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