I have proposed a similar approach with maven.vendor in the build.properties.
> Gesendet: Donnerstag, 14. Februar 2019 um 14:24 Uhr > Von: "Gary Gregory" <garydgreg...@gmail.com> > An: "Maven Developers List" <dev@maven.apache.org> > Cc: "Robert Scholte" <rfscho...@apache.org>, "Dalibor Topic" > <dalibor.to...@oracle.com>, debian-j...@lists.debian.org, "Matthias Klose" > <d...@ubuntu.com> > Betreff: Re: Fwd: FOSDEM 19 Debian Java talk > > 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 > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
