On Mon, 25 Jun 2018 08:24:58 +0200 Michael Osipov <micha...@apache.org> wrote: > > William, > > my first an foremost question is why do you need this?
Maven and parts are needed as dependencies for Gradle and Netbeans. > Aren't you satisfied with the signed binary released we provide? No, I do not run a binary distribution. Why should Maven be one of the sole binaries? The only exception is the JDK itself, for other reasons. > Even if you pursue the from-source-BSD-approach, it is perfectly fine > to use packages as-is. Pre-generated sources are bad. One should have a means to build from version control for a variety of reasons. Java has a horrendous habit of developing things that require bootstrapping, needlessly... The JDK is one thing, but anything built atop should have a better way. Most of these generate Java code or bytecode from something else. > This is what I recommend on the FreeBSD Java mailing list. Moreover, > the general consensus from us is that we do not support packages not > carrying the Git commit or our signature. Debian guys do abnormal > things by splitting every single dependency of Maven into a deb file. I am not looking for support. I am looking to understand things Maven is built atop and how its developed. If one makes changes to a mdo file. They must run Maven to generate the Java file. Plus then write tests to ensure that what Modello generated was what was expected. Rather than writing pure Java from the start... In a nutshell to develop maven, you must be able to run maven. To use said plugins to generate Java code. Which a choice was made to use that format over others. Which can always be changed and eliminates any issues I have with build. It is not like Modello's .mdo files are in wide use. I cannot find them anywhere other than Maven, and even worse a circular dep issue with Plexus. https://github.com/codehaus-plexus/plexus-containers/issues/11 That is poor design IMHO. Maven could drop using Modello mdo files for some other format for Maven build. Which would not effect other stuff. It likely would not change work flow described above. As you swap out the modello-maven-plugin for javacc, antlr, xjc, or some other plugin. Lots of Generators to choose from that are more common. > These days compiling Java software w/ pure javac is a pain. Maybe how you do it, but using what I have been working on for sometime it is anything but. I was able to package most of Netbeans in a much more simplistic way using a completely different build system. You should look at some of my packages and tell me that is complex. Or even the eclasses. They are trivial compared to most other build systems. It could even be used on other distros or OS. https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/dev-java/ Netbeans ones are even less due to its eclass https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/nb-ide https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/eclass/java-netbeans.eclass > Even if this will work, you'd still need -- as you have said -- all > dependencies from Maven. So you still rely on binary files. Nice assumption, but you are wrong. I build ALL dependencies from source.... I use no binaries, except for javacc only to build javacc from source within its package. Its the only one using a pre-build binary that resides within source releases. https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/dev-java/javacc/javacc-9999.ebuild#L39 Which I have a request into to stop requiring bootstrap. https://github.com/javacc/javacc/issues/40 Other stuff I can build to build itself like Groovy, antlr and many other generators. Though I do dislike bootstrapping and believe it can be avoided in many cases. Sadly others do not care about such and rather continue with the bad practices of requiring bootstrapping. -- William L. Thomson Jr.
pgpRaG5o3YvtH.pgp
Description: OpenPGP digital signature
