I would think the benefit of having a single plugin would be to have faster release cycles, as the amount of work for a single release is quite important imho. So having a single release cycle would lower the ration work/ nb mojos. That said, I think that could also be achieved by using a reactor build (we could keep several jar plugin in a single release cycle/git repo). Maybe that would bring the same benefits without drawbacks. I know some people do frown when releasing the same artifacts without any real change, but I’m not sure why…
------------------------ Guillaume Nodet Le jeu. 15 août 2024 à 13:39, Konrad Windszus <k...@apache.org> a écrit : > The concrete example I suffered from was > https://issues.apache.org/jira/browse/MRESOURCES-289 which forced me to > stay on 3.1.0 ( > https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/58ef9f5f28d8e54c4d26d35011b1caff570a1b1d/pom.xml#L111-L115 > ). > > > On 15. Aug 2024, at 13:35, Konrad Windszus <k...@apache.org> wrote: > > > > 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 > > > >
