Enable to reuse mojo without full maven stack

[rmannibucau]

Maven being a constraint and dependency resolution simplicity getting broken with jpms support it will be neat to enable easier pipelines writing and likely to only rely on dep resolution then let integrator to do the pipeline run instead of maven phase based execution graph whichbis suboptimal in all cases

[hendrikebbers]

@rmannibucau can you add some more information to this one?

[rmannibucau]

For me the minimum is to keep maven-plugin-api dependency free (except maven*) and enable it to instantiate a mojo, means decoupling it from plexus and a few other dependencies.
Then it is an integrator work to enable the pipeline of the build.
My idea is to keep the dependency support in ide (model of maven 4) and let the build be done by another way.

[rmannibucau]

side note: it can enable #11 use case which is not use module-info to drive the build - I assume it will use some kind of directives like comments or annotations to complete what's missing from the pom to be functional.

since it breaks the single key feature of maven: static descriptor without any build - to let project be opened in the ide without having a functional build which was one of the biggest pitfall of gradle and advantage of maven.

[gnodet]

What do you mean "full maven stack" ? A mojo is usually injected with a session, project, all kind of things which do not make sense without maven.

The Maven 4 API is nearly usable without maven full stack. See https://github.com/apache/maven/blob/master/maven-api-impl/src/test/java/org/apache/maven/internal/impl/standalone/TestApiStandalone.java

[rmannibucau]

@gnodet goal is to drop most of transitive deps which are not o.a.m from this code (assume it moved to a "main"). Long story short idea is to reuse maven owned code but not depend on conflicting or hard to manage 3rd parties - from plexus to guice.

[gnodet]

Well, that's almost the case now....

[rmannibucau]

Agree but still these ones:

[INFO] +- org.codehaus.plexus:plexus-interpolation:jar:1.27:compile
[INFO] +- com.fasterxml.woodstox:woodstox-core:jar:6.6.2:compile
[INFO] +- org.codehaus.woodstox:stax2-api:jar:4.2.1:compile
[INFO] +- org.slf4j:slf4j-api:jar:2.0.13:compile

Guess the woodstox ones could be excluded with very few effort, slf4j-api can not be critical short term (but guess it should use maven-api instead) but plexus-interpolation is harder to drop but will be critical for that task.

[gnodet]

I agree about plexus-interpolation, imho, an interpolation service could be provided by the API (through a Service available from the Session maybe) and reused by other service implementations. We need to break plexus deps.

For woodstox, it may be possible to be agnostic about the stax implementation (so possibly using the implementation from the JDK), that would require a bit of work.