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 <rmannibu...@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) > > >
