Maven plugin cannot have a new major version, as "by convention" it would mean it requires Maven 4 to run. As in this case it would be m-remote-resources-p 4.0.0 (as currently it is 3.x,x).
I always assumed maven plugin versions should be observed when "shifted one position to left". Something like: 3.2.1 is 3 :: 2.1 (and patch is always ".0" if no 4th version element) Hence, to me 3.2.1 plugin version means: - lineage 3 (requires maven 3.x to run, this is more precisely driven by plugin itself, ASF plugins are 3.2.5+ for example using prerequisite) - major: 2 - minor:1 - patch: "0" always (as we usually don't use 4 segmented version In other words, plugin version 3.2.1 to me means "this is a maven3 plugin, version 2.1.0" T On Fri, Mar 10, 2023 at 6:17 PM Elliotte Rusty Harold <elh...@ibiblio.org> wrote: > If we're breaking the API, it should be a new major version. > > On Fri, Mar 10, 2023 at 10:11 AM Benjamin Marwell <bmarw...@apache.org> > wrote: > > > > +1 for dropping. Make it a new minor Version. We may want to add a > > migration strategy. But then, if there's not even a hit on GitHub... Just > > go with it. We do have a well working mailing list. > > > > > > On Fri, 10 Mar 2023, 10:56 Olivier Lamy, <ol...@apache.org> wrote: > > > > > not sure how useful this feature is... > > > I would say just drop it... > > > quick search on github cannot find usage of it... > > > > > > > https://github.com/search?q=%3CrunOnlyAtExecutionRoot%3E+language%3A%22Maven+POM%22&type=code&l=Maven+POM > > > > > > > > > > > > On Fri, 10 Mar 2023 at 00:44, Tamás Cservenák <ta...@cservenak.net> > wrote: > > > > > > > > Howdy, > > > > > > > > I would like to share (and possibly exchange) some recollections > about > > > the > > > > m-remote-resource-p. > > > > > > > > For start, there is an ongoing PR to drop all the accumulated legacy > > > stuff: > > > > https://github.com/apache/maven-remote-resources-plugin/pull/26 > > > > > > > > But what caught my eye are these lines: > > > > > > > > https://github.com/apache/maven-remote-resources-plugin/blame/e7cc40df2f5ee99cde90d1dc7308df719f1c1963/src/main/java/org/apache/maven/plugin/resources/remote/ProcessRemoteResourcesMojo.java#L134-L138 > > > > > > > > In short, what this plugin does is (should be) nearly trivial: > collect > > > > project, project dependencies, resolve some resource bundles, apply > > > > Velocity templates, done. > > > > > > > > BUT, due to the comment and removal of `requiresDependencyResolution` > > > this > > > > plugin does what Maven should be doing: resolves/collects and builds > > > > transitive deps. And I feel this is wrong. > > > > > > > > As you see in comment, the REASON of removal (and hence bloating the > Mojo > > > > with all-the-stuff-that-Maven-should-do) was to implement > > > > https://issues.apache.org/jira/browse/MRRESOURCES-41 that again > looks > > > like > > > > some 'wish" issue, with idea "to mimic the assembly plugin's > > > > runOnlyAtExecutionRoot flag". Also, to me this "smells" like > aggregation > > > > without aggregator (and resolution without Maven) -- so just a WTH > moment > > > > one after another. > > > > > > > > I find this wrong, as it sacrifices simplicity and reusability > (plugin > > > must > > > > do what Maven already does for plugin, if asked for), and it > resulted in > > > > this plugin to become bloat, and later totally neglected and full of > > > > booby-traps. > > > > > > > > So, my proposal is like in PR: > > > > > > > > 1. return this Mojo switch `requiresDependencyResolution=TEST` and > let > > > Mojo > > > > filter as it needs. This is already done in PR and big chunk of code > is > > > > gone, all tests except the one IT that tests the > runOnlyAtExecutionRoot > > > > passes OK. > > > > 2. above implies we drop runOnlyAtExecutionRoot, everything else > remains, > > > > BUT > > > > 3. introduce new mojo aggregate-process (as in PR), that really does > what > > > > it says: will collect all DEPENDENCIES in BULK at parent level. There > > > > are two shortcomings (as seen in IT_RunOnlyAtExecutionRoot source): > it is > > > > IN BULK, and for this to work, a goal is needed that will produce > > > > inter-project dependencies, otherwise build fails. > > > > > > > > With these changes all passes OK and IMO the plugin itself became > much > > > > simpler and easier to understand. > > > > > > > > In short, if you have any idea, I am listening! > > > > > > > > > > > > Thanks > > > > T > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
