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

[bokken]

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]

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]

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

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. :-)

[jordanMatrix]

Is there still any appetite for this? I would like to help / contribute but certainly using Ant is a "turn off" for me.

If there are no additional dependencies needed to build or run with maven, then there is no additional download necessary. Although you might be referring to build depencies that maven needs to build like the various plugins it uses be default.

[collinfunk]

As far as I know, Maven kind-of requires a standardized directory layout which xz-java doesn't use.

I wonder if it would be easier to use Bazel or Gradle.

[bokken]

I have done the work to do builds in maven in the past.
The only thing I found clunky was the multi-version jar content.

[Larhzu]

Sorry for the delays. In the past two years I have spent much less time on XZ for Java than I expected in early 2024, so the project hasn't progressed recently. :-(

I don't have a clear answer to the Maven question right now. If I'm maintaining the code, then I need to have some kind of understanding what the code does. Moving to Maven would mean that I need to learn Maven well enough.

@collinfunk wrote:

As far as I know, Maven kind-of requires a standardized directory layout which xz-java doesn't use.

It can be changed if required. It's annoying though because renamed files make it harder to view the history.

@jordanMatrix wrote:

If there are no additional dependencies needed to build or run with maven, then there is no additional download necessary. Although you might be referring to build depencies that maven needs to build like the various plugins it uses be default.

A POM file refers to a bunch of plugins. I assume at least some of those plugins aren't shipped with Maven (or packaged by GNU/Linux distros). Instead, Maven itself works like a package manager and downloads binary packages of those plugins, and then runs them, right?

Packages in the Maven Central are signed by those who upload them; they aren't centrally signed by Maven Central because Maven Central doesn't build any packages either. The POM file examples I found don't list any (package/plugin-specific) signing keys or hashes, so I wonder how Maven verifies that the file it downloaded is what it should be.

I'm well aware that the GNU/Linux distro method for packaging isn't guaranteed to avoid supplychain attacks, but I'm comparing to that model because I'm more familiar with it.

I would like to help / contribute but certainly using Ant is a "turn off" for me.

Do you have any specific contributions in mind? :-) Some things that could be done:

• Test suite is the most obvious missing thing.

• Threading support: I might like to work on this myself at some point. The encoder shouldn't be a huge amount of work. However, I understand that people wish for quicker progress and then someone else writing it might need to be considered. I fear that my review process might take as much effort from me as just writing the code myself.

• Some sort of code review focused on Java-specific things: My limited Java experience must show in the code at some places, I'm sure. For example, I don't know if the exception saving in finish and close in XZOutputStream and several other classes makes sense. Normally that specific detail doesn't matter though.

With the above points, I suppose the test suite is where Maven vs. Ant matters most.