On Thu, 24 May 2018 21:02:31 -0400 Tim Boudreau <[email protected]> wrote:
> I could tell you whatever you want to know about Gentoo's build > system, Really? I have completely redesign how Java is handled... I would doubt there are more familiar with it than me, at least regarding Java on Gentoo. Though my work is still a work in process, and still re-engineering aspects. > but I don't know that it's really relevant to building > NetBeans. It is nice, and does the kind of parallelization you're > after, but it's more like a meta-build system - a build system for > running other build systems. FWIW, NetBSd/SmartOS's pkgsrc is also > similar, but makefile-based and more aggressive about rebuilding > dependencies. Guess you missed that my Netbeans ebuilds wrap nothing... They call javac directly. NO ant, maven, gradle etc. It CAN wrap other build systems, or it can BE the build system :) In my case portage IS the build system for Netbeans. Its very trivial. Probably the most simplistic way to build Netbeans. > If you were looking at replacing the Ant based system, the first > place I'd look is Maven, since there is already support for building > modules with it, so a lot of the heavy lifting is already done. Maven is dead... Nothing new should be done in Maven. There is little reason to use Maven over Gradle. The build aspect of Maven itself is reason enough not to use it. Plexus and Modello are underlying to how Maven is built. It seems nothing uses that stuff. I bet few here even do anything with it. https://github.com/codehaus-plexus https://github.com/codehaus-plexus/modello There are enough things that generate Java code from something else, IMHO way to many. At least Gradle uses Groovy which other stuff uses. Nothing uses the technology that Maven uses to build itself. Ant and Gradle are trivial to build compared to Maven, its junk IMHO. > If you're looking to parallelize building modules, that probably > could be done either with the existing Ant system, or possibly with > Maven - I don't know off the top of my head something for > parallelizing a multi module build, but it's likely to be a solved > problem. IMHO the ant build system is a bit bulky and has source/targets in to many places. I am not anti-ant, I do still have legacy projects in ant. But anything new is Gradle. I see few reasons really to remain with ant. I see absolutely no reason to ever use Maven for anything that is not already Maven. XML is dead, and we should kill it ASAP. Ant and Maven continue this XML legacy, most the rest of the world has moved passed horrendous XML. > IMO, Gradle is a step backward for build systems - scriptability > leads to fragile systems, and ones that are impossible for tools to > reason about. > > https://timboudreau.com/blog/maven/read Compared to Netbeans heavy ant modifications... https://github.com/apache/incubator-netbeans/tree/master/nbbuild/antsrc/org/netbeans/nbbuild Netbeans ant build can be fragile. It was next to impossible to wrap its ant build system in Gentoo's portage. Such that it was easier to bypass it entirely. I believe the result of what I am working with is considerably less complex. No java code, no extending a build system, no plugins etc. Just building Netbeans using my ebulids is SLOW... Speed was not the goal. Flexibility on usage, being able to create your own meta package, project build on Netbeans. Or a user specific IDE with only modules they care about etc. If someone only wants what they need, it could be less than building via existing build system. The harness stuff. This was the most modular another could make using the harness https://gitweb.gentoo.org/dev/fordfrog.git/tree/dev-java My approach makes ever jar available individually. Its different and would have a limited target audience. > In my experience, the biggest accelerator of building NetBeans is SSD > - ideally a couple in raid-0. If you're bound on disk I/O, you might > do a lot of work to parallelize everything, and then find build times > aren't much improved, if you were saturating the hardware. Travis has some decent infrastructure and takes ~30 min there, just as an example. https://travis-ci.org/apache/incubator-netbeans IMHO faster hardware is not always the answer to a speed solution. Code reduction and efficiency etc could be more of a factor. Combine that with faster hardware. You have a real winner :) Take portage, systems have gotten faster, but Gentoos portage slower IMHO due to bad coding and maybe use of Python vs C or other. Interesting that others stuff like Bazel and Buck also use mostly Java and some python. Rather than all python. An example there is Jem vs Java-Config, C vs Python, C screams and uses less ram, cpu etc. Just takes more to code in C than python. https://github.com/Obsidian-StudiosInc/jem https://github.com/gentoo/java-config Most are like who cares. But on a battery or limited hardware. Ever bit adds up to real savings. Sadly to many code quick and put the delays in runtime. I rather code slow and ensure efficient running code ideally. Rather than save the developer time, I save the world... and electricity etc. Its a different non RAD approach. > If you want to measure how disk bound, copy the source tree to a > ramdisk and time building there. > > For that matter, there is probably a lot of low hanging fruit in > improving performance of the existing Ant build - I don't know that > much effort has ever been put into that. Netbeans build is not that slow IMHO. Though could be faster. I think the main reason to move past Ant is its mostly yesterdays technology. IMHO Ant was Java's 1st generation build system. Maven 2nd generation, and Gradle is 3rd and current. Given the rise of Meson, that may pave the way for more Gradle usage. The one thing Gradle has almost nothing else does is gradle wrapper, gradlew. The ability to install and run itself from a minimal script. That alone is super useful for an environment that is not ready for a project build. Get your JDK, run gradlew, and your off to the races. But the work to switch Netbeans to Gradle would be considerable. Hard to say if thats worth it. Other than moving things forward vs remaining the same. But it is some what moot. -- William L. Thomson Jr.
pgpZ7yXBnzrN6.pgp
Description: OpenPGP digital signature
