Just to be clear, your argument seems to be that a new plugin must always add new functionality, not that its existence should make its ancestors obsolete (since by that measure Ubuntu has failed since Debian still exists)
But still, the xkcd comic is about *competing* standards (A/C adaptors, character encodings, messaging protocols), i.e. there are integration points under different authorities which all need to be changed to adopt the new standard (at more or less the same time). That's clearly not the case with Maven plugin configuration: when is there ever a conflict between plugins? Or more than one authority over a project? Without conflict or multiple authorities there's no need for synchronization. The $5000 question is how can the old plugins still even exist if the code for them has been moved to a new core plugin? @Tamás Cservenák <ta...@cservenak.net> you are talking about moving these mojos to a new plugin? Delany On Thu, 15 Aug 2024 at 17:49, Elliotte Rusty Harold <elh...@ibiblio.org> wrote: > No, it seems to be a proposal for a new core plugin, not just > reorganzing the git repo. I predict if someone tries that we'll still > have all the old plugins plus the new maven-core-plugin. I have seen > this play out so many times over the years. Another old favorite: > > https://www.youtube.com/watch?v=vK3WhJGg7PM > > On Thu, Aug 15, 2024 at 11:17 AM Guillaume Nodet <gno...@apache.org> > wrote: > > > > Yes, I don’t understand either. > > I think the proposal is just to merge all core plugins into a single > > project. > > > > ------------------------ > > Guillaume Nodet > > > > > > > > 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 > > > > > > > > > > > > > > > -- > 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 > >
