You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Guillaume Nodet <gn...@apache.org> on 2022/03/14 07:59:08 UTC
[DISCUSS] New Maven Core API for 4.x
Hi everyone,
As Michael hinted at this new API in the "[DISCUSS] Radical Fast Forward to
3.5.4" thread, I'd like to start the discussion around it.
Over the past weeks, I've worked on an experimental API for Maven 4.x.
The goals are multiple :
* fix some problems with designs that do not work well with multithreading
* offer a way to finally get rid of deprecated code
* offer a complete API (which would deprecate m-artifact-transfer,
m-dependency-tree)
* offer an homogeneous and a bit more modern API
* completely hide the maven-resolver, so that it can finally upgrade to a
v2 with the package renamed without too much disturbance
The goal would be to extract the models and API in a separate project with
a much lower release cycle, as those rarely change, but are currently
released with each version of maven.
The current API can be seen at [1]. Note that the plugins API has also
been included within the new API and the plugin tools have been updated so
that the maven-plugin-plugin supports both v3 api and the new v4 api. A
new flag has been added to the MojoDescriptor to know if the plugin is
using the old or the new api. The plugin testing harness tools have been
updated to junit 5 and now provide a few annotations [2] to help writing
plugin tests [3]. The maven-core has been enhanced to support loading
those new v4 plugins along with the v3 ones, which means they can work
side-by-side in the same build. This is done by implementing the new API
by wrapping the v3 implementation classes (such as MavenSession,
MavenProject, etc...) [4].
I've ported a few plugins such as clean [5], install [6], deploy [7] as a
proof-of-concept that this actually works.
The very rough goal would be to to have multiple phases:
* continue the work on this API so that it can actually cover all use
cases for plugins, create a new project with the new API and models, make
sure plugins can work correctly with the new API / implementation
* release the API, then maven-core supporting the new API
* upgrade plugins to the new API, deprecate old components and API
* once all plugins have migrated to the new API, switch maven-core
implementation to the new API
I'm eager to hear your thoughts !
[1]
https://github.com/apache/maven/tree/mvn4/maven-core-api/src/main/java/org/apache/maven/api
[2]
https://github.com/apache/maven-plugin-testing/tree/mvn4/maven-plugin-testing-harness/src/main/java/org/apache/maven/api/plugin/testing
[3]
https://github.com/apache/maven-deploy-plugin/blob/mvn4/src/test/java/org/apache/maven/plugins/deploy/DeployFileMojoTest.java
[4]
https://github.com/apache/maven/tree/mvn4/maven-core/src/main/java/org/apache/maven/internal/impl
[5] https://github.com/apache/maven-clean-plugin/tree/mvn4/
[6] https://github.com/apache/maven-install-plugin/tree/mvn4/
[7] https://github.com/apache/maven-deploy-plugin/tree/mvn4/
--
------------------------
Guillaume Nodet
Re: [DISCUSS] New Maven Core API for 4.x
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1 to move that way but also +1 to keep plugins working (I don't see all
plugins of the ecosystem being rewritten within 5 years so a light plugin
compat layer would be neat).
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le lun. 28 mars 2022 à 11:33, Guillaume Nodet <gn...@apache.org> a écrit :
> 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]
>
> https://github.com/gnodet/maven/blob/m-api-immutable/maven-model/src/main/mdo/reader-ex.vm
>
> Le lun. 14 mars 2022 à 08:59, Guillaume Nodet <gn...@apache.org> a écrit
> :
>
> > Hi everyone,
> >
> > As Michael hinted at this new API in the "[DISCUSS] Radical Fast Forward
> > to 3.5.4" thread, I'd like to start the discussion around it.
> >
> > Over the past weeks, I've worked on an experimental API for Maven 4.x.
> > The goals are multiple :
> > * fix some problems with designs that do not work well with
> > multithreading
> > * offer a way to finally get rid of deprecated code
> > * offer a complete API (which would deprecate m-artifact-transfer,
> > m-dependency-tree)
> > * offer an homogeneous and a bit more modern API
> > * completely hide the maven-resolver, so that it can finally upgrade to
> > a v2 with the package renamed without too much disturbance
> >
> > The goal would be to extract the models and API in a separate project
> with
> > a much lower release cycle, as those rarely change, but are currently
> > released with each version of maven.
> >
> > The current API can be seen at [1]. Note that the plugins API has also
> > been included within the new API and the plugin tools have been updated
> so
> > that the maven-plugin-plugin supports both v3 api and the new v4 api. A
> > new flag has been added to the MojoDescriptor to know if the plugin is
> > using the old or the new api. The plugin testing harness tools have been
> > updated to junit 5 and now provide a few annotations [2] to help writing
> > plugin tests [3]. The maven-core has been enhanced to support loading
> > those new v4 plugins along with the v3 ones, which means they can work
> > side-by-side in the same build. This is done by implementing the new API
> > by wrapping the v3 implementation classes (such as MavenSession,
> > MavenProject, etc...) [4].
> > I've ported a few plugins such as clean [5], install [6], deploy [7] as a
> > proof-of-concept that this actually works.
> >
> > The very rough goal would be to to have multiple phases:
> > * continue the work on this API so that it can actually cover all use
> > cases for plugins, create a new project with the new API and models, make
> > sure plugins can work correctly with the new API / implementation
> > * release the API, then maven-core supporting the new API
> > * upgrade plugins to the new API, deprecate old components and API
> > * once all plugins have migrated to the new API, switch maven-core
> > implementation to the new API
> >
> > I'm eager to hear your thoughts !
> >
> > [1]
> >
> https://github.com/apache/maven/tree/mvn4/maven-core-api/src/main/java/org/apache/maven/api
> > [2]
> >
> https://github.com/apache/maven-plugin-testing/tree/mvn4/maven-plugin-testing-harness/src/main/java/org/apache/maven/api/plugin/testing
> > [3]
> >
> https://github.com/apache/maven-deploy-plugin/blob/mvn4/src/test/java/org/apache/maven/plugins/deploy/DeployFileMojoTest.java
> > [4]
> >
> https://github.com/apache/maven/tree/mvn4/maven-core/src/main/java/org/apache/maven/internal/impl
> > [5] https://github.com/apache/maven-clean-plugin/tree/mvn4/
> > [6] https://github.com/apache/maven-install-plugin/tree/mvn4/
> > [7] https://github.com/apache/maven-deploy-plugin/tree/mvn4/
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
>
Re: [DISCUSS] New Maven Core API for 4.x
Posted by Guillaume Nodet <gn...@apache.org>.
I've raised a PR with the new immutable model at [1]. The new API would
only use the immutable model, while the old API would use the old model
rewritten to wrap the immutable model.
There are no real changes in the tests or integration tests (apart from 1
removed test), so this is really fully compatible.
[1] https://github.com/apache/maven/pull/703
Le lun. 28 mars 2022 à 11:33, Guillaume Nodet <gn...@apache.org> a écrit :
> 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]
> https://github.com/gnodet/maven/blob/m-api-immutable/maven-model/src/main/mdo/reader-ex.vm
>
> Le lun. 14 mars 2022 à 08:59, Guillaume Nodet <gn...@apache.org> a
> écrit :
>
>> Hi everyone,
>>
>> As Michael hinted at this new API in the "[DISCUSS] Radical Fast Forward
>> to 3.5.4" thread, I'd like to start the discussion around it.
>>
>> Over the past weeks, I've worked on an experimental API for Maven 4.x.
>> The goals are multiple :
>> * fix some problems with designs that do not work well with
>> multithreading
>> * offer a way to finally get rid of deprecated code
>> * offer a complete API (which would deprecate m-artifact-transfer,
>> m-dependency-tree)
>> * offer an homogeneous and a bit more modern API
>> * completely hide the maven-resolver, so that it can finally upgrade to
>> a v2 with the package renamed without too much disturbance
>>
>> The goal would be to extract the models and API in a separate project
>> with a much lower release cycle, as those rarely change, but are currently
>> released with each version of maven.
>>
>> The current API can be seen at [1]. Note that the plugins API has also
>> been included within the new API and the plugin tools have been updated so
>> that the maven-plugin-plugin supports both v3 api and the new v4 api. A
>> new flag has been added to the MojoDescriptor to know if the plugin is
>> using the old or the new api. The plugin testing harness tools have been
>> updated to junit 5 and now provide a few annotations [2] to help writing
>> plugin tests [3]. The maven-core has been enhanced to support loading
>> those new v4 plugins along with the v3 ones, which means they can work
>> side-by-side in the same build. This is done by implementing the new API
>> by wrapping the v3 implementation classes (such as MavenSession,
>> MavenProject, etc...) [4].
>> I've ported a few plugins such as clean [5], install [6], deploy [7] as a
>> proof-of-concept that this actually works.
>>
>> The very rough goal would be to to have multiple phases:
>> * continue the work on this API so that it can actually cover all use
>> cases for plugins, create a new project with the new API and models, make
>> sure plugins can work correctly with the new API / implementation
>> * release the API, then maven-core supporting the new API
>> * upgrade plugins to the new API, deprecate old components and API
>> * once all plugins have migrated to the new API, switch maven-core
>> implementation to the new API
>>
>> I'm eager to hear your thoughts !
>>
>> [1]
>> https://github.com/apache/maven/tree/mvn4/maven-core-api/src/main/java/org/apache/maven/api
>> [2]
>> https://github.com/apache/maven-plugin-testing/tree/mvn4/maven-plugin-testing-harness/src/main/java/org/apache/maven/api/plugin/testing
>> [3]
>> https://github.com/apache/maven-deploy-plugin/blob/mvn4/src/test/java/org/apache/maven/plugins/deploy/DeployFileMojoTest.java
>> [4]
>> https://github.com/apache/maven/tree/mvn4/maven-core/src/main/java/org/apache/maven/internal/impl
>> [5] https://github.com/apache/maven-clean-plugin/tree/mvn4/
>> [6] https://github.com/apache/maven-install-plugin/tree/mvn4/
>> [7] https://github.com/apache/maven-deploy-plugin/tree/mvn4/
>>
>> --
>> ------------------------
>> Guillaume Nodet
>>
>>
>
> --
> ------------------------
> Guillaume Nodet
>
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] New Maven Core API for 4.x
Posted by Mark Derricutt <ma...@talios.com>.
We’re over at https://github.com/repaint-io/maven-tiles
What we’re doing is essential “evil” and mixing in “tiles” as implicit
parents.
It’s it’s no longer possible with 4.x - and if 4.x could provide something
similar, with a transition path we could document, I’m down with sunsetting
the project for 4.x+.
Mark
--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree
On 29/03/2022 at 8:53:06 AM, Guillaume Nodet <gn...@apache.org> wrote:
> Le lun. 28 mars 2022 à 21:22, Mark Derricutt <ma...@talios.com> a écrit :
>
> I wonder how much of this will break what we do with the
>
> tiles-maven-plugin, where we essentially “inject” parents into the model
>
> via a maven extension.
>
>
>
> Interesting. Do you have a pointer to that plugin's source code ?
>
> Guillaume
>
>
Re: [DISCUSS] New Maven Core API for 4.x
Posted by Guillaume Nodet <gn...@apache.org>.
Le lun. 28 mars 2022 à 21:22, Mark Derricutt <ma...@talios.com> a écrit :
> I wonder how much of this will break what we do with the
> tiles-maven-plugin, where we essentially “inject” parents into the model
> via a maven extension.
>
Interesting. Do you have a pointer to that plugin's source code ?
Guillaume
>
> I remember I was seeing some odd issues under earlier builds of 4.x as well
> some time ago but will need to refresh my memory on what that was now.
> Something about properties no longer passing down to those injected parents
> if I recall.
>
> Mark
>
> --
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree
>
>
> On 29/03/2022 at 6:30:24 AM, Guillaume Nodet <gn...@apache.org> 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:
> >
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] New Maven Core API for 4.x
Posted by Mark Derricutt <ma...@talios.com>.
I wonder how much of this will break what we do with the
tiles-maven-plugin, where we essentially “inject” parents into the model
via a maven extension.
I remember I was seeing some odd issues under earlier builds of 4.x as well
some time ago but will need to refresh my memory on what that was now.
Something about properties no longer passing down to those injected parents
if I recall.
Mark
--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree
On 29/03/2022 at 6:30:24 AM, Guillaume Nodet <gn...@apache.org> 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:
>
Re: [DISCUSS] New Maven Core API for 4.x
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <gn...@apache.org> 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 <rm...@gmail.com> 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 <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le mar. 29 mars 2022 à 00:06, Matt Benson <mb...@apache.org> 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 <gn...@apache.org>
> > 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 <mb...@apache.org> 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 <gn...@apache.org>
> > > 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]
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/gnodet/maven/blob/m-api-immutable/maven-model/src/main/mdo/reader-ex.vm
> > > > > >
> > > > > > Le lun. 14 mars 2022 à 08:59, Guillaume Nodet <gnodet@apache.org
> >
> > a
> > > > > écrit
> > > > > > :
> > > > > >
> > > > > > > Hi everyone,
> > > > > > >
> > > > > > > As Michael hinted at this new API in the "[DISCUSS] Radical
> Fast
> > > > > Forward
> > > > > > > to 3.5.4" thread, I'd like to start the discussion around it.
> > > > > > >
> > > > > > > Over the past weeks, I've worked on an experimental API for
> Maven
> > > > 4.x.
> > > > > > > The goals are multiple :
> > > > > > > * fix some problems with designs that do not work well with
> > > > > > > multithreading
> > > > > > > * offer a way to finally get rid of deprecated code
> > > > > > > * offer a complete API (which would deprecate
> > > m-artifact-transfer,
> > > > > > > m-dependency-tree)
> > > > > > > * offer an homogeneous and a bit more modern API
> > > > > > > * completely hide the maven-resolver, so that it can finally
> > > > upgrade
> > > > > to
> > > > > > > a v2 with the package renamed without too much disturbance
> > > > > > >
> > > > > > > The goal would be to extract the models and API in a separate
> > > project
> > > > > > with
> > > > > > > a much lower release cycle, as those rarely change, but are
> > > currently
> > > > > > > released with each version of maven.
> > > > > > >
> > > > > > > The current API can be seen at [1]. Note that the plugins API
> > has
> > > > also
> > > > > > > been included within the new API and the plugin tools have been
> > > > updated
> > > > > > so
> > > > > > > that the maven-plugin-plugin supports both v3 api and the new
> v4
> > > api.
> > > > > A
> > > > > > > new flag has been added to the MojoDescriptor to know if the
> > plugin
> > > > is
> > > > > > > using the old or the new api. The plugin testing harness tools
> > > have
> > > > > been
> > > > > > > updated to junit 5 and now provide a few annotations [2] to
> help
> > > > > writing
> > > > > > > plugin tests [3]. The maven-core has been enhanced to support
> > > > loading
> > > > > > > those new v4 plugins along with the v3 ones, which means they
> can
> > > > work
> > > > > > > side-by-side in the same build. This is done by implementing
> the
> > > new
> > > > > API
> > > > > > > by wrapping the v3 implementation classes (such as
> MavenSession,
> > > > > > > MavenProject, etc...) [4].
> > > > > > > I've ported a few plugins such as clean [5], install [6],
> deploy
> > > [7]
> > > > > as a
> > > > > > > proof-of-concept that this actually works.
> > > > > > >
> > > > > > > The very rough goal would be to to have multiple phases:
> > > > > > > * continue the work on this API so that it can actually cover
> > all
> > > > use
> > > > > > > cases for plugins, create a new project with the new API and
> > > models,
> > > > > make
> > > > > > > sure plugins can work correctly with the new API /
> implementation
> > > > > > > * release the API, then maven-core supporting the new API
> > > > > > > * upgrade plugins to the new API, deprecate old components
> and
> > > API
> > > > > > > * once all plugins have migrated to the new API, switch
> > > maven-core
> > > > > > > implementation to the new API
> > > > > > >
> > > > > > > I'm eager to hear your thoughts !
> > > > > > >
> > > > > > > [1]
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven/tree/mvn4/maven-core-api/src/main/java/org/apache/maven/api
> > > > > > > [2]
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-plugin-testing/tree/mvn4/maven-plugin-testing-harness/src/main/java/org/apache/maven/api/plugin/testing
> > > > > > > [3]
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-deploy-plugin/blob/mvn4/src/test/java/org/apache/maven/plugins/deploy/DeployFileMojoTest.java
> > > > > > > [4]
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven/tree/mvn4/maven-core/src/main/java/org/apache/maven/internal/impl
> > > > > > > [5] https://github.com/apache/maven-clean-plugin/tree/mvn4/
> > > > > > > [6] https://github.com/apache/maven-install-plugin/tree/mvn4/
> > > > > > > [7] https://github.com/apache/maven-deploy-plugin/tree/mvn4/
> > > > > > >
> > > > > > > --
> > > > > > > ------------------------
> > > > > > > Guillaume Nodet
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > ------------------------
> > > > > > Guillaume Nodet
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > ------------------------
> > > > Guillaume Nodet
> > > >
> > >
> >
>
>
> --
> ------------------------
> Guillaume Nodet
>
Re: [DISCUSS] New Maven Core API for 4.x
Posted by Guillaume Nodet <gn...@apache.org>.
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 <rm...@gmail.com> 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 <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mar. 29 mars 2022 à 00:06, Matt Benson <mb...@apache.org> 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 <gn...@apache.org>
> 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 <mb...@apache.org> 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 <gn...@apache.org>
> > 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]
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/gnodet/maven/blob/m-api-immutable/maven-model/src/main/mdo/reader-ex.vm
> > > > >
> > > > > Le lun. 14 mars 2022 à 08:59, Guillaume Nodet <gn...@apache.org>
> a
> > > > écrit
> > > > > :
> > > > >
> > > > > > Hi everyone,
> > > > > >
> > > > > > As Michael hinted at this new API in the "[DISCUSS] Radical Fast
> > > > Forward
> > > > > > to 3.5.4" thread, I'd like to start the discussion around it.
> > > > > >
> > > > > > Over the past weeks, I've worked on an experimental API for Maven
> > > 4.x.
> > > > > > The goals are multiple :
> > > > > > * fix some problems with designs that do not work well with
> > > > > > multithreading
> > > > > > * offer a way to finally get rid of deprecated code
> > > > > > * offer a complete API (which would deprecate
> > m-artifact-transfer,
> > > > > > m-dependency-tree)
> > > > > > * offer an homogeneous and a bit more modern API
> > > > > > * completely hide the maven-resolver, so that it can finally
> > > upgrade
> > > > to
> > > > > > a v2 with the package renamed without too much disturbance
> > > > > >
> > > > > > The goal would be to extract the models and API in a separate
> > project
> > > > > with
> > > > > > a much lower release cycle, as those rarely change, but are
> > currently
> > > > > > released with each version of maven.
> > > > > >
> > > > > > The current API can be seen at [1]. Note that the plugins API
> has
> > > also
> > > > > > been included within the new API and the plugin tools have been
> > > updated
> > > > > so
> > > > > > that the maven-plugin-plugin supports both v3 api and the new v4
> > api.
> > > > A
> > > > > > new flag has been added to the MojoDescriptor to know if the
> plugin
> > > is
> > > > > > using the old or the new api. The plugin testing harness tools
> > have
> > > > been
> > > > > > updated to junit 5 and now provide a few annotations [2] to help
> > > > writing
> > > > > > plugin tests [3]. The maven-core has been enhanced to support
> > > loading
> > > > > > those new v4 plugins along with the v3 ones, which means they can
> > > work
> > > > > > side-by-side in the same build. This is done by implementing the
> > new
> > > > API
> > > > > > by wrapping the v3 implementation classes (such as MavenSession,
> > > > > > MavenProject, etc...) [4].
> > > > > > I've ported a few plugins such as clean [5], install [6], deploy
> > [7]
> > > > as a
> > > > > > proof-of-concept that this actually works.
> > > > > >
> > > > > > The very rough goal would be to to have multiple phases:
> > > > > > * continue the work on this API so that it can actually cover
> all
> > > use
> > > > > > cases for plugins, create a new project with the new API and
> > models,
> > > > make
> > > > > > sure plugins can work correctly with the new API / implementation
> > > > > > * release the API, then maven-core supporting the new API
> > > > > > * upgrade plugins to the new API, deprecate old components and
> > API
> > > > > > * once all plugins have migrated to the new API, switch
> > maven-core
> > > > > > implementation to the new API
> > > > > >
> > > > > > I'm eager to hear your thoughts !
> > > > > >
> > > > > > [1]
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven/tree/mvn4/maven-core-api/src/main/java/org/apache/maven/api
> > > > > > [2]
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-plugin-testing/tree/mvn4/maven-plugin-testing-harness/src/main/java/org/apache/maven/api/plugin/testing
> > > > > > [3]
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-deploy-plugin/blob/mvn4/src/test/java/org/apache/maven/plugins/deploy/DeployFileMojoTest.java
> > > > > > [4]
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven/tree/mvn4/maven-core/src/main/java/org/apache/maven/internal/impl
> > > > > > [5] https://github.com/apache/maven-clean-plugin/tree/mvn4/
> > > > > > [6] https://github.com/apache/maven-install-plugin/tree/mvn4/
> > > > > > [7] https://github.com/apache/maven-deploy-plugin/tree/mvn4/
> > > > > >
> > > > > > --
> > > > > > ------------------------
> > > > > > Guillaume Nodet
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > ------------------------
> > > > > Guillaume Nodet
> > > > >
> > > >
> > >
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > >
> >
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] New Maven Core API for 4.x
Posted by Mark Derricutt <ma...@talios.com>.
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 <rm...@gmail.com>
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
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 29 mars 2022 à 00:06, Matt Benson <mb...@apache.org> 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 <gn...@apache.org> 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 <mb...@apache.org> 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 <gn...@apache.org>
> 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]
> > > >
> > > >
> > >
> >
> https://github.com/gnodet/maven/blob/m-api-immutable/maven-model/src/main/mdo/reader-ex.vm
> > > >
> > > > Le lun. 14 mars 2022 à 08:59, Guillaume Nodet <gn...@apache.org> a
> > > écrit
> > > > :
> > > >
> > > > > Hi everyone,
> > > > >
> > > > > As Michael hinted at this new API in the "[DISCUSS] Radical Fast
> > > Forward
> > > > > to 3.5.4" thread, I'd like to start the discussion around it.
> > > > >
> > > > > Over the past weeks, I've worked on an experimental API for Maven
> > 4.x.
> > > > > The goals are multiple :
> > > > > * fix some problems with designs that do not work well with
> > > > > multithreading
> > > > > * offer a way to finally get rid of deprecated code
> > > > > * offer a complete API (which would deprecate
> m-artifact-transfer,
> > > > > m-dependency-tree)
> > > > > * offer an homogeneous and a bit more modern API
> > > > > * completely hide the maven-resolver, so that it can finally
> > upgrade
> > > to
> > > > > a v2 with the package renamed without too much disturbance
> > > > >
> > > > > The goal would be to extract the models and API in a separate
> project
> > > > with
> > > > > a much lower release cycle, as those rarely change, but are
> currently
> > > > > released with each version of maven.
> > > > >
> > > > > The current API can be seen at [1]. Note that the plugins API has
> > also
> > > > > been included within the new API and the plugin tools have been
> > updated
> > > > so
> > > > > that the maven-plugin-plugin supports both v3 api and the new v4
> api.
> > > A
> > > > > new flag has been added to the MojoDescriptor to know if the plugin
> > is
> > > > > using the old or the new api. The plugin testing harness tools
> have
> > > been
> > > > > updated to junit 5 and now provide a few annotations [2] to help
> > > writing
> > > > > plugin tests [3]. The maven-core has been enhanced to support
> > loading
> > > > > those new v4 plugins along with the v3 ones, which means they can
> > work
> > > > > side-by-side in the same build. This is done by implementing the
> new
> > > API
> > > > > by wrapping the v3 implementation classes (such as MavenSession,
> > > > > MavenProject, etc...) [4].
> > > > > I've ported a few plugins such as clean [5], install [6], deploy
> [7]
> > > as a
> > > > > proof-of-concept that this actually works.
> > > > >
> > > > > The very rough goal would be to to have multiple phases:
> > > > > * continue the work on this API so that it can actually cover all
> > use
> > > > > cases for plugins, create a new project with the new API and
> models,
> > > make
> > > > > sure plugins can work correctly with the new API / implementation
> > > > > * release the API, then maven-core supporting the new API
> > > > > * upgrade plugins to the new API, deprecate old components and
> API
> > > > > * once all plugins have migrated to the new API, switch
> maven-core
> > > > > implementation to the new API
> > > > >
> > > > > I'm eager to hear your thoughts !
> > > > >
> > > > > [1]
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven/tree/mvn4/maven-core-api/src/main/java/org/apache/maven/api
> > > > > [2]
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-plugin-testing/tree/mvn4/maven-plugin-testing-harness/src/main/java/org/apache/maven/api/plugin/testing
> > > > > [3]
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven-deploy-plugin/blob/mvn4/src/test/java/org/apache/maven/plugins/deploy/DeployFileMojoTest.java
> > > > > [4]
> > > > >
> > > >
> > >
> >
> https://github.com/apache/maven/tree/mvn4/maven-core/src/main/java/org/apache/maven/internal/impl
> > > > > [5] https://github.com/apache/maven-clean-plugin/tree/mvn4/
> > > > > [6] https://github.com/apache/maven-install-plugin/tree/mvn4/
> > > > > [7] https://github.com/apache/maven-deploy-plugin/tree/mvn4/
> > > > >
> > > > > --
> > > > > ------------------------
> > > > > Guillaume Nodet
> > > > >
> > > > >
> > > >
> > > > --
> > > > ------------------------
> > > > Guillaume Nodet
> > > >
> > >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
>
Re: [DISCUSS] New Maven Core API for 4.x
Posted by Matt Benson <mb...@apache.org>.
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 <gn...@apache.org> 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 <mb...@apache.org> 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 <gn...@apache.org> 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]
> > >
> > >
> >
> https://github.com/gnodet/maven/blob/m-api-immutable/maven-model/src/main/mdo/reader-ex.vm
> > >
> > > Le lun. 14 mars 2022 à 08:59, Guillaume Nodet <gn...@apache.org> a
> > écrit
> > > :
> > >
> > > > Hi everyone,
> > > >
> > > > As Michael hinted at this new API in the "[DISCUSS] Radical Fast
> > Forward
> > > > to 3.5.4" thread, I'd like to start the discussion around it.
> > > >
> > > > Over the past weeks, I've worked on an experimental API for Maven
> 4.x.
> > > > The goals are multiple :
> > > > * fix some problems with designs that do not work well with
> > > > multithreading
> > > > * offer a way to finally get rid of deprecated code
> > > > * offer a complete API (which would deprecate m-artifact-transfer,
> > > > m-dependency-tree)
> > > > * offer an homogeneous and a bit more modern API
> > > > * completely hide the maven-resolver, so that it can finally
> upgrade
> > to
> > > > a v2 with the package renamed without too much disturbance
> > > >
> > > > The goal would be to extract the models and API in a separate project
> > > with
> > > > a much lower release cycle, as those rarely change, but are currently
> > > > released with each version of maven.
> > > >
> > > > The current API can be seen at [1]. Note that the plugins API has
> also
> > > > been included within the new API and the plugin tools have been
> updated
> > > so
> > > > that the maven-plugin-plugin supports both v3 api and the new v4 api.
> > A
> > > > new flag has been added to the MojoDescriptor to know if the plugin
> is
> > > > using the old or the new api. The plugin testing harness tools have
> > been
> > > > updated to junit 5 and now provide a few annotations [2] to help
> > writing
> > > > plugin tests [3]. The maven-core has been enhanced to support
> loading
> > > > those new v4 plugins along with the v3 ones, which means they can
> work
> > > > side-by-side in the same build. This is done by implementing the new
> > API
> > > > by wrapping the v3 implementation classes (such as MavenSession,
> > > > MavenProject, etc...) [4].
> > > > I've ported a few plugins such as clean [5], install [6], deploy [7]
> > as a
> > > > proof-of-concept that this actually works.
> > > >
> > > > The very rough goal would be to to have multiple phases:
> > > > * continue the work on this API so that it can actually cover all
> use
> > > > cases for plugins, create a new project with the new API and models,
> > make
> > > > sure plugins can work correctly with the new API / implementation
> > > > * release the API, then maven-core supporting the new API
> > > > * upgrade plugins to the new API, deprecate old components and API
> > > > * once all plugins have migrated to the new API, switch maven-core
> > > > implementation to the new API
> > > >
> > > > I'm eager to hear your thoughts !
> > > >
> > > > [1]
> > > >
> > >
> >
> https://github.com/apache/maven/tree/mvn4/maven-core-api/src/main/java/org/apache/maven/api
> > > > [2]
> > > >
> > >
> >
> https://github.com/apache/maven-plugin-testing/tree/mvn4/maven-plugin-testing-harness/src/main/java/org/apache/maven/api/plugin/testing
> > > > [3]
> > > >
> > >
> >
> https://github.com/apache/maven-deploy-plugin/blob/mvn4/src/test/java/org/apache/maven/plugins/deploy/DeployFileMojoTest.java
> > > > [4]
> > > >
> > >
> >
> https://github.com/apache/maven/tree/mvn4/maven-core/src/main/java/org/apache/maven/internal/impl
> > > > [5] https://github.com/apache/maven-clean-plugin/tree/mvn4/
> > > > [6] https://github.com/apache/maven-install-plugin/tree/mvn4/
> > > > [7] https://github.com/apache/maven-deploy-plugin/tree/mvn4/
> > > >
> > > > --
> > > > ------------------------
> > > > Guillaume Nodet
> > > >
> > > >
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > >
> >
>
>
> --
> ------------------------
> Guillaume Nodet
>
Re: [DISCUSS] New Maven Core API for 4.x
Posted by Tibor Digana <ti...@apache.org>.
Hi Guillaume,
I think it was in 2013 when I had IIRC chat with Jason and Kristian
Rosenvold that the model and Project is risky from the concurrency point of
view.
I found the setters implemented with ArrayList as thread unsafe, and I
proposed introducing Service classes with accessing the data member and not
to make setters public.
Having public getters would lead to immutable objects but having the
services would lead to miscellaneous design patterns in the code internals.
Kristain convinced me that we did not have a concurrency issue, so we did
nothing about it. Bad luck!
T
On Mon, Mar 28, 2022 at 7:30 PM Guillaume Nodet <gn...@apache.org> 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 <mb...@apache.org> 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 <gn...@apache.org> 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]
> > >
> > >
> >
> https://github.com/gnodet/maven/blob/m-api-immutable/maven-model/src/main/mdo/reader-ex.vm
> > >
> > > Le lun. 14 mars 2022 à 08:59, Guillaume Nodet <gn...@apache.org> a
> > écrit
> > > :
> > >
> > > > Hi everyone,
> > > >
> > > > As Michael hinted at this new API in the "[DISCUSS] Radical Fast
> > Forward
> > > > to 3.5.4" thread, I'd like to start the discussion around it.
> > > >
> > > > Over the past weeks, I've worked on an experimental API for Maven
> 4.x.
> > > > The goals are multiple :
> > > > * fix some problems with designs that do not work well with
> > > > multithreading
> > > > * offer a way to finally get rid of deprecated code
> > > > * offer a complete API (which would deprecate m-artifact-transfer,
> > > > m-dependency-tree)
> > > > * offer an homogeneous and a bit more modern API
> > > > * completely hide the maven-resolver, so that it can finally
> upgrade
> > to
> > > > a v2 with the package renamed without too much disturbance
> > > >
> > > > The goal would be to extract the models and API in a separate project
> > > with
> > > > a much lower release cycle, as those rarely change, but are currently
> > > > released with each version of maven.
> > > >
> > > > The current API can be seen at [1]. Note that the plugins API has
> also
> > > > been included within the new API and the plugin tools have been
> updated
> > > so
> > > > that the maven-plugin-plugin supports both v3 api and the new v4 api.
> > A
> > > > new flag has been added to the MojoDescriptor to know if the plugin
> is
> > > > using the old or the new api. The plugin testing harness tools have
> > been
> > > > updated to junit 5 and now provide a few annotations [2] to help
> > writing
> > > > plugin tests [3]. The maven-core has been enhanced to support
> loading
> > > > those new v4 plugins along with the v3 ones, which means they can
> work
> > > > side-by-side in the same build. This is done by implementing the new
> > API
> > > > by wrapping the v3 implementation classes (such as MavenSession,
> > > > MavenProject, etc...) [4].
> > > > I've ported a few plugins such as clean [5], install [6], deploy [7]
> > as a
> > > > proof-of-concept that this actually works.
> > > >
> > > > The very rough goal would be to to have multiple phases:
> > > > * continue the work on this API so that it can actually cover all
> use
> > > > cases for plugins, create a new project with the new API and models,
> > make
> > > > sure plugins can work correctly with the new API / implementation
> > > > * release the API, then maven-core supporting the new API
> > > > * upgrade plugins to the new API, deprecate old components and API
> > > > * once all plugins have migrated to the new API, switch maven-core
> > > > implementation to the new API
> > > >
> > > > I'm eager to hear your thoughts !
> > > >
> > > > [1]
> > > >
> > >
> >
> https://github.com/apache/maven/tree/mvn4/maven-core-api/src/main/java/org/apache/maven/api
> > > > [2]
> > > >
> > >
> >
> https://github.com/apache/maven-plugin-testing/tree/mvn4/maven-plugin-testing-harness/src/main/java/org/apache/maven/api/plugin/testing
> > > > [3]
> > > >
> > >
> >
> https://github.com/apache/maven-deploy-plugin/blob/mvn4/src/test/java/org/apache/maven/plugins/deploy/DeployFileMojoTest.java
> > > > [4]
> > > >
> > >
> >
> https://github.com/apache/maven/tree/mvn4/maven-core/src/main/java/org/apache/maven/internal/impl
> > > > [5] https://github.com/apache/maven-clean-plugin/tree/mvn4/
> > > > [6] https://github.com/apache/maven-install-plugin/tree/mvn4/
> > > > [7] https://github.com/apache/maven-deploy-plugin/tree/mvn4/
> > > >
> > > > --
> > > > ------------------------
> > > > Guillaume Nodet
> > > >
> > > >
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > >
> >
>
>
> --
> ------------------------
> Guillaume Nodet
>
Re: [DISCUSS] New Maven Core API for 4.x
Posted by Guillaume Nodet <gn...@apache.org>.
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 <mb...@apache.org> 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 <gn...@apache.org> 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]
> >
> >
> https://github.com/gnodet/maven/blob/m-api-immutable/maven-model/src/main/mdo/reader-ex.vm
> >
> > Le lun. 14 mars 2022 à 08:59, Guillaume Nodet <gn...@apache.org> a
> écrit
> > :
> >
> > > Hi everyone,
> > >
> > > As Michael hinted at this new API in the "[DISCUSS] Radical Fast
> Forward
> > > to 3.5.4" thread, I'd like to start the discussion around it.
> > >
> > > Over the past weeks, I've worked on an experimental API for Maven 4.x.
> > > The goals are multiple :
> > > * fix some problems with designs that do not work well with
> > > multithreading
> > > * offer a way to finally get rid of deprecated code
> > > * offer a complete API (which would deprecate m-artifact-transfer,
> > > m-dependency-tree)
> > > * offer an homogeneous and a bit more modern API
> > > * completely hide the maven-resolver, so that it can finally upgrade
> to
> > > a v2 with the package renamed without too much disturbance
> > >
> > > The goal would be to extract the models and API in a separate project
> > with
> > > a much lower release cycle, as those rarely change, but are currently
> > > released with each version of maven.
> > >
> > > The current API can be seen at [1]. Note that the plugins API has also
> > > been included within the new API and the plugin tools have been updated
> > so
> > > that the maven-plugin-plugin supports both v3 api and the new v4 api.
> A
> > > new flag has been added to the MojoDescriptor to know if the plugin is
> > > using the old or the new api. The plugin testing harness tools have
> been
> > > updated to junit 5 and now provide a few annotations [2] to help
> writing
> > > plugin tests [3]. The maven-core has been enhanced to support loading
> > > those new v4 plugins along with the v3 ones, which means they can work
> > > side-by-side in the same build. This is done by implementing the new
> API
> > > by wrapping the v3 implementation classes (such as MavenSession,
> > > MavenProject, etc...) [4].
> > > I've ported a few plugins such as clean [5], install [6], deploy [7]
> as a
> > > proof-of-concept that this actually works.
> > >
> > > The very rough goal would be to to have multiple phases:
> > > * continue the work on this API so that it can actually cover all use
> > > cases for plugins, create a new project with the new API and models,
> make
> > > sure plugins can work correctly with the new API / implementation
> > > * release the API, then maven-core supporting the new API
> > > * upgrade plugins to the new API, deprecate old components and API
> > > * once all plugins have migrated to the new API, switch maven-core
> > > implementation to the new API
> > >
> > > I'm eager to hear your thoughts !
> > >
> > > [1]
> > >
> >
> https://github.com/apache/maven/tree/mvn4/maven-core-api/src/main/java/org/apache/maven/api
> > > [2]
> > >
> >
> https://github.com/apache/maven-plugin-testing/tree/mvn4/maven-plugin-testing-harness/src/main/java/org/apache/maven/api/plugin/testing
> > > [3]
> > >
> >
> https://github.com/apache/maven-deploy-plugin/blob/mvn4/src/test/java/org/apache/maven/plugins/deploy/DeployFileMojoTest.java
> > > [4]
> > >
> >
> https://github.com/apache/maven/tree/mvn4/maven-core/src/main/java/org/apache/maven/internal/impl
> > > [5] https://github.com/apache/maven-clean-plugin/tree/mvn4/
> > > [6] https://github.com/apache/maven-install-plugin/tree/mvn4/
> > > [7] https://github.com/apache/maven-deploy-plugin/tree/mvn4/
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > >
> > >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] New Maven Core API for 4.x
Posted by Matt Benson <mb...@apache.org>.
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 <gn...@apache.org> 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]
>
> https://github.com/gnodet/maven/blob/m-api-immutable/maven-model/src/main/mdo/reader-ex.vm
>
> Le lun. 14 mars 2022 à 08:59, Guillaume Nodet <gn...@apache.org> a écrit
> :
>
> > Hi everyone,
> >
> > As Michael hinted at this new API in the "[DISCUSS] Radical Fast Forward
> > to 3.5.4" thread, I'd like to start the discussion around it.
> >
> > Over the past weeks, I've worked on an experimental API for Maven 4.x.
> > The goals are multiple :
> > * fix some problems with designs that do not work well with
> > multithreading
> > * offer a way to finally get rid of deprecated code
> > * offer a complete API (which would deprecate m-artifact-transfer,
> > m-dependency-tree)
> > * offer an homogeneous and a bit more modern API
> > * completely hide the maven-resolver, so that it can finally upgrade to
> > a v2 with the package renamed without too much disturbance
> >
> > The goal would be to extract the models and API in a separate project
> with
> > a much lower release cycle, as those rarely change, but are currently
> > released with each version of maven.
> >
> > The current API can be seen at [1]. Note that the plugins API has also
> > been included within the new API and the plugin tools have been updated
> so
> > that the maven-plugin-plugin supports both v3 api and the new v4 api. A
> > new flag has been added to the MojoDescriptor to know if the plugin is
> > using the old or the new api. The plugin testing harness tools have been
> > updated to junit 5 and now provide a few annotations [2] to help writing
> > plugin tests [3]. The maven-core has been enhanced to support loading
> > those new v4 plugins along with the v3 ones, which means they can work
> > side-by-side in the same build. This is done by implementing the new API
> > by wrapping the v3 implementation classes (such as MavenSession,
> > MavenProject, etc...) [4].
> > I've ported a few plugins such as clean [5], install [6], deploy [7] as a
> > proof-of-concept that this actually works.
> >
> > The very rough goal would be to to have multiple phases:
> > * continue the work on this API so that it can actually cover all use
> > cases for plugins, create a new project with the new API and models, make
> > sure plugins can work correctly with the new API / implementation
> > * release the API, then maven-core supporting the new API
> > * upgrade plugins to the new API, deprecate old components and API
> > * once all plugins have migrated to the new API, switch maven-core
> > implementation to the new API
> >
> > I'm eager to hear your thoughts !
> >
> > [1]
> >
> https://github.com/apache/maven/tree/mvn4/maven-core-api/src/main/java/org/apache/maven/api
> > [2]
> >
> https://github.com/apache/maven-plugin-testing/tree/mvn4/maven-plugin-testing-harness/src/main/java/org/apache/maven/api/plugin/testing
> > [3]
> >
> https://github.com/apache/maven-deploy-plugin/blob/mvn4/src/test/java/org/apache/maven/plugins/deploy/DeployFileMojoTest.java
> > [4]
> >
> https://github.com/apache/maven/tree/mvn4/maven-core/src/main/java/org/apache/maven/internal/impl
> > [5] https://github.com/apache/maven-clean-plugin/tree/mvn4/
> > [6] https://github.com/apache/maven-install-plugin/tree/mvn4/
> > [7] https://github.com/apache/maven-deploy-plugin/tree/mvn4/
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
>
Re: [DISCUSS] New Maven Core API for 4.x
Posted by Guillaume Nodet <gn...@apache.org>.
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]
https://github.com/gnodet/maven/blob/m-api-immutable/maven-model/src/main/mdo/reader-ex.vm
Le lun. 14 mars 2022 à 08:59, Guillaume Nodet <gn...@apache.org> a écrit :
> Hi everyone,
>
> As Michael hinted at this new API in the "[DISCUSS] Radical Fast Forward
> to 3.5.4" thread, I'd like to start the discussion around it.
>
> Over the past weeks, I've worked on an experimental API for Maven 4.x.
> The goals are multiple :
> * fix some problems with designs that do not work well with
> multithreading
> * offer a way to finally get rid of deprecated code
> * offer a complete API (which would deprecate m-artifact-transfer,
> m-dependency-tree)
> * offer an homogeneous and a bit more modern API
> * completely hide the maven-resolver, so that it can finally upgrade to
> a v2 with the package renamed without too much disturbance
>
> The goal would be to extract the models and API in a separate project with
> a much lower release cycle, as those rarely change, but are currently
> released with each version of maven.
>
> The current API can be seen at [1]. Note that the plugins API has also
> been included within the new API and the plugin tools have been updated so
> that the maven-plugin-plugin supports both v3 api and the new v4 api. A
> new flag has been added to the MojoDescriptor to know if the plugin is
> using the old or the new api. The plugin testing harness tools have been
> updated to junit 5 and now provide a few annotations [2] to help writing
> plugin tests [3]. The maven-core has been enhanced to support loading
> those new v4 plugins along with the v3 ones, which means they can work
> side-by-side in the same build. This is done by implementing the new API
> by wrapping the v3 implementation classes (such as MavenSession,
> MavenProject, etc...) [4].
> I've ported a few plugins such as clean [5], install [6], deploy [7] as a
> proof-of-concept that this actually works.
>
> The very rough goal would be to to have multiple phases:
> * continue the work on this API so that it can actually cover all use
> cases for plugins, create a new project with the new API and models, make
> sure plugins can work correctly with the new API / implementation
> * release the API, then maven-core supporting the new API
> * upgrade plugins to the new API, deprecate old components and API
> * once all plugins have migrated to the new API, switch maven-core
> implementation to the new API
>
> I'm eager to hear your thoughts !
>
> [1]
> https://github.com/apache/maven/tree/mvn4/maven-core-api/src/main/java/org/apache/maven/api
> [2]
> https://github.com/apache/maven-plugin-testing/tree/mvn4/maven-plugin-testing-harness/src/main/java/org/apache/maven/api/plugin/testing
> [3]
> https://github.com/apache/maven-deploy-plugin/blob/mvn4/src/test/java/org/apache/maven/plugins/deploy/DeployFileMojoTest.java
> [4]
> https://github.com/apache/maven/tree/mvn4/maven-core/src/main/java/org/apache/maven/internal/impl
> [5] https://github.com/apache/maven-clean-plugin/tree/mvn4/
> [6] https://github.com/apache/maven-install-plugin/tree/mvn4/
> [7] https://github.com/apache/maven-deploy-plugin/tree/mvn4/
>
> --
> ------------------------
> Guillaume Nodet
>
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] New Maven Core API for 4.x
Posted by Guillaume Nodet <gn...@apache.org>.
Right, I was going to reply, but you already saw it.
Thx for the link, I'll investigate to make sure they are recognized
correctly, but I think the Nonnull and Nullable matching based on the
annotation class simple name is the usual way.
Guillaume
Le ven. 18 mars 2022 à 13:31, Konrad Windszus <kw...@apache.org> a écrit :
> I see now that this has been addressed in
> https://github.com/apache/maven/commit/8113c5139eed8a8b5f9883b5e105f820868d13f0
> already. I am just not sure whether your own annotations are evaluated by
> SonarQube and SpotBugs. For the latter check out the matching algorithm at
> https://github.com/spotbugs/spotbugs/blob/51e586bed98393e53559a38c1f9bd15f54514efa/spotbugs/src/main/java/edu/umd/cs/findbugs/ba/NullnessAnnotation.java#L35.
> Not sure where the related matching algorithm is in the SonarQube source
> code....
>
> Konrad
>
> On 2022/03/18 11:00:29 Konrad Windszus wrote:
> > Hi,
> > this looks really nice. Just one observation: I would recommend to get
> rid of JSR 305 null-annotations due to it being dormant and having
> split-package issues (https://nipafx.dev/jsr-305-java-9/). Consider
> migrating to either spotbugs (
> https://spotbugs.readthedocs.io/en/stable/annotations.html) or Jetbrains
> annotations (https://github.com/JetBrains/java-annotations).
> >
> > Konrad
> >
> > On 2022/03/14 07:59:08 Guillaume Nodet wrote:
> > > Hi everyone,
> > >
> > > As Michael hinted at this new API in the "[DISCUSS] Radical Fast
> Forward to
> > > 3.5.4" thread, I'd like to start the discussion around it.
> > >
> > > Over the past weeks, I've worked on an experimental API for Maven 4.x.
> > > The goals are multiple :
> > > * fix some problems with designs that do not work well with
> multithreading
> > > * offer a way to finally get rid of deprecated code
> > > * offer a complete API (which would deprecate m-artifact-transfer,
> > > m-dependency-tree)
> > > * offer an homogeneous and a bit more modern API
> > > * completely hide the maven-resolver, so that it can finally upgrade
> to a
> > > v2 with the package renamed without too much disturbance
> > >
> > > The goal would be to extract the models and API in a separate project
> with
> > > a much lower release cycle, as those rarely change, but are currently
> > > released with each version of maven.
> > >
> > > The current API can be seen at [1]. Note that the plugins API has also
> > > been included within the new API and the plugin tools have been
> updated so
> > > that the maven-plugin-plugin supports both v3 api and the new v4 api.
> A
> > > new flag has been added to the MojoDescriptor to know if the plugin is
> > > using the old or the new api. The plugin testing harness tools have
> been
> > > updated to junit 5 and now provide a few annotations [2] to help
> writing
> > > plugin tests [3]. The maven-core has been enhanced to support loading
> > > those new v4 plugins along with the v3 ones, which means they can work
> > > side-by-side in the same build. This is done by implementing the new
> API
> > > by wrapping the v3 implementation classes (such as MavenSession,
> > > MavenProject, etc...) [4].
> > > I've ported a few plugins such as clean [5], install [6], deploy [7]
> as a
> > > proof-of-concept that this actually works.
> > >
> > > The very rough goal would be to to have multiple phases:
> > > * continue the work on this API so that it can actually cover all use
> > > cases for plugins, create a new project with the new API and models,
> make
> > > sure plugins can work correctly with the new API / implementation
> > > * release the API, then maven-core supporting the new API
> > > * upgrade plugins to the new API, deprecate old components and API
> > > * once all plugins have migrated to the new API, switch maven-core
> > > implementation to the new API
> > >
> > > I'm eager to hear your thoughts !
> > >
> > > [1]
> > >
> https://github.com/apache/maven/tree/mvn4/maven-core-api/src/main/java/org/apache/maven/api
> > > [2]
> > >
> https://github.com/apache/maven-plugin-testing/tree/mvn4/maven-plugin-testing-harness/src/main/java/org/apache/maven/api/plugin/testing
> > > [3]
> > >
> https://github.com/apache/maven-deploy-plugin/blob/mvn4/src/test/java/org/apache/maven/plugins/deploy/DeployFileMojoTest.java
> > > [4]
> > >
> https://github.com/apache/maven/tree/mvn4/maven-core/src/main/java/org/apache/maven/internal/impl
> > > [5] https://github.com/apache/maven-clean-plugin/tree/mvn4/
> > > [6] https://github.com/apache/maven-install-plugin/tree/mvn4/
> > > [7] https://github.com/apache/maven-deploy-plugin/tree/mvn4/
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] New Maven Core API for 4.x
Posted by Konrad Windszus <kw...@apache.org>.
I see now that this has been addressed in https://github.com/apache/maven/commit/8113c5139eed8a8b5f9883b5e105f820868d13f0 already. I am just not sure whether your own annotations are evaluated by SonarQube and SpotBugs. For the latter check out the matching algorithm at https://github.com/spotbugs/spotbugs/blob/51e586bed98393e53559a38c1f9bd15f54514efa/spotbugs/src/main/java/edu/umd/cs/findbugs/ba/NullnessAnnotation.java#L35. Not sure where the related matching algorithm is in the SonarQube source code....
Konrad
On 2022/03/18 11:00:29 Konrad Windszus wrote:
> Hi,
> this looks really nice. Just one observation: I would recommend to get rid of JSR 305 null-annotations due to it being dormant and having split-package issues (https://nipafx.dev/jsr-305-java-9/). Consider migrating to either spotbugs (https://spotbugs.readthedocs.io/en/stable/annotations.html) or Jetbrains annotations (https://github.com/JetBrains/java-annotations).
>
> Konrad
>
> On 2022/03/14 07:59:08 Guillaume Nodet wrote:
> > Hi everyone,
> >
> > As Michael hinted at this new API in the "[DISCUSS] Radical Fast Forward to
> > 3.5.4" thread, I'd like to start the discussion around it.
> >
> > Over the past weeks, I've worked on an experimental API for Maven 4.x.
> > The goals are multiple :
> > * fix some problems with designs that do not work well with multithreading
> > * offer a way to finally get rid of deprecated code
> > * offer a complete API (which would deprecate m-artifact-transfer,
> > m-dependency-tree)
> > * offer an homogeneous and a bit more modern API
> > * completely hide the maven-resolver, so that it can finally upgrade to a
> > v2 with the package renamed without too much disturbance
> >
> > The goal would be to extract the models and API in a separate project with
> > a much lower release cycle, as those rarely change, but are currently
> > released with each version of maven.
> >
> > The current API can be seen at [1]. Note that the plugins API has also
> > been included within the new API and the plugin tools have been updated so
> > that the maven-plugin-plugin supports both v3 api and the new v4 api. A
> > new flag has been added to the MojoDescriptor to know if the plugin is
> > using the old or the new api. The plugin testing harness tools have been
> > updated to junit 5 and now provide a few annotations [2] to help writing
> > plugin tests [3]. The maven-core has been enhanced to support loading
> > those new v4 plugins along with the v3 ones, which means they can work
> > side-by-side in the same build. This is done by implementing the new API
> > by wrapping the v3 implementation classes (such as MavenSession,
> > MavenProject, etc...) [4].
> > I've ported a few plugins such as clean [5], install [6], deploy [7] as a
> > proof-of-concept that this actually works.
> >
> > The very rough goal would be to to have multiple phases:
> > * continue the work on this API so that it can actually cover all use
> > cases for plugins, create a new project with the new API and models, make
> > sure plugins can work correctly with the new API / implementation
> > * release the API, then maven-core supporting the new API
> > * upgrade plugins to the new API, deprecate old components and API
> > * once all plugins have migrated to the new API, switch maven-core
> > implementation to the new API
> >
> > I'm eager to hear your thoughts !
> >
> > [1]
> > https://github.com/apache/maven/tree/mvn4/maven-core-api/src/main/java/org/apache/maven/api
> > [2]
> > https://github.com/apache/maven-plugin-testing/tree/mvn4/maven-plugin-testing-harness/src/main/java/org/apache/maven/api/plugin/testing
> > [3]
> > https://github.com/apache/maven-deploy-plugin/blob/mvn4/src/test/java/org/apache/maven/plugins/deploy/DeployFileMojoTest.java
> > [4]
> > https://github.com/apache/maven/tree/mvn4/maven-core/src/main/java/org/apache/maven/internal/impl
> > [5] https://github.com/apache/maven-clean-plugin/tree/mvn4/
> > [6] https://github.com/apache/maven-install-plugin/tree/mvn4/
> > [7] https://github.com/apache/maven-deploy-plugin/tree/mvn4/
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] New Maven Core API for 4.x
Posted by Konrad Windszus <kw...@apache.org>.
Hi,
this looks really nice. Just one observation: I would recommend to get rid of JSR 305 null-annotations due to it being dormant and having split-package issues (https://nipafx.dev/jsr-305-java-9/). Consider migrating to either spotbugs (https://spotbugs.readthedocs.io/en/stable/annotations.html) or Jetbrains annotations (https://github.com/JetBrains/java-annotations).
Konrad
On 2022/03/14 07:59:08 Guillaume Nodet wrote:
> Hi everyone,
>
> As Michael hinted at this new API in the "[DISCUSS] Radical Fast Forward to
> 3.5.4" thread, I'd like to start the discussion around it.
>
> Over the past weeks, I've worked on an experimental API for Maven 4.x.
> The goals are multiple :
> * fix some problems with designs that do not work well with multithreading
> * offer a way to finally get rid of deprecated code
> * offer a complete API (which would deprecate m-artifact-transfer,
> m-dependency-tree)
> * offer an homogeneous and a bit more modern API
> * completely hide the maven-resolver, so that it can finally upgrade to a
> v2 with the package renamed without too much disturbance
>
> The goal would be to extract the models and API in a separate project with
> a much lower release cycle, as those rarely change, but are currently
> released with each version of maven.
>
> The current API can be seen at [1]. Note that the plugins API has also
> been included within the new API and the plugin tools have been updated so
> that the maven-plugin-plugin supports both v3 api and the new v4 api. A
> new flag has been added to the MojoDescriptor to know if the plugin is
> using the old or the new api. The plugin testing harness tools have been
> updated to junit 5 and now provide a few annotations [2] to help writing
> plugin tests [3]. The maven-core has been enhanced to support loading
> those new v4 plugins along with the v3 ones, which means they can work
> side-by-side in the same build. This is done by implementing the new API
> by wrapping the v3 implementation classes (such as MavenSession,
> MavenProject, etc...) [4].
> I've ported a few plugins such as clean [5], install [6], deploy [7] as a
> proof-of-concept that this actually works.
>
> The very rough goal would be to to have multiple phases:
> * continue the work on this API so that it can actually cover all use
> cases for plugins, create a new project with the new API and models, make
> sure plugins can work correctly with the new API / implementation
> * release the API, then maven-core supporting the new API
> * upgrade plugins to the new API, deprecate old components and API
> * once all plugins have migrated to the new API, switch maven-core
> implementation to the new API
>
> I'm eager to hear your thoughts !
>
> [1]
> https://github.com/apache/maven/tree/mvn4/maven-core-api/src/main/java/org/apache/maven/api
> [2]
> https://github.com/apache/maven-plugin-testing/tree/mvn4/maven-plugin-testing-harness/src/main/java/org/apache/maven/api/plugin/testing
> [3]
> https://github.com/apache/maven-deploy-plugin/blob/mvn4/src/test/java/org/apache/maven/plugins/deploy/DeployFileMojoTest.java
> [4]
> https://github.com/apache/maven/tree/mvn4/maven-core/src/main/java/org/apache/maven/internal/impl
> [5] https://github.com/apache/maven-clean-plugin/tree/mvn4/
> [6] https://github.com/apache/maven-install-plugin/tree/mvn4/
> [7] https://github.com/apache/maven-deploy-plugin/tree/mvn4/
>
> --
> ------------------------
> Guillaume Nodet
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] New Maven Core API for 4.x
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Guillaume,
+1, also +1 to add a hint in the mojo descriptor if the plugin is mvn4
compatible (version=xxx) to fully isolate it from the maven.core class
realm except the API which will avoid some headache in our tooling and at
runtime!
think it is the way we should priviledge to have a smoother and smaller
code maintenance.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le lun. 14 mars 2022 à 08:59, Guillaume Nodet <gn...@apache.org> a écrit :
> Hi everyone,
>
> As Michael hinted at this new API in the "[DISCUSS] Radical Fast Forward to
> 3.5.4" thread, I'd like to start the discussion around it.
>
> Over the past weeks, I've worked on an experimental API for Maven 4.x.
> The goals are multiple :
> * fix some problems with designs that do not work well with
> multithreading
> * offer a way to finally get rid of deprecated code
> * offer a complete API (which would deprecate m-artifact-transfer,
> m-dependency-tree)
> * offer an homogeneous and a bit more modern API
> * completely hide the maven-resolver, so that it can finally upgrade to a
> v2 with the package renamed without too much disturbance
>
> The goal would be to extract the models and API in a separate project with
> a much lower release cycle, as those rarely change, but are currently
> released with each version of maven.
>
> The current API can be seen at [1]. Note that the plugins API has also
> been included within the new API and the plugin tools have been updated so
> that the maven-plugin-plugin supports both v3 api and the new v4 api. A
> new flag has been added to the MojoDescriptor to know if the plugin is
> using the old or the new api. The plugin testing harness tools have been
> updated to junit 5 and now provide a few annotations [2] to help writing
> plugin tests [3]. The maven-core has been enhanced to support loading
> those new v4 plugins along with the v3 ones, which means they can work
> side-by-side in the same build. This is done by implementing the new API
> by wrapping the v3 implementation classes (such as MavenSession,
> MavenProject, etc...) [4].
> I've ported a few plugins such as clean [5], install [6], deploy [7] as a
> proof-of-concept that this actually works.
>
> The very rough goal would be to to have multiple phases:
> * continue the work on this API so that it can actually cover all use
> cases for plugins, create a new project with the new API and models, make
> sure plugins can work correctly with the new API / implementation
> * release the API, then maven-core supporting the new API
> * upgrade plugins to the new API, deprecate old components and API
> * once all plugins have migrated to the new API, switch maven-core
> implementation to the new API
>
> I'm eager to hear your thoughts !
>
> [1]
>
> https://github.com/apache/maven/tree/mvn4/maven-core-api/src/main/java/org/apache/maven/api
> [2]
>
> https://github.com/apache/maven-plugin-testing/tree/mvn4/maven-plugin-testing-harness/src/main/java/org/apache/maven/api/plugin/testing
> [3]
>
> https://github.com/apache/maven-deploy-plugin/blob/mvn4/src/test/java/org/apache/maven/plugins/deploy/DeployFileMojoTest.java
> [4]
>
> https://github.com/apache/maven/tree/mvn4/maven-core/src/main/java/org/apache/maven/internal/impl
> [5] https://github.com/apache/maven-clean-plugin/tree/mvn4/
> [6] https://github.com/apache/maven-install-plugin/tree/mvn4/
> [7] https://github.com/apache/maven-deploy-plugin/tree/mvn4/
>
> --
> ------------------------
> Guillaume Nodet
>
Re: [DISCUSS] New Maven Core API for 4.x
Posted by Guillaume Nodet <gn...@apache.org>.
I suppose you could raise PRs to the origin/mvn4 branch ? Maybe even commit
changes directly, if that makes sense.
Le lun. 14 mars 2022 à 16:43, Michael Osipov <mi...@apache.org> a écrit :
> Am 2022-03-14 um 08:59 schrieb Guillaume Nodet:
> > Hi everyone,
> >
> > As Michael hinted at this new API in the "[DISCUSS] Radical Fast Forward
> to
> > 3.5.4" thread, I'd like to start the discussion around it.
> >
> > Over the past weeks, I've worked on an experimental API for Maven 4.x.
> > The goals are multiple :
> > * fix some problems with designs that do not work well with
> multithreading
> > * offer a way to finally get rid of deprecated code
> > * offer a complete API (which would deprecate m-artifact-transfer,
> > m-dependency-tree)
> > * offer an homogeneous and a bit more modern API
> > * completely hide the maven-resolver, so that it can finally upgrade
> to a
> > v2 with the package renamed without too much disturbance
> >
> > The goal would be to extract the models and API in a separate project
> with
> > a much lower release cycle, as those rarely change, but are currently
> > released with each version of maven.
> >
> > The current API can be seen at [1]. Note that the plugins API has also
> > been included within the new API and the plugin tools have been updated
> so
> > that the maven-plugin-plugin supports both v3 api and the new v4 api. A
> > new flag has been added to the MojoDescriptor to know if the plugin is
> > using the old or the new api. The plugin testing harness tools have been
> > updated to junit 5 and now provide a few annotations [2] to help writing
> > plugin tests [3]. The maven-core has been enhanced to support loading
> > those new v4 plugins along with the v3 ones, which means they can work
> > side-by-side in the same build. This is done by implementing the new API
> > by wrapping the v3 implementation classes (such as MavenSession,
> > MavenProject, etc...) [4].
> > I've ported a few plugins such as clean [5], install [6], deploy [7] as a
> > proof-of-concept that this actually works.
> >
> > The very rough goal would be to to have multiple phases:
> > * continue the work on this API so that it can actually cover all use
> > cases for plugins, create a new project with the new API and models, make
> > sure plugins can work correctly with the new API / implementation
> > * release the API, then maven-core supporting the new API
> > * upgrade plugins to the new API, deprecate old components and API
> > * once all plugins have migrated to the new API, switch maven-core
> > implementation to the new API
> >
> > I'm eager to hear your thoughts !
> >
> > [1]
> >
> https://github.com/apache/maven/tree/mvn4/maven-core-api/src/main/java/org/apache/maven/api
> > [2]
> >
> https://github.com/apache/maven-plugin-testing/tree/mvn4/maven-plugin-testing-harness/src/main/java/org/apache/maven/api/plugin/testing
> > [3]
> >
> https://github.com/apache/maven-deploy-plugin/blob/mvn4/src/test/java/org/apache/maven/plugins/deploy/DeployFileMojoTest.java
> > [4]
> >
> https://github.com/apache/maven/tree/mvn4/maven-core/src/main/java/org/apache/maven/internal/impl
> > [5] https://github.com/apache/maven-clean-plugin/tree/mvn4/
> > [6] https://github.com/apache/maven-install-plugin/tree/mvn4/
> > [7] https://github.com/apache/maven-deploy-plugin/tree/mvn4/
> >
>
> MASSIVE! Nothing else to say. I have taken a look at [1] and see already
> room for improvement. What is the best way to comment on code?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] New Maven Core API for 4.x
Posted by Michael Osipov <mi...@apache.org>.
Am 2022-03-15 um 00:54 schrieb Hervé BOUTEMY:
> Le lundi 14 mars 2022, 16:43:51 CET Michael Osipov a écrit :
>> MASSIVE! Nothing else to say.
> +1
>
>> The very rough goal would be to to have multiple phases:
>> * continue the work on this API so that it can actually cover all use
>> cases for plugins, create a new project with the new API and models, make
>> sure plugins can work correctly with the new API / implementation
>> * release the API, then maven-core supporting the new API
> do you think that we would do first Maven 4.0.0-alpha releases as 1 global
> release, to have a first stabilisation, before splitting the API+models in a
> second set of betas?
I would expect to release alpha-1 as soon without waiting even longer
for it. The API can be delivered in any subsequent alpha version. We are
no restrained to one alpha version.
M
Re: [DISCUSS] New Maven Core API for 4.x
Posted by Hervé BOUTEMY <he...@free.fr>.
Le lundi 14 mars 2022, 16:43:51 CET Michael Osipov a écrit :
> MASSIVE! Nothing else to say.
+1
> The very rough goal would be to to have multiple phases:
> * continue the work on this API so that it can actually cover all use
> cases for plugins, create a new project with the new API and models, make
> sure plugins can work correctly with the new API / implementation
> * release the API, then maven-core supporting the new API
do you think that we would do first Maven 4.0.0-alpha releases as 1 global
release, to have a first stabilisation, before splitting the API+models in a
second set of betas?
note to self: do an updated dependency graph based on
https://maven.apache.org/ref/4-LATEST/
to clearly see the split between the API+models vs core
probably we'll need to write a plan on our Wiki
> * upgrade plugins to the new API, deprecate old components and API
this one will take time, given the work at Maven side and at community level
This will IMHO span the whole Maven 4 life time
> * once all plugins have migrated to the new API, switch maven-core
> implementation to the new API
this is one may be for Maven 5...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] New Maven Core API for 4.x
Posted by Michael Osipov <mi...@apache.org>.
Am 2022-03-14 um 08:59 schrieb Guillaume Nodet:
> Hi everyone,
>
> As Michael hinted at this new API in the "[DISCUSS] Radical Fast Forward to
> 3.5.4" thread, I'd like to start the discussion around it.
>
> Over the past weeks, I've worked on an experimental API for Maven 4.x.
> The goals are multiple :
> * fix some problems with designs that do not work well with multithreading
> * offer a way to finally get rid of deprecated code
> * offer a complete API (which would deprecate m-artifact-transfer,
> m-dependency-tree)
> * offer an homogeneous and a bit more modern API
> * completely hide the maven-resolver, so that it can finally upgrade to a
> v2 with the package renamed without too much disturbance
>
> The goal would be to extract the models and API in a separate project with
> a much lower release cycle, as those rarely change, but are currently
> released with each version of maven.
>
> The current API can be seen at [1]. Note that the plugins API has also
> been included within the new API and the plugin tools have been updated so
> that the maven-plugin-plugin supports both v3 api and the new v4 api. A
> new flag has been added to the MojoDescriptor to know if the plugin is
> using the old or the new api. The plugin testing harness tools have been
> updated to junit 5 and now provide a few annotations [2] to help writing
> plugin tests [3]. The maven-core has been enhanced to support loading
> those new v4 plugins along with the v3 ones, which means they can work
> side-by-side in the same build. This is done by implementing the new API
> by wrapping the v3 implementation classes (such as MavenSession,
> MavenProject, etc...) [4].
> I've ported a few plugins such as clean [5], install [6], deploy [7] as a
> proof-of-concept that this actually works.
>
> The very rough goal would be to to have multiple phases:
> * continue the work on this API so that it can actually cover all use
> cases for plugins, create a new project with the new API and models, make
> sure plugins can work correctly with the new API / implementation
> * release the API, then maven-core supporting the new API
> * upgrade plugins to the new API, deprecate old components and API
> * once all plugins have migrated to the new API, switch maven-core
> implementation to the new API
>
> I'm eager to hear your thoughts !
>
> [1]
> https://github.com/apache/maven/tree/mvn4/maven-core-api/src/main/java/org/apache/maven/api
> [2]
> https://github.com/apache/maven-plugin-testing/tree/mvn4/maven-plugin-testing-harness/src/main/java/org/apache/maven/api/plugin/testing
> [3]
> https://github.com/apache/maven-deploy-plugin/blob/mvn4/src/test/java/org/apache/maven/plugins/deploy/DeployFileMojoTest.java
> [4]
> https://github.com/apache/maven/tree/mvn4/maven-core/src/main/java/org/apache/maven/internal/impl
> [5] https://github.com/apache/maven-clean-plugin/tree/mvn4/
> [6] https://github.com/apache/maven-install-plugin/tree/mvn4/
> [7] https://github.com/apache/maven-deploy-plugin/tree/mvn4/
>
MASSIVE! Nothing else to say. I have taken a look at [1] and see already
room for improvement. What is the best way to comment on code?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org