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)

Osiris-Team / AutoPlug-Client

Server manager with automatic plugin- mod- server- java- self- updater, scheduled restarts, automatic backups, shared folders, and many more handy features to automate/boost your server maintenance.

https://autoplug.one/

MIT License

56 stars 23 forks source link

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) #237

Open Minionguyjpro opened 5 months ago

Minionguyjpro commented 5 months ago

Importance: 5/10

Problem: The functionality to download a plugin and mod using a direct download link/URL to the .jar is missing. This functionality would allow us to install plugins easily that are outside of the known platforms such as Bukkit, Spigot, Modrinth and CurseForge (GitHub too, but that's for open source projects in general).

Solution: Add a command to install a plugin and mod using an URL directly, and throw an error if the downloading file from the URL doesn't end in .jar.

Osiris-Team commented 5 months ago

@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.

Minionguyjpro commented 5 months ago

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!

Osiris-Team commented 5 months ago

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

Minionguyjpro commented 5 months ago

@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.

Osiris-Team commented 5 months ago

@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.

Minionguyjpro commented 5 months ago

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.

Minionguyjpro commented 5 months ago

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.

Osiris-Team commented 5 months ago

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.

Minionguyjpro commented 5 months ago

Oh it generates them, but could you just explain me what the AP-TEST-SERVER one is different from the other generated one in target?

Op di 30 apr. 2024 22:10 schreef Osiris-Team @.***>:

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.

— Reply to this email directly, view it on GitHub https://github.com/Osiris-Team/AutoPlug-Client/issues/237#issuecomment-2087030836, or unsubscribe https://github.com/notifications/unsubscribe-auth/APYNRKUWNYDKRKHBQZSWMLDY773DPAVCNFSM6AAAAABG34XRC6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBXGAZTAOBTGY . You are receiving this because you were mentioned.Message ID: @.***>

Osiris-Team commented 5 months ago

@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.

Minionguyjpro commented 5 months ago

@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.

Minionguyjpro commented 5 months ago

@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.

Minionguyjpro commented 5 months ago

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

Minionguyjpro commented 5 months ago

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.

Minionguyjpro commented 5 months ago

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?

Osiris-Team commented 5 months ago

@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.

Minionguyjpro commented 5 months ago

@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

Minionguyjpro commented 5 months ago

@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.

Osiris-Team commented 5 months ago

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