AFAIK, Tamas suggested to *move* all plugins in a single maven-core-plugin, not to extract reusable data in a new git repo.
Le jeu. 15 août 2024 à 15:42, Christoph Läubrich <m...@laeubi-soft.de> a écrit : > > I think the main problem is that "maven-core" is often rejecting request > for providing useful things in the first place. > > That leads to all kind of "helper", "util", ... so maybe instead of > having a maven-core-plugin, it would better to have a maven-plugin-core > module (what of course can for example contain things like > AbstractXXXMojo others can extend. > > Then one can easily share (and improve) common code but still has the > mentioned advantage of individual releases/plugins and flexibility. > > Am 15.08.24 um 13:35 schrieb Konrad Windszus: > > 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- ------------------------ Guillaume Nodet
