In NetBeans internally, the project description is a set of queries/SPIs
that provide answers to queries like "what is the classpath for this source
root", or "this is the UI that should be shown for this project". Some of
them are (mostly) language agnostic, some are Java specific, some are
specific to some other languages and/or groups/types of languages. The
queries are generally very versatile, although not completely almighty.
And the support for the particular build/project-types are built using
these queries/SPI, but that's mostly "just" a facade (sometimes a complex
facade, though). In other words, the Maven support "just" reads the
configuration from Maven/pom.xml, and uses the data to answer the queries.
And also know what to call when the user invokes the "Build" action, etc.
And something similar is the case for Gradle, OpenJDK module projects and
MX projects.
But, these are code queries, not a UI and/or configuration file. The
closest user-visible thing to a configuration file for the queries is the
(Java) (Ant) Free-Form Project. But, I would **NOT** recommend using it to
anyone - this is basically a very thin facade over the internal queries,
with effectively no validation, and it is very easy to get to a bad state.
(Esp. if one goes beyond that the UI permits, and starts to configure the
project in XML.)
The thing that may be usable at least for experimentation and/or
small-scale use is the "Java with Ant/Java Project with Existing Sources".
Yes, this is related to Ant, but it can be somewhat detached if needed. It
allows to configure source roots, and the classpath/module path for the
source roots (all the roots with sources have to have the same
configuration, and dtto all the roots with tests). I use it this way in
some cases. It is not very convenient, as one needs to configure things
manually, but works well enough for me in the rare cases I need it.
It should be possible to get things like "Build"/"Run" and even "Debug"
work with a custom build tool with this project. In the build.xml, one can
say something like:
<target name="jar">
<exec executable="echo">
<arg line="Hello, world!" />
</exec>
</target>
And this will be called for the "Build" action.
This configuration can even be put into the VCS, and shared.
For a more widespread and more convenient use, it is IMO better if an IDE
plugin can get/read the configuration directly from the given build
system/build tool, and provide a more tailored experience. Sadly, filling
the queries is not really trivial.
I have some experiments where the (Java) queries are autoconfigured from a
list of commands used (or that would be used, it is not strictly necessary
to run the commands) to build a project. Like, especially the javac
invocations, and (eventually) also the jar tool invocations. That only
solves a part of the build system/tool support. The other parts
include action bindings, so that the "Build" action runs the correct thing,
etc., but the (Java) queries are one of the complex parts. This would be
similar to compile_command.json used for C/C++ projects.
So, if your built system/tool can write a file listing the tool invocations
(command lines, basically) needed to build the projects, and keep that
up-to-date, there may be a possibility to try with my experiment to gain
some more experience.
Jan
On Fri, Sep 19, 2025 at 1:37 AM Blake McBride <[email protected]> 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]> 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
>>
>>
>>
