Le dimanche 18 août 2024, 13:04:39 CEST Konrad Windszus a écrit : > > On 18. Aug 2024, at 12:59, Hervé Boutemy <herve.bout...@free.fr> wrote: > > > > with Maven 4, we'll have to maintain a 4.x branch of each plugin in > > parallel to the current Maven 3 compatible one: Maven 4 is the right time > > to have the discussion and eventually change the structure > > > > we need to clarify what "core" means: > > > > from https://maven.apache.org/plugins/ , I suppose we would try to merge > > clean (1 goal), deploy (2 goals), install (2 goals) and resources (3 > > goals) into a new plugin (8 goals)? > > Any other existing plugin that you think would be candidate to the merge? > > Any "LOT of code duplication" that is found elsewhere? > > > > > > on evaluating the value we get from it: > > as a Maven dev, it's true that clean, install and deploy have few > > releases. > > Resources seem to have a current issue reported by Konrad, I need to > > understand... > > This is no longer true in the newest m-resource-p, it was just an example > where I could not upgrade m-resource-p to a newer version due to a > regression. That would no longer be possible if all goals would be part of > one common plugin (because then it is all or nothing for those mojos).
ok, good news that's why the new "core" plugin requires a reasonable goals scope, as any other plugin: a plugin with more than 10 goals in general tends to be hard to simply document, like we have experience with dependency plugin for example > > as a user, it's true that these plugins are used in each and every > > packaging bindings > > https://maven.apache.org/ref/3.9.9/maven-core/default-bindings.html , > > having only one version to drive them would be nice > > > > Regards, > > > > Hervé > > > > Le jeudi 15 août 2024, 13:13:57 CEST Tamás Cservenák a écrit : > >> Howdy, > >> > >> as am going over multiple plugins (as it is time to upgrade parent, some > >> bugfix, etc), all I see is: > >> * a LOT of code duplication across plugins (some even have comments like > >> in > >> plugin X "this should be shared with Y") > >> * some "forcefully" pushed out "shared" artifact to share them across > >> * just many too small codebases that needs a LOT of process/work effort > >> for > >> small gain > >> * it is all chopped up into relatively small pieces > >> > >> Hence, we were already discussing this idea on Slack: what if we > >> introduce > >> maven-core-plugin? > >> > >> One single plugin that contains some "most common" Mojos? > >> (nothing new under Sun, this would be the "a la Takari Lifecycle" > >> situation, where one plugin delivers most common Mojos -- although there > >> the incentive was build avoidance/incremental build). > >> > >> For start, we could consider all 'core' plugins (those referenced from > >> maven like in lifecycle mapping) except: > >> * m-compiler-p > >> * m-surefire-p > >> > >> as they are complex on their own. > >> > >> WDYT? > >> Tamas > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
