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 <[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 >
