Think we should either assume it and make these plugins embedded in core (same loader) or just let it like that and if needed extract reusable services in core when dep free.
Le jeu. 15 août 2024 à 16:39, Tamás Cservenák <ta...@cservenak.net> a écrit : > Eliotte, > > Who would "compete" within the ASF Maven project? > > T > > On Thu, Aug 15, 2024 at 4:37 PM Elliotte Rusty Harold <elh...@ibiblio.org> > wrote: > > > This sounds like an opportunity to cite my all-time favorite xkcd: > > > > https://xkcd.com/927/ > > > > On Thu, Aug 15, 2024 at 7:15 AM Tamás Cservenák <ta...@cservenak.net> > > wrote: > > > > > > 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 > > > > > > > > -- > > 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 > > > > >
