Move to maven for java builds

[Pierre Labastie]

For all java packages (except icedtea-web, which uses its own build system) in the book, ant is deprecated in favor of maven. Having maven would allow to switch to a more recent version of junit.

[Pierre Labastie]

Took some time to get the build system to do anything. Still not sure it actually builds anything: there are a lot of downloads of the type:

Downloaded from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/1.4.2/plexus-utils-1.4.2.jar (190 kB at 160 kB/s)

Actually, there is a DEPENDENCIES file containing 43 lines of the form:

  - Plexus Common Utilities (http://codehaus-plexus.github.io/plexus-utils/) org.codehaus.plexus:plexus-utils:jar:3.1.0

I'll have some work to build all of those from source, and actually I am not sure whether it is possible.

[Pierre Labastie]

What I have done so far:

• Download ​https://archive.apache.org/dist/maven/maven-3/3.5.3/source/apache-maven-3.5.3-src.tar.gz and ​https://archive.apache.org/dist/maven/maven-3/3.5.3/binaries/apache-maven-3.5.3-bin.tar.gz (maven needs a maven binary for building itself).
• Untar apache-maven-3.5.3-src.tar.gz and cd apache-maven-3.5.3
• tar xf ../apache-maven-3.5.3-bin.tar.gz (extracts to apache-maven-3.5.3 inside apache-maven-3.5.3, so maybe a --strip⁻components=1 would be better)
• Find the mvn binary with PATH=apache-maven-3.5.3/bin:$PATH
• Run mvn -Drat.ignoreErrors=true package. The -Drat.ignoreErrors switch is necessary because one file does not have a correct licence header (it does not have any licence header actually)

It takes a few minutes, but the time is mainly spent downloading files.

[Pierre Labastie]

OK when extracting the binary with --strip-components=1, there are no more downloads...

[Pierre Labastie]

Two days later: did some progress, but open source documentation is just a plague...

• I was wrong in comment:4. Downloaded files go to a local repository (by default $HOME/.m2/repository). If I erase $HOME/.m2, downloads occur again, whatever I do. Note that there is nothing wrong with that: maven depends on a lot of other projects. There are 1309 files downloaded, mainly jars...
• Maven builder works with "phases". When you ask for a phase (say "package", which is roughly equivalent to "install" in other build system), all the preceding phases (validate, compile, test, ...) are played again. There may be configuration switches to skip some of those... Have to read more doc :-(. But it means that if you first do the compile phase, and then as root, the package phase, all the preceding phases will be replayed as root.
• The default local repository can be changed on the command line, but cannot be put into the build directory, unless you skip the validation phase with -Drat.ignoreErrors=true.
• same for the binary package, which cannot be extracted in tree for the same reason.

So we need two auxiliary directories (the local repo and the maven binary), which cannot be put into the build tree. So where to put them? /tmp, .., user home? In any case, they have to be removed at the end of the build. I'd be inclined to use ..

[Pierre Labastie]

I realize that what we consider as building and installing is not quite the same in the maven ecosystem: everything that is built by maven has to be put into the repository(ies) in order to be reused in other builds (in addition to be installed to the system of course). Using system libraries is possible with some tweaks, but is discouraged.

I see that debian uses /usr/share/maven-repo, and adds some files to the repo for all the packages contained there. That's rather complicated...

Other things (unrelated). If we want to build everything from source in the java world, it may be a big task. We'd need other build tools (for example hamcrest, needed for junit, requires gradle. gradle can bootstrap itself. junit needs maven for building. maven needs junit. etc)

Even the jtreg test manager for OpenJDK requires a dozen of jars, from the same amount of sources...

I guess it would need a new book, something like JLFS (Java LFS). And a few authors...

In the absence of those, we'll have to use a lot of binaries without building them. Those may be downloaded from maven-central or apache repositories and stored in the local repository. But now, what do we want to build? Even fop can be found on those repos... I am wondering what is the limit between what we accept as binaries, and what we really want to build from source.

[Pierre Labastie]

Eventually, after a poll to the list, the decision has been taken to do what is described in #10548.

[Pierre Labastie]

Well, further discussion on the list lead showed that it'd be nice to keep developer tools ib the book for Java. I think the simplest is the following:

• Keep OpenJDK and apache-ant as they are now
• add apache-maven
• move junit to maven
• keep ant build for fop: the reason is that there is no easy way to add the hyphenation patterns with maven, except downloading the compiled patterns from sourceforge.

[Pierre Labastie]

Fixed at r19974