search

tukaani-project / xz-java

XZ for Java
https://tukaani.org/xz/java.html
BSD Zero Clause License
23 stars 14 forks source link

[Discussion]: Is there interest in moving to maven based build instead of ant #9

Open bokken opened 6 months ago

bokken commented 6 months ago

Describe the Feature

maven is more commonly used now than ant, and it's pom.xml and repository have become something of a standard for open source jar distribution. It would also simplify adding unit tests.

Expected Complications

Some project structural changes to comply with maven convention (i.e. source moved to /src/main/java). Naming of some secondary artifacts would likely change. There could be future work to break out some of the sample code into separate projects, which could be part of a reactor build.

Will I try to implement this new feature?

Yes

Larhzu commented 2 months ago

I don't have a clear opinion at the moment. I know very little about Java ecosystem. If Maven is what most people expect nowadays and it helps adding tests, I suppose I should learn it too. (But if it is like 50 % prefer Maven and 50 % prefer Ant, then it's perhaps simpler to not change.)

At least XZ for Java 1.10 should be done with the current build system. There isn't a lot to do until 1.10 could be released.

bokken commented 1 month ago

@Larhzu - I agree that getting 1.10 out (hopefully with the bytearrayview branch included :) ) is higher priority. My perspective of the current java ecosystem is that maven dominates, gradle is up and coming and ant is largely an afterthought.

Larhzu commented 1 month ago

My perspective of the current java ecosystem is that maven dominates, gradle is up and coming and ant is largely an afterthought.

OK, thanks!

Being new to these things, one thing in #10 stands out: if I understand it correctly, it seems that with Maven the build process itself has many external dependencies. Currently XZ for Java has only one online dependency, the short text file from Oracle that javadoc needs to link to the JDK documentation. It's not an executable file but it still feels slightly dirty when the project has no other dependencies.

If build system needs to download executable code as part of the build process, instead of that code being part of the build tool itself when the tool is installed, I suppose it would have felt a bit odd to me a year ago. After the spring 2024 event, there's certainly a new layer of extra thrill to the idea.

The way Maven Central works, each FOSS developer submitting both sources and binaries, always felt a bit different compared to how GNU/Linux distros and other OS packagers work. Those take the upstream source and build it. With Maven Central it doesn't seem obvious that the binaries must match the accompanying source but perhaps there is some sort of automated check done by someone somewhere. And I admit that we recently saw that it can be non-obvious in GNU/Linux distros too, but at least it takes more effort from the upstream as one cannot just upload binaries for everyone to run.

I agree that getting 1.10 out (hopefully with the bytearrayview branch included :) ) is higher priority.

Not a lot is missing from the 1.10 release, I hope. :-)