Jar manifest files carry data like "built-by" and implementation information:
https://docs.oracle.com/javase/tutorial/deployment/jar/packageman.html Why not reuse "Implementation-Vendor" or invent a new entry and put "Debian" in there. Maven can display this additional information on "mvn -version". Gary On Thu, Feb 14, 2019 at 4:56 AM Markus Koschany <a...@debian.org> wrote: > 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 > >
