Re: Multiple source roots?

[Scott Palmer]

> For myself, and most of the guys I work with, Maven would be the one we’d have throttled.  Totally agree. I worked on a large project that went through the build lifecycle of Ant -> Maven -> Gradle.  Ant had the flexibility, and Ant+Ivy worked well for dependency management, but the XML was just way too unwieldy to deal with. Maven had structure and lacked flexibility, you have to shoehorn your project into its limited little boxes and still deal with excessively verbose XML.  I get that is sort of the point - you shouldn’t invent your own project conventions on a whim… but complex projects don’t always fit well into an existing convention no matter how hard you try to make it happen.   Back on topic… Multiple sources roots are trivial with Gradle: sourceSets {     main {         java {             srcDir 'src/main/java'             srcDir 'generated/src/main/java' // Add a generated source directory         }         resources {             srcDir 'src/main/resources'             srcDir 'src/main/config' // Add another resource directory         }     } } To add another perspective, I recently started programming some projects in Zig.  In Zig your build file is Zig code. Zig provides APIs to configure the build and you call them from a build.zig file.  I thought that was an interesting approach, and I liked the idea of not being forced to learn yet another language for the build system (e.g. Kotlin).  It seems similar to Gradle if Gradle had used Java as the language for the build file - it’s not far off what they’ve done with Kotlin.   Scott On Sep 20, 2025, at 7:04 AM, Rob Walker <r...@ascert.com.invalid> wrote:  We all have our preferences – and we all have our reasons for them, many of which don’t gel with others.   Gradle was the first newer generation build tool that gave us a worthy replacement to Ant on our projects. For myself, and most of the guys I work with, Maven would be the one we’d have throttled. We begrudgingly work with it on a handful of OSS libs where it’s the tool of choice. Like I say – different strokes.   On the topic of the original post – Gradle does a passable job of multiple source roots, with a bit of effort. In NB it’s not perfect, but it’s kind of OK if you treat each subproject as standalone with clear divisions and boundaries, and work with it that way. I tend to do my builds & tests from standalone command shell windows – all I’m looking for out of an IDE is graceful handling when editing and highlighting when I (or others in the team) have wandered off base. Couple of the other guys do more work within the IDE itself – although at least one of those is also a VSCode fan and uses both.   (Also been a professional coder for 40+ years, FWIW)   -R   From: Stephen Parry <sgpa...@mainscreen.com> Sent: 20 September 2025 11:43 To: users@netbeans.apache.org Subject: Re: Multiple source roots?   I have to make the case against a lot of what has been said here. I have worked with different build tools for over 40 years, within hobby, industry and education, including make/cmake with c++, Maven and Gradle with desktop, and Gradle with Android Java. The consistent and rigid structure of a Maven build is a key part of its strength as a build tool. You don't have to spend three days working out where the crazed code monkey who wrote the build has put the source for the code component you need to work on. The build is there to provide simple and clear support for the source code, not to *be* the source code. If you allow flexibility but guideline good practice, that good practice just gets ignored. As such, it is not sufficient to just ask / advocate for multiple source roots. You have to be specific. That multiplicity has to be tied to a stated purpose (jmods, generated sources, multiple apps within a suite...), so that its use is documented, understood and expected. Some of these already exist in Maven. Programmer's whim or "future expansion" are not sufficient reason for allowing the build process to be made more complex. The compile / build / run functions of an IDE should be the the thinnest and simplest possible wrapper around the build tool. When you open the 'makefile', that should be opening the IDE project. That is the great thing about NetBeans. It has almost become Maven with a UI. That way, if the code runs in the IDE, command line builds and CI/CD have some chance of working too. You are one step closer to packaging the working final product, not hiding build issues behind the IDE. Moving between IDEs is simplified too. All this requires that the build process is simple and consistent enough that the IDE tooling can understand it and interface with it. This is also good for any developer who is novice to the project. From my perception, Maven's main limitation is messy, poor and poorly understood support for different configurations and platforms. It is very Javacentric in that way - write once, run anywhere. Although that is a compromise that keeps things simpler, it left a gap for Gradle, a tool that should have been throttled at birth, IMHO. I agree that JSON would have been more concise than XML, but ini files? That's like saying Fortran is better than Java or Pascal. A build configuration is and should be an n-level structure. INI files are at best three level, if you use multiple files. Gradle configuration is not declarative; it is imperative code dressed up as declarative. Converting between Groovy(sic) and Koitlin recipes is not straightforward and the two are yet more languages that have to be learned, whereas anyone and everyone already can and does learn XML and JSON. The greater flexibility in Gradle has led to the minefield where the two recipes needed for adding a plugin or a library work fine for desktop, but have no chance of working for Android, because Google do Gradle 'their way'. Just my tuppence worth.   On 19 September 2025 19:58:05 BST, Ulrich Mayring <ulrich.mayr...@isys.de.INVALID> wrote: I like multiple source roots as well, but since Netbeans decided at one point to just be a UI for the chosen build system, it also means that the build system has to support multiple source roots. Gradle does that in a way, but it's far from perfect and involves manually editing the build file - you cannot do it with the “build system UI” aka Netbeans. However, you can do it well enough to make it work for large and small projects and if it doesn't work for your project, then maybe your project should be refactored. I'm also for imperative build files, because declarative approaches are too complex for the human brain and should never be the default. They should only be employed if they work demonstrably better in a given use case than imperative approaches (in some exceptional cases they may even be easier to understand for the human brain). It is again possible, if not ideal, to use Gradle for imperative approaches. You can write imperative code in either Groovy or Kotlin. These are first-class programming languages, so do whatever you want. However, if you think a build file should not be executable code, but only configuration for an external code executor, then Maven might be the right build tool for you. If you want to write your own build tool and use it in Netbeans, you have to write a plug-in to integrate it. Riding on the back of another plugin supporting another build system and sneaking your own in there, doesn't make sense. You'll never get your fixes or changes approved, because that other build system is probably not interested in supporting piggy-backers. iSYS Software GmbH Ulrich Mayring | Full Stack Developer Technology Lab / R&D Tel: +49 (0) 89 46 23 28-0 | Fax  +49 (0) 89 46 23 28-14 email: ulrich.mayr...@isys.de Grillparzerstraße 10 | D-81675 München www.isys.de Sitz der Gesellschaft: München | HRB 111760 Geschäftsführer: Stefan Fischer und Max Haller -- Sent from my Android device with K-9 Mail. Please excuse my brevity.