Add ``.install plugin url``, ``.ip url``, ``.install mod url`` and ``.im url`` Command (Would Love To Do Myself but Too Chaotic Yet, Will Keep Looking Into It) about autoplug-client HOT 19 OPEN

@Minionguyjpro Yeah sounds good, I would even extend it to make installing possible from, for example a spigot url, which would then extract the type (spigot) and id from the url, and then execute .install plugin spigot 1234 internally, and thus make the whole process much more convenient.

from autoplug-client.

I'm going to make another PR for the client soon to migrate it to Gradle, though it could conflict with the already open PRs. They'd have to make sure to sync the changes if it gets merged!

from autoplug-client.

@Minionguyjpro sure give that a try, it could be a bit harder though since it depends on some maven plugins.

from autoplug-client.

@Minionguyjpro sure give that a try, it could be a bit harder though since it depends on some maven plugins.

True, but we use maven central as repository when building with Gradle! So I guess this won't be a problem at all.

from autoplug-client.

@Minionguyjpro as far as I know maven plugins don't run on Gradle. You will have to find alternative Gradle plugins that do the same things.

from autoplug-client.

No, there is no need for that actually since Gradle supports the Maven Central repository and it can download all of the same plugins from there just fine and build (I tested). I'm not sure though, what is the difference between the generated AutoPlug-Client.jar in AP-TEST-SERVER/ compared to the original-AutoPlug-Client.jar in target/. The one in the targetdirectory seems to be bigger. Please explain to me, it can help with some migration stuff to Gradle.

from autoplug-client.

No, there is no need for that actually since Gradle supports the Maven Central repository and it can download all of the same plugins from there just fine and build (I tested). I'm not sure though, what is the difference between the generated AutoPlug-Client.jar in AP-TEST-SERVER/ compared to the original-AutoPlug-Client.jar in target/. The one in the targetdirectory seems to be bigger. Please explain to me, it can help with some migration stuff to Gradle.

Well maybe they aren't runnable on Gradle. But maybe the ones in the Maven Central also have a Gradle version? I'm not sure, but all plugins for Minecraft projects that ran on Maven, also seem to have a version that can be used by Gradle.

from autoplug-client.

The one in the targetdirectory seems to be bigger. Please explain to me, it can help with some migration stuff to Gradle.

I guess you are missing shading, go through all plugins used in pom.xml build and search for gradle alternatives,
i think you can even try chatgpt for this.

from autoplug-client.

from autoplug-client.

@Minionguyjpro Ahh thats what you meant. The jar in AP-TEST-SERVER is simply the shaded jar that was moved from /target into that directory.

In AP-TEST-SERVER, you can then run autoplug and do manual tests.

from autoplug-client.

@Minionguyjpro Ahh thats what you meant. The jar in AP-TEST-SERVER is simply the shaded jar that was moved from /target into that directory.

In AP-TEST-SERVER, you can then run autoplug and do manual tests.

I see. But is the jar in /target not shaded or is it? I want to try to replicate the functionality as close as possible.

from autoplug-client.

@Minionguyjpro Ahh thats what you meant. The jar in AP-TEST-SERVER is simply the shaded jar that was moved from /target into that directory.
In AP-TEST-SERVER, you can then run autoplug and do manual tests.

I see. But is the jar in /target not shaded or is it? I want to try to replicate the functionality as close as possible.

I see it's not, okay.

from autoplug-client.

Okay @Osiris-Team I got tests to work, but do you know why this one here fails?

from autoplug-client.

Okay @Osiris-Team I got tests to work, but do you know why this one here fails?

Maven also seems to fail the same test.

from autoplug-client.

Ah nevermind you exclude the test task. I now successfully got to replicate the same names (Shaded AutoPlug-Client.jar in AP-TEST-SERVER and original-AutoPlug-Client.jar in build/libs). Will need to do some manual tests myself to see whether it runs.

EDIT: the shaded JAR seems to fail with:

Failed to determine AutoPlug-Client version. More details below. Keep in mind that the exception is ignored and does not further affect the application.
java.lang.NullPointerException: inStream parameter is null
	at java.base/java.util.Objects.requireNonNull(Objects.java:235)
	at java.base/java.util.Properties.load(Properties.java:410)
	at com.osiris.autoplug.client.utils.UtilsJar.getPropertiesFromJar(UtilsJar.java:101)
	at com.osiris.autoplug.client.utils.UtilsJar.getAutoPlugPropertiesFromJar(UtilsJar.java:80)
	at com.osiris.autoplug.client.utils.UtilsJar.getThisJarsAutoPlugProperties(UtilsJar.java:70)
	at com.osiris.autoplug.client.utils.GD.<clinit>(GD.java:48)
	at com.osiris.autoplug.client.Main.main(Main.java:57)
Initialising AutoPlug-Client (ERROR RETRIEVING VERSION)

It still runs, but do you have any idea why this happens and how to fix it in here?

from autoplug-client.

@Minionguyjpro in pom.xml there is a section that creates and includes an autoplug.properties file in the jar with the version, so you must replicate that too in gradle.

from autoplug-client.

@Minionguyjpro in pom.xml there is a section that creates and includes an autoplug.properties file in the jar with the version, so you must replicate that too in gradle.

Okay got it, was able to recreate such a thing in Gradle using writing and stuff. It works, the version is now visible but I still get this error on startup after some time:

SLF4J: No SLF4J providers were found.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See https://www.slf4j.org/codes.html#noProviders for further details.
SLF4J: Class path contains SLF4J bindings targeting slf4j-api versions 1.7.x or earlier.
SLF4J: Ignoring binding found at [jar:file:/home/minionguyjpro/Documenten/GitHub/AutoPlug-Client/AP-TEST-SERVER/AutoPlug-Client.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See https://www.slf4j.org/codes.html#ignoredBindings for an explanation

from autoplug-client.

@Minionguyjpro in pom.xml there is a section that creates and includes an autoplug.properties file in the jar with the version, so you must replicate that too in gradle.

Okay got it, was able to recreate such a thing in Gradle using writing and stuff. It works, the version is now visible but I still get this error on startup after some time:

SLF4J: No SLF4J providers were found.
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See https://www.slf4j.org/codes.html#noProviders for further details.
SLF4J: Class path contains SLF4J bindings targeting slf4j-api versions 1.7.x or earlier.
SLF4J: Ignoring binding found at [jar:file:/home/minionguyjpro/Documenten/GitHub/AutoPlug-Client/AP-TEST-SERVER/AutoPlug-Client.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See https://www.slf4j.org/codes.html#ignoredBindings for an explanation

And it seems like AutoPlug functions as normal apart from that! I want to get that error fixed so we can get that annoying thing away.

from autoplug-client.

@Minionguyjpro also handled in the pom.xml somewhere. Search for slf4j in there.

from autoplug-client.