Traneptora / jxlatte

Java JPEG XL decoder
MIT License
41 stars 6 forks source link

Move to the Gradle Build System #3

Closed hYdos closed 1 year ago

hYdos commented 1 year ago

First of all, I love this project. It's a great thing to see something so new and maintained on java and thank you for all your had work ❤️ However, if I or someone else wanted to use this program in their own java program there are a few issues. The build system you use even though compatible with java, doesn't do everything needed to use java properly. With Gradle, we remove the need to copy your code into our projects. We just either publish the code locally to what we call a maven (the local one is called mavenLocal) or we use a service such as https://jitpack.io to host the built jar for us to depend on. Gradle also greatly improves IDE compatibility as all Java IDE's (IntelliJ and Eclipse) support it and finally it also improves the user friendliness. If I want to build this program on Windows all i do is gradlew build and on Linux its just ./gradlew build.

Traneptora commented 1 year ago

No, gradle sucks for a variety of reasons. If you want to build the program on windows or linux you run "meson setup build/" and "meson compile build/"

hYdos commented 1 year ago

why do you think Gradle sucks any more than meson?

On Tue, Mar 28, 2023 at 12:28 AM Leo Izen @.***> wrote:

No, gradle sucks for a variety of reasons. If you want to build the program on windows or linux you run "meson setup build/" and "meson compile build/"

— Reply to this email directly, view it on GitHub https://github.com/thebombzen/jxlatte/pull/3#issuecomment-1485216823, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGCR7I7VSJABLH2TSSAVLSLW6GPYFANCNFSM6AAAAAAWI7VSWM . You are receiving this because you authored the thread.Message ID: @.***>

Traneptora commented 1 year ago

Gradle's absurdly slow and bloated, breaks your build when you update it, and requires you to learn Groovy to do anything interesting. It requires you to commit the build system itself to your repository in order to prevent some of these issues, and it's also completely unnecessary for anything that just produces a single jar file with no dependencies other than the JVM.

hYdos commented 1 year ago

okay then, Use Maven.

On Tue, Mar 28, 2023 at 1:13 PM Leo Izen @.***> wrote:

Gradle's absurdly slow and bloated, breaks your build when you update it, and requires you to learn Groovy to do anything interesting. It requires you to commit the build system itself to your repository in order to prevent some of these issues, and it's also completely unnecessary for anything that just produces a single jar file with no dependencies other than the JVM.

— Reply to this email directly, view it on GitHub https://github.com/thebombzen/jxlatte/pull/3#issuecomment-1486142271, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGCR7I6Q26WNHFZ5G2PLCILW6JJL3ANCNFSM6AAAAAAWI7VSWM . You are receiving this because you authored the thread.Message ID: @.***>

eli-schwartz commented 1 year ago

With Gradle, we remove the need to copy your code into our projects. We just either publish the code locally to what we call a maven (the local one is called mavenLocal) or we use a service such as https://jitpack.io to host the built jar for us to depend on.

Curious why you need gradle for this? If both gradle and meson produce a *.jar output and you plan to use a hosted service for the artifact, why is it infeasible to just host whatever built artifact is produced by whichever arbitrary command the project uses? Either way it's totally irrelevant to local dev work.

Gradle also greatly improves IDE compatibility as all Java IDE's (IntelliJ and Eclipse) support it

Okay, I suppose. Pity it doesn't support something standard like compile_commands.json, especially because Jetbrains projects do support that for e.g. CLion.

and finally it also improves the user friendliness. If I want to build this program on Windows all i do is gradlew build and on Linux its just ./gradlew build.

... huh? This is just a tautology. Really, it's essentially just the logical fallacy "appeal to popularity".

If you want to build this program on Windows all you do is arcane-command, that command can just as easily be an arcane meson command. While it is true that many Java users are familiar with gradle, that doesn't mean it's good, merely familiar. Probably a Makefile would be even more familiar.

Maybe a small custom wrapper script called ./gradlew would help, that just executes the relevant meson commands?

...

I really feel like this is probably all irrelevant and what is really wanted is binary release artifacts (uploaded .jar files, optionally to Maven Central), much like people publish binary release artifacts for most any other language. The most user-friendly thing to do is to not require users to build anything, surely?