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