For me, if it's only dependency updates or matching versions of sibling jars, it's a valuable new release because it says "We _know_ 100% this combination works". Assuming the combination is tested.
Gary On Thu, Aug 15, 2024, 9:01 AM Guillaume Nodet <gno...@apache.org> wrote: > 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 > > > > > > > >
