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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > > 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 <[email protected]> > 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
