Le lundi 19 août 2024, 09:43:50 CEST Christoph Läubrich a écrit : > Should it really be "core-plugin" or can't one simply retain existing > plugin names. sorry, a plugin has a single name, no per-goal customization: merging plugins means from a user perspective using one single new plugin name Of course "maven-core-plugin" is just a first initial name: any better idea to match the intent of the new merged plugin is welcome
> > I'm just asking because: > > 1) It would invalidate each and every custom configuration / executions +1 > 2) All share the same "configuration space" then +1 in the case of skip parameter, for example, that exists all goals of the install/deploy/clean/resource plugins, XML configuration is a unique "skip" parameter, but CLI property is differentiated "maven.<task>.skip" notice that per-execution XML configuration can be done, which de-facto provides per-mojo config > 3) A prefix can only be applied once for a plugin but not for a mojo > (afaik) so also cli invocations will be broken / maybe unexpected +1 hence why we need to clarify which plugins are intended to be merged to see if it is worth the change to me, merging install+deploy+clean+resource can be an idea I don't see what other merges are in initial vision, in the same target plugin that install/deploy/clean/resource or in another Regards, Hervé > > Am 19.08.24 um 09:04 schrieb Hervé Boutemy: > > 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 > > --------------------------------------------------------------------- > 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
