Is this proposal because elements from the super pom has been removed from 4.x? https://issues.apache.org/jira/browse/MNG-6054 https://maven.apache.org/ref/3.9.8/maven-model-builder/super-pom.html https://maven.apache.org/ref/4.0.0-alpha-9/maven-model-builder/super-pom.html
Which changes a new user's on-ramp to maven 4+ as those core plugin versions are no longer managed? On Thu, Aug 15, 2024 at 8:44 AM Gary Gregory <garydgreg...@gmail.com> wrote: > 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 > > > > > > > > > > > > >
