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
