-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PoC/experiment: new scope "import-plugins" #1190
base: master
Are you sure you want to change the base?
Conversation
Introduces new scope very similar to "import" but this one is "import-plugins" and as it's name says, imports pluginManagement. To test it: * build this PR * use this POM https://gist.github.com/cstamas/8668205f68b0eaf42c8c34bba7d080a4 * invoke `mvn help:effective-pom`
@cstamas This is interesting and could almost be a migration path for tiles-maven-plugin - I wonder if having a new scope is good tho, rather than reusing the existing I'll pull the PR in the morning and play with it. |
see https://issues.apache.org/jira/browse/MNG-5588 |
Um, |
putting a plugin-related scope on a dependencyManagement does not look intuitive either |
"plugin-related scope"? Plugins does not have scopes 😄 OTOH, if you look at original definition of "import" scope: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#dependency-scope "This scope is only supported on a dependency of type pom in the The new "import-plugins" works exactly the same, except just replace "This scope is only supported on a dependency of type pom in the |
And an idea from comment on MNG-5588: IF you are importing a POM, why not import everything? (And then need for new scope really goes away). Users can prepare POMs with parts they want (depMgt only, pluginMgt only, or both) and import. (but this carries potential of breaking builds, that do import some POM for it's depMgt but are not interested, or worse, would break them if pluginMgt is imported...) |
The issue with "import" magic is that very quickly you will also need the conflict resolution management until you import a single piece which is basically a parent. Think extensions are a nice way to configure plugins (bad for dependencies since this part must always load in an IDE without code execution but it is not the case for plugins) but for the case you want to inherit from something done outside we could just use xml references, which would enable to import a template and customize it inline instead of importing as such which often leads to issues. So from my window we shouldn't enable much on dependencies but we can go quite far now we have the consumer model transformation pipeline by enabling to reference a plugin from an imported resource (can need an import block but not a big deal) and customize it inline, even with required placeholders if needed. |
That's essentially what tiles-maven-plugin does - only it does it by synthetically injected the tile-pom as a parent (and has its own transitive tiles, which I don't like - but users do). Because it's pulling in everything - you get the plugin definition and the executions, so you don't need to repeat all the plugins in the child pom (but that I could probably accept). |
No real problem - more questioning the naming (which may be too early in the change to quibble over naming), tho reading the reasoning of 'plugins don't have scope' that means this is possibly more a trade-off due to current limitations of the POM format. @rmannibucau's comment:
makes me think back to the current tiles implementation which operates as an extension, hooking into the model builder - but with the immutable model in M4 doesn't work - an new extension point for model manipulation would be nice. One nice thing with tiles, by pulling as parents - we also pull in any ` defined, which can also then be overridden/customised. |
Well, if v4 does not allow tiles to be implemented it means the plugin API is not yet sufficient and can't be used so we must fix it, can be nice to work on that, intent is to copy instead of mutating, not breaking use cases. |
Plugins does not and will not have "scope". Why would a plugin need "scope"? IMHO this is not a deficiency but was a deliberate design goal. |
As we all know, the "import" scope is not really a scope, it is a hack. And we do already have that hack in place, and it works. So, am really unsure why we either:
So, why are we sitting comfy and not doing anything about it? This PR does 1st bullet, but for sure we can get a stab on 2nd bullet as well, as we decide... |
Introduces new scope very similar to "import" but this one is "import-plugins" and as it's name says, imports pluginManagement.
To test it:
mvn help:effective-pom
Enjoy!