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
