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
Attachment:
signature.asc
Description: OpenPGP digital signature