back to: we need to clarify what scope of merge is expected 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 "core" 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?
if we don't clarify or precise expected scope by different people, the discussion is getting into circles: https://maven.apache.org/plugins/ lists 52 plugins, I hope nobody expects to merge much Regards, Hervé Le dimanche 18 août 2024, 15:27:05 CEST Gary Gregory a écrit : > I also wonder why the core needs to be sliced and diced at this level of > plugin granularity. I imagine some of ot is for historical reasons. My > comments are just born out of curiosity, this is not a criticism 😀 > > Gary > > On Sun, Aug 18, 2024, 9:19 AM Elliotte Rusty Harold <elh...@ibiblio.org> > > wrote: > > Putting all plugins in a single plugin jar also makes releases more > > challenging. 9 plugins might not be able to be updated because of a > > critical regression in one of them. > > > > On Sun, Aug 18, 2024 at 12:49 PM Ozgun Oz <ozgunn...@gmail.com> wrote: > > > As a maven user, I agree with Konrad on the fact that putting all > > > plugins > > > in a single plugin jar will remove the flexibility users have today to > > > uprade them independently in case of bug/regression/retrocompability > > > > issue > > > > > in one plugin. > > > > > > Why not creating a library that regroups the duplicated code among > > > > plugins ? > > > > > On Sun, Aug 18, 2024, 2:34 PM Gary Gregory <garydgreg...@gmail.com> > > > > wrote: > > > > Another way to look at a "core": > > > > > > > > In my Maven 3.9.8 install folder I have 23 "maven-" jars including 10 > > > > "maven-resolver-". Why don't I just a single "maven-core" jar? > > > > > > > > Gary > > > > > > > > On Sun, Aug 18, 2024, 7:04 AM Konrad Windszus <k...@apache.org> wrote: > > > > > > 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). > > > > > > > > > > > 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 > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.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
