Hi, Although I do see the benefits from a Maven Dev perspective for Consumers this is worse. In the past often individual plugin versions suffered from regressions for certain edge cases.
Having individual separate plugins allowed consumers to deliberately use an old version of one plugin (e.g. maven-resources-plugin) while upgrading all others to the latest version available. One example is maven-resources-plugin which suffered from some regressions in the past. Instead I would rather try to identify the shared code and put it into a library (new or existing). Konrad > On 15. Aug 2024, at 13:13, 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
