[ANN] Apache Maven Shade Plugin Version 3.3.0 Released

[Karl Heinz Marbaise]

The Apache Maven team is pleased to announce the release of the
Apache Maven Shade Plugin Version 3.3.0

https://maven.apache.org/plugins/maven-shade-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-shade-plugin
  3.3.0


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-shade-plugin/download.cgi

Release Notes Maven Shade Plugin 3.3.0

https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12348391=Text=12317921

* Bugs:
  * [MSHADE-252] - shadeSourcesContent is broken when combined with
partial relocation
  * [MSHADE-396] - Improve SourceContent Shading

* New Feature:

  * [MSHADE-36] - Add option to include dependency reduced POM instead
of original one

* Improvements:

  * [MSHADE-321] - Always respect 'createDependencyReducedPom' flag
  * [MSHADE-371] - Update Shade
Apache[Notice/LICENSE]ResourceTransformer to use also [NOTICE/LICENSE].md
  * [MSHADE-373] - Source transformation on source jar can break OSGi
resolution due to duplicated bundle name
  * [MSHADE-382] - Add an option to skip execution
  * [MSHADE-391] - Do not modify class files, if nothing was relocated
  * [MSHADE-405] - ShowOverlapping Uses http instead of https

Tasks:

  * [MSHADE-389] - Get rid of old baggage
  * [MSHADE-390] - Implement Sisu index transformer
  * [MSHADE-401] - Improve ServiceResourceTransformer
  * [MSHADE-412] - SimpleRelocator can fail in NPE, in particular with
manifest transformer

Dependency upgrades:

  * [MSHADE-379] - Support Java 16 - upgrade ASM to 9.0
  * [MSHADE-386] - Update JDependency to 2.6.0
  * [MSHADE-407] - Update ASM to 9.2 to support Java 17

Enjoy

- The Apache Maven team

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] New Maven Core API for 4.x

[Romain Manni-Bucau]

Hmm, can mean reviewing on github the actual impact of such a deep breaking
change. If too much outside our own code it can not be an option without a
compat layer for a very long time, if very rare let's mive forward I'd say.
But clearly we need a real plugin api and disable all maven-core classreal
from mojo.

Le mar. 29 mars 2022 à 22:16, Guillaume Nodet  a écrit :

> The immutable model is not the only goal.  One of the main goal is to
> provide a more complete and cleaner API so that we can get rid of
> maven-compat and other legacy stuff, hide the resolver api, etc...
> The immutable model is just a side benefit that we can get while
> refactoring the API, so while I think keeping a compatible layer during a
> period when we could switch plugins is definitely a good idea, I don't
> think keeping that model forever in the new API is the best way forward.
>
> In addition, injecting an immutable model in plugins will definitely allow
> closer control over changes in the model.  For more specific usages or
> modifications on the model, I would think using a plugin extension at an
> earlier stage may be a better option.  For example adding project
> dependencies may require recomputing the project graph and thus needs to be
> controlled by maven, or maybe done in an early stage of the build using a
> build extension but not allowed after the dependency collection has been
> done.
>
> Guillaume
>
> Le mar. 29 mars 2022 à 08:28, Romain Manni-Bucau  a
> écrit :
>
> > I think the number of plugin doing it is not that small, now the question
> > is: what's the difference (technically) between a project you can mutate
> > and a project manager mutating the project state? Idea behind is to NOT
> > inject the MavenProject in any mojo but inject a proxy/decorated instance
> > which can handle the manager and actual project usage as expected by
> maven.
> > The impact being: no change in any plugin nor plugin api but same goal
> > being reached. In other words we have:
> >
> > 1. maven-core which uses whatever he wants to reach the programming model
> > we think is good (immutability)
> > 2. @Parameter MavenProject which becomes an API delegating to 1 (but is
> > never the internal MavenProject instance)
> >
> > (indeed same applies to all models, just took project as an example which
> > is likely more familiar)
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mar. 29 mars 2022 à 00:06, Matt Benson  a écrit :
> >
> > > As a developer I appreciate the concept of immutability. At the same
> > time,
> > > having written more than one (proprietary) plugin that mutates the
> > project
> > > model, I would hate to see my options in this regard diminished
> > > particularly if the future situation were one that forces me to modify
> > the
> > > Maven installation in order to achieve X result. Such a "trapdoor" as
> you
> > > have suggested (to provide a managed mechanism for updating the project
> > > model--presumably this would enable the core engine to be aware of
> > changes)
> > > would hopefully be a sufficient "method of last resort" to permit me to
> > > keep a given plugin "modern" while still performing its essential
> duties.
> > >
> > > Matt
> > >
> > > On Mon, Mar 28, 2022, 12:30 PM Guillaume Nodet 
> > wrote:
> > >
> > > > What I have in mind is that plugins that use the new api would
> receive
> > > the
> > > > immutable model, while plugins that use the old (3.x) api would
> > receive a
> > > > model that would wrap the immutable one. However, I think mutating
> the
> > > > model or the maven project should be done via services provided by
> the
> > > > maven api. That will allow controlling concurrent access,
> interception,
> > > > logging, etc...
> > > > For example, adding a source directory in the new api is done using
> the
> > > > ProjectManager, which I think should be the place where the project
> is
> > > > mutated:
> > > >
> > > >
> > > >
> > >
> >
> https://github.com/gnodet/maven/blob/m-api-immutable/api/maven-api-core/src/main/java/org/apache/maven/api/services/ProjectManager.java
> > > > I assume the number of plugins that mutate the project is small.  I
> > think
> > > > the best way would be to provide atomic apis for mutating the parts
> > that
> > > > need to be so that maven can have tighter control, but we can always
> > > > provide an api to replace the Project or the Model with a new copy if
> > > > needed so that any plugin can have the possibility to mutate those.
> > > > Does that make sense?
> > > >
> > > > Guillaume
> > > >
> > > > Le lun. 28 mars 2022 à 13:47, Matt Benson  a
> > écrit :
> > > >
> > > > > So in the new API, what kind of 

Re: [DISCUSS] New Maven Core API for 4.x

[Guillaume Nodet]

The immutable model is not the only goal.  One of the main goal is to
provide a more complete and cleaner API so that we can get rid of
maven-compat and other legacy stuff, hide the resolver api, etc...
The immutable model is just a side benefit that we can get while
refactoring the API, so while I think keeping a compatible layer during a
period when we could switch plugins is definitely a good idea, I don't
think keeping that model forever in the new API is the best way forward.

In addition, injecting an immutable model in plugins will definitely allow
closer control over changes in the model.  For more specific usages or
modifications on the model, I would think using a plugin extension at an
earlier stage may be a better option.  For example adding project
dependencies may require recomputing the project graph and thus needs to be
controlled by maven, or maybe done in an early stage of the build using a
build extension but not allowed after the dependency collection has been
done.

Guillaume

Le mar. 29 mars 2022 à 08:28, Romain Manni-Bucau  a
écrit :

> I think the number of plugin doing it is not that small, now the question
> is: what's the difference (technically) between a project you can mutate
> and a project manager mutating the project state? Idea behind is to NOT
> inject the MavenProject in any mojo but inject a proxy/decorated instance
> which can handle the manager and actual project usage as expected by maven.
> The impact being: no change in any plugin nor plugin api but same goal
> being reached. In other words we have:
>
> 1. maven-core which uses whatever he wants to reach the programming model
> we think is good (immutability)
> 2. @Parameter MavenProject which becomes an API delegating to 1 (but is
> never the internal MavenProject instance)
>
> (indeed same applies to all models, just took project as an example which
> is likely more familiar)
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mar. 29 mars 2022 à 00:06, Matt Benson  a écrit :
>
> > As a developer I appreciate the concept of immutability. At the same
> time,
> > having written more than one (proprietary) plugin that mutates the
> project
> > model, I would hate to see my options in this regard diminished
> > particularly if the future situation were one that forces me to modify
> the
> > Maven installation in order to achieve X result. Such a "trapdoor" as you
> > have suggested (to provide a managed mechanism for updating the project
> > model--presumably this would enable the core engine to be aware of
> changes)
> > would hopefully be a sufficient "method of last resort" to permit me to
> > keep a given plugin "modern" while still performing its essential duties.
> >
> > Matt
> >
> > On Mon, Mar 28, 2022, 12:30 PM Guillaume Nodet 
> wrote:
> >
> > > What I have in mind is that plugins that use the new api would receive
> > the
> > > immutable model, while plugins that use the old (3.x) api would
> receive a
> > > model that would wrap the immutable one. However, I think mutating the
> > > model or the maven project should be done via services provided by the
> > > maven api. That will allow controlling concurrent access, interception,
> > > logging, etc...
> > > For example, adding a source directory in the new api is done using the
> > > ProjectManager, which I think should be the place where the project is
> > > mutated:
> > >
> > >
> > >
> >
> https://github.com/gnodet/maven/blob/m-api-immutable/api/maven-api-core/src/main/java/org/apache/maven/api/services/ProjectManager.java
> > > I assume the number of plugins that mutate the project is small.  I
> think
> > > the best way would be to provide atomic apis for mutating the parts
> that
> > > need to be so that maven can have tighter control, but we can always
> > > provide an api to replace the Project or the Model with a new copy if
> > > needed so that any plugin can have the possibility to mutate those.
> > > Does that make sense?
> > >
> > > Guillaume
> > >
> > > Le lun. 28 mars 2022 à 13:47, Matt Benson  a
> écrit :
> > >
> > > > So in the new API, what kind of component would receive a mutable
> model
> > > if
> > > > not a plugin? I.e., what would be the correct mechanism for enhancing
> > the
> > > > project model at runtime?
> > > >
> > > > Matt
> > > >
> > > > On Mon, Mar 28, 2022, 4:33 AM Guillaume Nodet 
> > wrote:
> > > >
> > > > > Hi everyone,
> > > > >
> > > > > Last week, I worked on a fully immutable maven model. The results
> are
> > > > > available at [1].  The modifications required in modello were a bit
> > too
> > > > > complicated, so I ended up using the modello models, but generating
> > the
> > > > > models, readers and 

[RESULT] [VOTE] - Release Apache Maven Shade Plugin Version 3.3.0

[Karl Heinz Marbaise]

Hi,

The vote has passed with the following result:

+1: Enrico Olivelli, Romain Manni-Bucau, Slawomir Jaranowski, Hervé
Boutemy, Philipp Dallig, Karl Heinz Marbaise, Sylwester Lachiewicz,
Olivier Lamy

PMC quorum: reached

I will promote the artifacts to the central repo.

Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Surprises on maven 4

[Romain Manni-Bucau]

Le mar. 29 mars 2022 à 09:40, Maarten Mulders  a
écrit :

> Hi,
>
> Let me only chime in on your first question, as I have no idea about the
> latter one...
>
> On 28/03/2022 10:19, Romain Manni-Bucau wrote:
> > Hi all,
> >
> > For an output check (thanks again Michael for the pointer), I tested
> maven
> > master/4 this morning and get a few question marks:
> >
> > 1. I know we warn when a plugin has no lock version but it also means we
> > implicitly force to define a plugin and warn we defined it, this does not
> > make much sense from an user point of view for me so either we should
> keep
> > a default version aligned on maven version or just not enforce any plugin
> > if not defined in the pom (means if I did not define install plugin, mvn
> > install wouldn't install - don't think it is good but it is not worse
> than
> > warning for an implicit definition when something implicit had been done
> > IMHO)
>
> As far as I know, we warn when a user did not explicitly lock the
> version of plugin that they inherit through the Maven Super POM. When
> the user locks that version using pluginManagement, the warning is gone.
>
> So yes, Maven still defines a default version for e.g. the resources or
> the compiler plugin, but it explains to the user: relying on this makes
> your build less stable, and this is how you can improve.
>
> I think that makes sense: it makes the build more deterministic, as it
> is no longer dependent on the version of Maven that a user has. I'm not
> sure what exactly doesn't make sense in this setup?
>

If you do something implicit then you should do something implicit or not
do it right?
So if you binding implicitly some plugins your must not emit any warning or
it means you are not sure about what you do.

I certainly understand the rational (the fear it breaks with some later
maven version for ex) but this is something we have a full control and we
can guarantee to stay backward compatible for supported maven versions.

Concretely, no default should lead to any warning and maven being
"convention over configuration", conventions should work which implies we
should:

1. only provide warning-free lifecycles
2. probably enforce a default encoding (UTF-8?)

If I need to define a ton of plugins to get rid of the warnings (to get
started warning free I need 6-7 plugins???), it can be saner to drop
lifecycles from maven and move to extensions now we have them, this way the
entry cost is a single extension (jar-extension for ex) which is a bit
better than the current user experience but still weirdish as experience
IMHO.

For any user, default bindings are part of maven-core (even if it is not in
terms of project/module but it is since we depend on it) so not having it
integrated OOTB (warnings) is negative IMHO so something we should clean up
before 4.0.0.

I'm not sure the solution is to get back to previous behavior for built-in
lifecycles or to move to something like extensions but not working properly
OOTB breaks maven design IMHO. It was already hurting for the encoding in
v2/v3 but if it becomes the same for plugins the entrycost will keep
increasing and I hope it does not go that path.


>
> > 2. I was not able to reproduce it after an install but I got at first
> build
> > this error (mvn clean install -DskipTests -T8):
> >
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> > (default-install) on project : Execution default-install of goal
> > org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install failed:
> > Unable to provision, see the following errors:
> > [ERROR]
> > [ERROR] 1) Error in custom provider, java.lang.IllegalStateException
> > [ERROR]   at ClassRealm[plexus.core, parent: null] (via modules:
> > org.eclipse.sisu.wire.WireModule ->
> > org.eclipse.sisu.plexus.PlexusBindingModule ->
> > org.apache.maven.session.scope.internal.SessionScopeModule)
> > [ERROR]   while locating org.apache.maven.execution.MavenSession
> > [ERROR]
> > [ERROR] 1 error
> > [ERROR] -> [Help 1]
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> > (default-install) on project orchestrator: Execution default-install of
> > goal org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> failed:
> > Unable to provision, see the following errors:
> > [ERROR]
> > [ERROR] 1) Error in custom provider, java.lang.IllegalStateException
> > [ERROR]   at ClassRealm[plexus.core, parent: null] (via modules:
> > org.eclipse.sisu.wire.WireModule ->
> > org.eclipse.sisu.plexus.PlexusBindingModule ->
> > org.apache.maven.session.scope.internal.SessionScopeModule)
> > [ERROR]   while locating org.apache.maven.execution.MavenSession
> > [ERROR]
> > [ERROR] 1 error
> >
> > I'm a bit suspicious about this last one since there is a new resolution
> of
> > project modules, anyone with some idea?
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> > 

Re: Surprises on maven 4

[Maarten Mulders]

Hi,

Let me only chime in on your first question, as I have no idea about the 
latter one...


On 28/03/2022 10:19, Romain Manni-Bucau wrote:

Hi all,

For an output check (thanks again Michael for the pointer), I tested maven
master/4 this morning and get a few question marks:

1. I know we warn when a plugin has no lock version but it also means we
implicitly force to define a plugin and warn we defined it, this does not
make much sense from an user point of view for me so either we should keep
a default version aligned on maven version or just not enforce any plugin
if not defined in the pom (means if I did not define install plugin, mvn
install wouldn't install - don't think it is good but it is not worse than
warning for an implicit definition when something implicit had been done
IMHO)


As far as I know, we warn when a user did not explicitly lock the 
version of plugin that they inherit through the Maven Super POM. When 
the user locks that version using pluginManagement, the warning is gone.


So yes, Maven still defines a default version for e.g. the resources or 
the compiler plugin, but it explains to the user: relying on this makes 
your build less stable, and this is how you can improve.


I think that makes sense: it makes the build more deterministic, as it 
is no longer dependent on the version of Maven that a user has. I'm not 
sure what exactly doesn't make sense in this setup?



2. I was not able to reproduce it after an install but I got at first build
this error (mvn clean install -DskipTests -T8):

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
(default-install) on project : Execution default-install of goal
org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install failed:
Unable to provision, see the following errors:
[ERROR]
[ERROR] 1) Error in custom provider, java.lang.IllegalStateException
[ERROR]   at ClassRealm[plexus.core, parent: null] (via modules:
org.eclipse.sisu.wire.WireModule ->
org.eclipse.sisu.plexus.PlexusBindingModule ->
org.apache.maven.session.scope.internal.SessionScopeModule)
[ERROR]   while locating org.apache.maven.execution.MavenSession
[ERROR]
[ERROR] 1 error
[ERROR] -> [Help 1]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
(default-install) on project orchestrator: Execution default-install of
goal org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install failed:
Unable to provision, see the following errors:
[ERROR]
[ERROR] 1) Error in custom provider, java.lang.IllegalStateException
[ERROR]   at ClassRealm[plexus.core, parent: null] (via modules:
org.eclipse.sisu.wire.WireModule ->
org.eclipse.sisu.plexus.PlexusBindingModule ->
org.apache.maven.session.scope.internal.SessionScopeModule)
[ERROR]   while locating org.apache.maven.execution.MavenSession
[ERROR]
[ERROR] 1 error

I'm a bit suspicious about this last one since there is a new resolution of
project modules, anyone with some idea?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book




Thanks,


Maarten

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] New Maven Core API for 4.x

[Mark Derricutt]

I’m wondering (off the cuff thought here) if having a stronger design
difference between a standard Mojo, and an Extension might be useful?

As general mojo/plugin - having an injected immutable MavenProject *view* is
probably fine, but for an extension I probably want a mutable
MavenProject.Builder or the like - that can be manipulated ( parents
injected/rewritten, additional tasks/plugins injected, dependencies vetted).

Or, a *subtle* change in terminology but with possible big-ups - rather
than *immutable*, have a *persistent* project model - similar to persistent
collections in Scala and other functional languages, they’re immutable, but
they have modification commands that return new, updated instances.

Having a defined model processor could go:  baseModel -> extension A ->
extension B -> reactor -> build-all-the-things.


-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree


On 29/03/2022 at 7:28:15 PM, Romain Manni-Bucau 
wrote:

> I think the number of plugin doing it is not that small, now the question
> is: what's the difference (technically) between a project you can mutate
> and a project manager mutating the project state? Idea behind is to NOT
> inject the MavenProject in any mojo but inject a proxy/decorated instance
> which can handle the manager and actual project usage as expected by maven.
> The impact being: no change in any plugin nor plugin api but same goal
> being reached. In other words we have:
>
> 1. maven-core which uses whatever he wants to reach the programming model
> we think is good (immutability)
> 2. @Parameter MavenProject which becomes an API delegating to 1 (but is
> never the internal MavenProject instance)
>
> (indeed same applies to all models, just took project as an example which
> is likely more familiar)
>
>
>

Re: [DISCUSS] New Maven Core API for 4.x

[Romain Manni-Bucau]

I think the number of plugin doing it is not that small, now the question
is: what's the difference (technically) between a project you can mutate
and a project manager mutating the project state? Idea behind is to NOT
inject the MavenProject in any mojo but inject a proxy/decorated instance
which can handle the manager and actual project usage as expected by maven.
The impact being: no change in any plugin nor plugin api but same goal
being reached. In other words we have:

1. maven-core which uses whatever he wants to reach the programming model
we think is good (immutability)
2. @Parameter MavenProject which becomes an API delegating to 1 (but is
never the internal MavenProject instance)

(indeed same applies to all models, just took project as an example which
is likely more familiar)

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mar. 29 mars 2022 à 00:06, Matt Benson  a écrit :

> As a developer I appreciate the concept of immutability. At the same time,
> having written more than one (proprietary) plugin that mutates the project
> model, I would hate to see my options in this regard diminished
> particularly if the future situation were one that forces me to modify the
> Maven installation in order to achieve X result. Such a "trapdoor" as you
> have suggested (to provide a managed mechanism for updating the project
> model--presumably this would enable the core engine to be aware of changes)
> would hopefully be a sufficient "method of last resort" to permit me to
> keep a given plugin "modern" while still performing its essential duties.
>
> Matt
>
> On Mon, Mar 28, 2022, 12:30 PM Guillaume Nodet  wrote:
>
> > What I have in mind is that plugins that use the new api would receive
> the
> > immutable model, while plugins that use the old (3.x) api would receive a
> > model that would wrap the immutable one. However, I think mutating the
> > model or the maven project should be done via services provided by the
> > maven api. That will allow controlling concurrent access, interception,
> > logging, etc...
> > For example, adding a source directory in the new api is done using the
> > ProjectManager, which I think should be the place where the project is
> > mutated:
> >
> >
> >
> https://github.com/gnodet/maven/blob/m-api-immutable/api/maven-api-core/src/main/java/org/apache/maven/api/services/ProjectManager.java
> > I assume the number of plugins that mutate the project is small.  I think
> > the best way would be to provide atomic apis for mutating the parts that
> > need to be so that maven can have tighter control, but we can always
> > provide an api to replace the Project or the Model with a new copy if
> > needed so that any plugin can have the possibility to mutate those.
> > Does that make sense?
> >
> > Guillaume
> >
> > Le lun. 28 mars 2022 à 13:47, Matt Benson  a écrit :
> >
> > > So in the new API, what kind of component would receive a mutable model
> > if
> > > not a plugin? I.e., what would be the correct mechanism for enhancing
> the
> > > project model at runtime?
> > >
> > > Matt
> > >
> > > On Mon, Mar 28, 2022, 4:33 AM Guillaume Nodet 
> wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > Last week, I worked on a fully immutable maven model. The results are
> > > > available at [1].  The modifications required in modello were a bit
> too
> > > > complicated, so I ended up using the modello models, but generating
> the
> > > > models, readers and writers using velocity templates. The templates
> are
> > > > actually way easier to modify than the modello generators, as you can
> > see
> > > > in the template generating the model [2] or the reader [3].  This
> also
> > > > allows generating mergers and transformers.
> > > > This also allows getting rid completely of plexus-utils dependency in
> > the
> > > > API.
> > > >
> > > > This all looks quite nice to me, however those changes are definitely
> > > > incompatible, which means plugins will just break at runtime or
> compile
> > > > time if they try to instantiate or modify objects from the model. If
> > > > there's a consensus on trying to move forward with an immutable
> model,
> > I
> > > > can investigate generating this immutable model into a separate new
> > > package
> > > > and only use it for the new API, and rewrite the mutable model by
> > > wrapping
> > > > the immutable one. This would allow a smoother integration /
> migration.
> > > >
> > > > Feedback welcomed !
> > > >
> > > > Cheers,
> > > > Guillaume Nodet
> > > >
> > > > [1] https://github.com/gnodet/maven/tree/m-api-immutable
> > > > [2]
> > > >
> > > >
> > >
> >
> https://github.com/gnodet/maven/blob/m-api-immutable/api/maven-api-model/src/main/mdo/model.vm
> > > > [3]