In fact, as along term user of Maven and Linux, I actually even dislike that binary JARs are rebuilt from scratch, as this is not what WORA was invented for. It adds no benefits, it just adds new bugs happening on one distro but no on another. If you ask me, immediately stop doing that and simply use the one and original built from Apache. This is not C++, this is Java.
And if you want to build Maven from scratch, then build it using Maven. That is the intended way. -Markus -----Ursprüngliche Nachricht----- Von: Tamás Cservenák [mailto:[email protected]] Gesendet: Donnerstag, 19. November 2020 09:51 An: Maven Developers List Betreff: Re: Talk: Bootstrapping the Java Ecosystem Hi Bjorn and Emmanuel, Without starting any flame wars, am really curious: why are you repackaging Maven? I'd understand for OS/distro native packages, but why do you rebuild JVM bytecode as well? Again, am not to start any flame war, am just curious! Am Linux user since 98 (first worked on S.u.S.E at university around '96), but was since using "dirty" distros like openSUSE then Ubuntu and today Mint. While watching the video, several questions arose in my head: 1) Instead of rebuilding something (let's say LOC of 1x), you did that several, if not ten times (so LOC of 10x). So, you had to review the codebase 10x I guess? Otherwise you are not sure what you built - as I guess you build it from source to be sure and able to see (among others) what are you building. How long was the review process? 2) Similarly, in a process like this, how do you track vulnerabilities or any other outstanding bugs? Or the "intermediate" bootstrapped dependencies simply "does not matter"? Just the final "output" is what matters (let's say Maven)? 3) What are you really building? As in video, it is said several times that you "mutilate" some package to build it, then use it to "bootstrap" some other package, and finally you rebuild the target package. Given in the process there was once a "mutilated" tool, how are you certain, that output of the build is correct (I have no doubts about reproducibility)? How do you prove that output is what it is thought/assumed to be? 3) (Joker) What is the overall CO2 footprint of distros like these? I believe you did not use Apple M1 for this work... :) Thanks in advance, T On Thu, Nov 19, 2020 at 9:15 AM Emmanuel Bourg <[email protected]> wrote: > Hi Björn, > > Nice presentation, the packaging of Maven in Debian followed a similar > path but we never documented the process. Did you go as far as recording > the exact steps and build order required to build from scratch? > > Spoiler for the next part of your quest toward packaging the Android > SDK: Maven was the easy part, Gradle and Kotlin are many leagues above > in term of circular dependencies and headache. We have been trying to > bootstrap Kotlin for 2 years in Debian and haven't found the right path > yet. > > Emmanuel Bourg > > > On 18/11/2020 21:29, Björn Höfling wrote: > > Dear Maven Developers, > > > > more than 4 years ago I naively asked you on how to build Maven from > > sources without using Maven. > > > > If you are interested in a declarative, bootstrappable, reproducible > > and effectively executable answer to this question, Julien Lepiller > > recorded a video on how he bootstrapped Maven and a maven-build-system > > for GNU Guix with only using the ant-build-system. He shows how to > > bootstrap Maven only from sources, which difficulties he had and how he > > mastered the dependency cycles and other problems. > > > > You can find a link to the video recordings in this announcement: > > > > https://guix.gnu.org/en/blog/2020/online-guix-day-announce-2/ > > > > If you have any questions, you can join the discussions on Guix day, > > the discussions for this talk will be on Sunday 2020-11-22, 16:00–16:25 > > UTC. > > > > Happy Hacking, > > > > Björn > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
