Prepare for Maven 4

[homberghp]

Description

The current Apache Maven support in NetBeans is tightly bound to Maven 3.x.y.

Maven 4 introduces a number of improvements, one of which is a proper API in a separate package/module.
Moving from maven 3.9.x to maven 4 is not trivial, because of the API changes.
The Apache Maven project strives to be backward compatible, in particular with to respect to the supported Maven Model versions.

We that the introduction of a proper Maven API simplifies integration into NetBeans as Maven client application.

The new integration should :

• Support execution of Maven goals projects based on model versions > 4.0.0
• Support editor hints of a Maven 4 pom.xml file based on model version supported by Maven 4.
• Listening for and understanding of Maven goal execution events.
• Support Maven 4 features introduced with Maven model version >= 4.1.0

This issue will be used to log advancement in this endeavour.

Several suggestions have been made to move NetBeans forward in this direction.
One is to use the mvnw wrapper as execution vehicle for the time.
This can be based on Mavens ExecutorTool and ToolboxTool.
These Maven API interfaces may be usable be used to adapt NetBeans MavenCommandLineExecutor.

Use case/motivation

To move NetBeans forward.

Related issues

Issue #8632

Are you willing to submit a pull request?

Yes, when I have something worth pulling.

[homberghp]

replay #8534 for Maven 4

[neilcsmith-net]

One is to use the mvnw wrapper as execution vehicle for the time.

We already default to using mvnw for the build if it's included in the project.

My suggestion was actually that we might take this opportunity not to bundle the whole of Maven, but just the libraries necessary to run the queries inside the IDE. We don't bundle all of Gradle in the IDE.

[homberghp]

One is to use the mvnw wrapper as execution vehicle for the time.

We already default to using mvnw for the build if it's included in the project.

My suggestion was actually that we might take this opportunity not to bundle the whole of Maven, but just the libraries necessary to run the queries inside the IDE. We don't bundle all of Gradle in the IDE.

If by 'queries' you mean support in the editor to reflect on the Maven model (POM files) to provide hints and errors, then I wholeheartedly agree. This would simplify the NB specific code a lot. AFAIK, running mvnw or mvn does not make a big difference on the command line. It ensures that the wrapped version is the one desired by the project and avoids forcing the user to install maven. It is, of course, a bit of clutter on the users storage, but storage is cheap. Also, the user always has the option to run the (also always) included pom.xml file with a normal maven.

The only things that NB should know about maven is:

• What a valid model file looks like and how to generate hints.
• Understand the feedback given by a maven exec, as in interpreting the maven output.

All in all this might also suggest that an LSP solution might be appropriate.

[neilcsmith-net]

There are a few other things there, in particular working with the dependency graph, and building the relevant classpaths, etc. I guess that might still be achievable using Maven output. In particular if we used the embedded mode of ExecutorTool for some things. I think it comes down to which is the easier approach / least work.

There are also MIMA and Toolbox directly that might be worth looking at. Again comes to looking at how much work is required to modify what we have vs adapt to something else.

I don't know where LSP fits in unless there's an existing third-party project you have in mind?

I don't see mvnw as adding clutter - it's about locking required build versions. Having a version of mvn you don't need is also clutter. The key thing for me is that if we started with using mvnw in new projects, recommending if missing, etc. we could consider upgrading the parsing stuff before Maven 4 final is released. We had a similar thing in the past with RCs of Gradle tooling - if used internally we need to ensure that doesn't "leak" into users' projects.

[jherkel]

@neilcsmith-net There is a problem with mvnw in case of multimodule build. Probably because netbeans cannot recognize maven 4.1.0 pom it cannot locate "root" project. So it tries to use bundled maven. Maybe netbeans can improve the way how it tries to locate mvnw wrapper. I mean to add some fallback strategy if project cannot be parsed.

[neilcsmith-net]

@jherkel NetBeans does not support Maven 4.1.0 POM. The bundled Maven is used to parse the project tree to find potential locations for the wrapper. Could it have a fallback, yes. Should it? IMO, probably not.

If it does have a fallback, it should probably follow the guide at https://maven.apache.org/guides/mini/guide-multiple-subprojects-4.html - "Maven attempts to find the root of a multi-project setup, by traversing upwards in the directory structure until it either finds a POM with a .mvn sibling directory or a POM with the root attribute set to true"

My reasoning for suggesting focus on mvnw is to support building on Maven 3 while bundling Maven 4 (in whole or part, even in non-final state).

[jherkel]

I understand for focusing on mvnw but my "fallback strategy" was meant for meantime. And it also helps with current maven 3 multimodule project in case when parent in pom.xml is wrong. For this case Netbeans also isn't able to locate mvnw.

[asbachb]

Just wanted to add that maven 4 introduces mvnsh which keeps the jvm / maven instance alive.

Would be nice to see an integration when touching the maven plugins.