maven daemon support

[mbien]

added minimal support for https://github.com/mvndaemon/mvnd

maven home has the following layout:

bin/mvn
lib/*.jar

while mvnd home looks like:

bin/mvnd
mvn/  <- bundled maven home

This PR allows users to set a mvnd home as a maven home, NetBeans will then use mvnd and also be able to query the maven version from the bundled maven home.

did a little bit of manual testing and it seems that everything is working fine.

potentially related jira issue:
https://issues.apache.org/jira/browse/NETBEANS-4746

[ebarboni]

Seems related to #3198. Maybe good to synchronize idea

[neilcsmith-net]

@ebarboni I'm not sure they need synchronizing. I don't think this will conflict having looked at the changes. The mvnw support kicks in on the project level when it's there, so should bypass the code in this PR entirely.

[mbien]

might resolve https://issues.apache.org/jira/browse/NETBEANS-4746

[mbien]

two issues encountered while working with mvnd:

• mvnd prints a dumb-terminal warning on every run
• mvnd's output is formatted differently, NB does not hyperlink exceptions properly

[sdedic]

What about distributing mvnd instead of maven ;) in NetBeans ?

[mbien]

What about distributing mvnd instead of maven ;) in NetBeans ?

not sure if i would recommend doing this tbh. First of all, there is a chance that mvnd will merge with maven in the next major version of maven (so i heard). Also, if mvnw takes off, it will be just a flag and everything downloads behind the scene anyway - no need to bundle anything.

There is also the issue with mvnd being MT, which will cause build failures on some projects or plugin combinations. So it can't be made default. I tested it on some dusty projects and not all of them built reliably with mvnd.

the best strategy might be to wait a bit longer while supporting a little bit of everything. If mvnd merges with maven and mvnw takes off... things might get simpler, and NB could remove/unify some code.

[jglick]

I have used mvnd in some cases where it made a big difference, though I have also come across weird cases where it seems to produce different results than mvn (even after disabling multithreading), so I would be cautious about switching to it by default.

[sdedic]

let me rephrase: as mvnd contains (?) mvn as its subset, we could eventually distribute mvnd (which includes mvn @ 3.8.2 at the moment, an upgrade from the current bundled 3.6.3), and get both: default maven, configurable mvnd

[mbien]

let me rephrase: as mvnd contains (?) mvn as its subset, we could eventually distribute mvnd (which includes mvn @ 3.8.2 at the moment, an upgrade from the current bundled 3.6.3), and get both: default maven, configurable mvnd

sure, I tested this PR with that config. if you set path to mvnd/mvn/ you get maven, if you set path to mvnd/ you get mvnd. I don't have anything against it.
My point simply was that if maven 4 going to be released with mvnd and mvnw in it, all this code would be dropped anyway and there will be hopefully one executable with different flags for different modes + mvnd should not be the NB default.

But if there is an easy way to bundle the mvnd+mvn combo in another PR and set the paths accordingly by default, why not. Just don't put too much effort into it i would say ;)

[mbien]

this might be too risky to be merged for 12.6. I did only basic clean/build/run manual testing with it.

[sdedic]

Looks good.

[mbien]

mvnd 0.7.1 seems to be working better, the console output is very similar to regular maven and most simple projects I tested worked fine. (roller selenium tests didn't work with mvnd for example but this is not NB' fault)

mvnd also recently became an apache project

rebased this PR to latest master. All tests are green. I think we could integrate this as minimal/experimental feature.

[jglick]

Got

java.lang.NullPointerException
	at org.netbeans.modules.maven.execute.CommandLineOutputHandler.trimTree(CommandLineOutputHandler.java:548)
	at org.netbeans.modules.maven.execute.CommandLineOutputHandler.processExecEvent(CommandLineOutputHandler.java:456)
	at org.netbeans.modules.maven.execute.CommandLineOutputHandler.access$300(CommandLineOutputHandler.java:74)
	at org.netbeans.modules.maven.execute.CommandLineOutputHandler$Output.run(CommandLineOutputHandler.java:276)
	at …