Hi Robert,
Am 12.02.19 um 20:09 schrieb Robert Scholte:
[...]
> Hi Markus,
>
> first of all thanks for the insights, it is important for us to know how
> Maven is used and in which way we can improve that way-of-work. Hervé is
> already working hard on the reproducible builds specs with your team in
> order to find out how we can improve our maven-plugins to get
> reproducible artifacts.
>
> Maven itself is not 100% reproducible. We've learned that some Linux
> vendors rebuild Maven and the presentation confirmed that Debian is one
> of those vendors. What we've seen in the past is that sometimes people
> are having issues with Maven and after a while we discovered that they
> were not using the official Apache Maven distribution[1]. For us it is
> quite easy to say: sorry, not our official distribution, please contact
> your Linux distributor.
> In such case we have 3 losers: the user, the Apache Maven project and
> the Linux Distributor. If only the official Maven distribution was used,
> then we would have had 3 winners.
>
> When you decide to rebuild Maven, you're also taking all related
> responsibilities.
We hear this a lot and it seems to be more common in the Java community.
>From Debian's point of view (other distributions like Fedora share the
same view) it is essential being able to rebuild software from source.
The prerequisite is the availability of source code of course. Most of
us find it even strange when upstream developers recommend to use their
prebuilt versions. Do they have something to hide? Why can't they just
make building from source easy and trivial?
We believe that every user should have the ability to modify software
but this is only possible if she can build it from source. We go to
great lengths to ensure that all software complies with Debian's free
software guidelines. For the enduser the language and build tools of a
certain piece of software almost become meaningless. They just type "apt
source maven", change into the maven directory and rebuild the software
with another one-liner.
In case of Maven I don't see where our release differs fundamentally
from your binary releases. As I said there is only one reproducibility
patch left that doesn't change the functionality at all. So what we do
is grab your sources from https://github.com/apache/maven/releases or
maven.apache.org. In our opinion, without making any significant
changes, it should just behave as your binary release when we build it
from source. Otherwise there is source code missing or different.
> 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.
> 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.
It is a challenge to build Maven from source. We solved the
bootstrapping problem and now we can use Debian's Maven version to build
newer versions but we have to follow a certain build order when we make
an update.
> 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'?
This is how it looks on Debian 9 "Stretch" at the moment.
Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.8.0_181, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "linux", version: "4.9.0-8-amd64", arch: "amd64", family: "unix"
It is obvious from Maven home I guess but there is no special emphasis
on Debian because when you install Maven from Debian you will never get
a prebuilt binary release, this is implicit for all software in Debian's
main distribution.
> - What is the optimum way of distributing Maven sources? For example:
> also providing compile and package scripts (instead of calling
> maven-plugins)?
The major headache for us is the initial bootstrapping of new compilers
or build tools. We often write our own Ant scripts to solve the chicken
and egg problem. For Maven this is currently solved but if I recall
correctly there are sometimes plugins that require a certain Maven
version which in turn requires a specific plugin version, a classic
dependency loop. So if there was a way to build Maven without Maven or
certain plugins that would obviously make our life easier.
[...]
>> Our biggest challenge is Gradle. If Robert wants to help us then he
>> should never rewrite parts of Maven in Kotlin or encourage developers to
>> use a specific prebuilt version of Maven and to ship a script in every
>> project that downloads it from the internet (gradle-wrapper). ;)
>
> 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.
Uh, don't give in to those developers. :) This is really a bad habit in
the Java community. A build system should be merely a tool to build your
software and maybe for simplifying project management but imagine all
C/C++/Python and Perl developers would be like that. What a nightmare.
Regards,
Markus