Re: [DISCUSS] New Maven Core API for 4.x

I've raised a PR with the new immutable model at [1]. The new API would only use the immutable model, while the old API would use the old model rewritten to wrap the immutable model. There are no real changes in the tests or integration tests (apart from 1 removed test), so this is really fully co

Re: [DISCUSS] New Maven Core API for 4.x

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 me

Re: [DISCUSS] New Maven Core API for 4.x

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 classre

Re: [DISCUSS] New Maven Core API for 4.x

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

Re: [DISCUSS] New Maven Core API for 4.x

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.Builde

Re: [DISCUSS] New Maven Core API for 4.x

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

Re: [DISCUSS] New Maven Core API for 4.x

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 inst

Re: [DISCUSS] New Maven Core API for 4.x

We’re over at https://github.com/repaint-io/maven-tiles What we’re doing is essential “evil” and mixing in “tiles” as implicit parents. It’s it’s no longer possible with 4.x - and if 4.x could provide something similar, with a transition path we could document, I’m down with sunsetting the proj

Re: [DISCUSS] New Maven Core API for 4.x

Le lun. 28 mars 2022 à 21:22, Mark Derricutt a écrit : > I wonder how much of this will break what we do with the > tiles-maven-plugin, where we essentially “inject” parents into the model > via a maven extension. > Interesting. Do you have a pointer to that plugin's source code ? Guillaume

Re: [DISCUSS] New Maven Core API for 4.x

I wonder how much of this will break what we do with the tiles-maven-plugin, where we essentially “inject” parents into the model via a maven extension. I remember I was seeing some odd issues under earlier builds of 4.x as well some time ago but will need to refresh my memory on what that was no

Re: [DISCUSS] New Maven Core API for 4.x

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 ap

Re: [DISCUSS] New Maven Core API for 4.x

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 wrote: > Hi everyone, > > Last week, I worked on a fully immutable ma

Re: [DISCUSS] New Maven Core API for 4.x

+1 to move that way but also +1 to keep plugins working (I don't see all plugins of the ecosystem being rewritten within 5 years so a light plugin compat layer would be neat). Romain Manni-Bucau @rmannibucau | Blog | Old Blog <

Re: [DISCUSS] New Maven Core API for 4.x

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

Re: [DISCUSS] New Maven Core API for 4.x

Right, I was going to reply, but you already saw it. Thx for the link, I'll investigate to make sure they are recognized correctly, but I think the Nonnull and Nullable matching based on the annotation class simple name is the usual way. Guillaume Le ven. 18 mars 2022 à 13:31, Konrad Windszus a

Re: [DISCUSS] New Maven Core API for 4.x

I see now that this has been addressed in https://github.com/apache/maven/commit/8113c5139eed8a8b5f9883b5e105f820868d13f0 already. I am just not sure whether your own annotations are evaluated by SonarQube and SpotBugs. For the latter check out the matching algorithm at https://github.com/spotb

Re: [DISCUSS] New Maven Core API for 4.x

Hi, this looks really nice. Just one observation: I would recommend to get rid of JSR 305 null-annotations due to it being dormant and having split-package issues (https://nipafx.dev/jsr-305-java-9/). Consider migrating to either spotbugs (https://spotbugs.readthedocs.io/en/stable/annotations.ht

Re: [DISCUSS] New Maven Core API for 4.x

Am 2022-03-15 um 00:54 schrieb Hervé BOUTEMY: Le lundi 14 mars 2022, 16:43:51 CET Michael Osipov a écrit : MASSIVE! Nothing else to say. +1 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

Re: [DISCUSS] New Maven Core API for 4.x

Le lundi 14 mars 2022, 16:43:51 CET Michael Osipov a écrit : > MASSIVE! Nothing else to say. +1 > 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,

Re: [DISCUSS] New Maven Core API for 4.x

I suppose you could raise PRs to the origin/mvn4 branch ? Maybe even commit changes directly, if that makes sense. Le lun. 14 mars 2022 à 16:43, Michael Osipov a écrit : > Am 2022-03-14 um 08:59 schrieb Guillaume Nodet: > > Hi everyone, > > > > As Michael hinted at this new API in the "[DISCUSS]

Re: [DISCUSS] New Maven Core API for 4.x

Am 2022-03-14 um 08:59 schrieb Guillaume Nodet: 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 :

Re: [DISCUSS] New Maven Core API for 4.x

Hi Guillaume, +1, also +1 to add a hint in the mojo descriptor if the plugin is mvn4 compatible (version=xxx) to fully isolate it from the maven.core class realm except the API which will avoid some headache in our tooling and at runtime! think it is the way we should priviledge to have a smoother

[DISCUSS] New Maven Core API for 4.x

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 w