Re: Fwd: FOSDEM 19 Debian Java talk
Hi Robert,
Some comments with my Maven package maintainer hat.
Le 12/02/2019 à 20:09, Robert Scholte a écrit :
> I'm also wondering how you build Maven, since Maven is
> being built with Maven. That should be a challenge to also rebuild all
> plugins, etc.
The maven package is rebuilt with the version of Maven previously
packaged, that's not really a problem now. In the past we used a
convoluted Ant build mimicking the Maven phases but that's history now.
The source code is fetched from the release tags on the Git repositories
(the tags are polled everyday and we're warned when a new release is
available). One project (library, plugin, etc) is mapped to one package,
and the upgrade process is done manually. It isn't terribly difficult
but that's quite time consuming. If there are Debian/Ubuntu users in the
Maven community interested in helping they are very welcome.
> And how do you test this and confirm that it works as the official
> distribution?
> Sure, *IF* Maven is 100% reproducible then you can rely on our
> test-infra, but that's not the situation.
Debian has a CI infra rebuilding 550+ packages using Maven as build
tool, so regressions tend to be caught fairly quickly (and immediately
[1] reported [2][3]). Also the version provided in the stable release is
available after months of user testing. So I'm pretty confident the
Debian package is true to the Apache binaries.
> So here are my main questions:
> - Are you making clear that you're not using the official Maven
> distribution, e.g. by adjust the info from 'mvn --version'?
No we aren't, but that's worth considering. Note that as the Maven
reproducibility improves this will become unnecessary because at some
point we'll be able to build binaries strictly identical to the Apache ones.
> - What is the optimum way of distributing Maven sources? For example:
> also providing compile and package scripts (instead of calling
> maven-plugins)?
The current system is mostly fine to us. The only issue I got recently
was the embedding of the SLF4J sources at build time, because we don't
build binary packages installing the sources artifacts of the libraries
and they aren't available at build time (we could though, that's a
little more work). In this case I patched the build [4] to embed the
compiled classes with the shade plugin instead (the patch was refused
though [5], but that's a fairly minor divergence).
> Interesting :) We've been discussing how we could get more contributors
> and Kotlin was one idea, but that one didn't make it.
> Even though we as Maven developers don't like the wrapper, the community
> is asking for it, so we're seriously considering to add it as part of
> Maven Core.
The wrapper would have no significant impact on the Debian packaging, we
just remove it before assembling the source package (no binaries are
allowed).
Emmanuel Bourg
[1] https://issues.apache.org/jira/browse/MJAVADOC-504
[2] https://issues.apache.org/jira/browse/MPLUGIN-339
[3] https://issues.apache.org/jira/browse/SUREFIRE-1422
[4]
https://salsa.debian.org/java-team/maven/blob/master/debian/patches/slf4j-compatibility.patch
[5] https://github.com/apache/maven/pull/118
Reply to: