Again, I agree with standards, and I like standards. I never drift from standards unless there is a specific benefit to do so. In each case I drift, there is a specific benefit to it. IMO, the benefits I gain from the way I am doing things are:
1. The places I drift from the standards are generally super easy to pick up. 2. The benefits gained from the standards drift far, far outweigh the benefits of the standard. --blake On Thu, Sep 18, 2025 at 10:33 PM Laszlo Kishalmi <[email protected]> wrote: > Well, just checked the project. > > It seems to be a hermit one. > > There is a reason why build systems are tend to be declarative. Gradle can > be both declarative and imperative and anything between them. > > `bld` is a perfect tool for hermits. Though it comes with a project > structure recommendation. Even that one is not followed here. Builds should > not be complex. Not even here. If functions are well defined, separated, > then there is no reason to unjar junit jar files, and create something new > out of them, etc. > > I respect that you see the world in your own way. > > > On 9/18/25 16:36, Blake McBride wrote: > > Again, one example of the many reasons I wrote bld. > > Using Maven as a project description for an IDE is not a good idea, IMO. > Maven is too verbose and limited. Gradle is just as bad. > > Maven and Gradle are mostly declarative. bld is imperative. Declarative > systems are generally simpler so long as you are doing the typical things. > As soon as you go outside their box, it either gets incredibly complex real > fast or you just bump up against their limitations. Imperative systems are > generally a bit more complex, but their functionality is unlimited and > their complexity is flat. They can do anything with trivial changes. > Declarative build systems are always limited and inordinately complex when > you go outside their box. > > IMO, imperative build systems are better, period. > > On the other hand, IDE project files are far more declarative. If you > augment them with an imperative element, they can be perfect. > > Trying to use a build system as an IDE project description file works in > very simple cases but falls apart in complex cases. > > It would be best if the industry created a standard, descriptive, simple > project description format that had imperative extensions that are used by > the build system but ignored by the IDE. XML would literally be the worst > format for that file. JSON would be far better. INI file format would be > best. > > Clearly, pom.xml files are inadequate. Perhaps NetBeans can lead the way. > I'd be happy to be part of the team laying out the spec for the file, but I > just don't have enough time to implement it. Let me know if there is > interest. > --blake > > > > On Thu, Sep 18, 2025 at 4:44 PM Martin Desruisseaux > <[email protected]> > <[email protected]> wrote: > >> Le 18/09/2025 à 22:42, Blake McBride a écrit : >> >> If you have *multiple source roots*, Maven itself only supports a >> *single* <sourceDirectory> and <testSourceDirectory> in the <build> >> section. To handle *more than one*, you need to *declare one as the >> “main”* and then use the build-helper-maven-plugin to add the rest. >> >> The above describes Maven 3. There is a new way to declare sources in >> Maven 4, which allows multiple source roots. Maven 4 is not yet GA (latest >> version is 4.0.0-rc-4), not all plugins have been updated, and I don't know >> how advanced is the Maven 4 integration in NetBeans. But I guess that the >> situation will get good improvements in the next 10 months. >> >> Martin >> >> >>
