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 <[email protected]> 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: [email protected] > >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.
