Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.1.0-M1, 2.1.0, 2.2.0, 2.2.1
-
Fix Version/s: 3.0-alpha-2
-
Component/s: Class Loading, Dependencies, Plugins and Lifecycle
-
Labels:None
-
Complexity:Intermediate
-
Number of attachments :
Description
I have a plugin that makes use of the implementation attribute in its configuration. That is, one of its parameters is a plexus tag that specifies an implementation class to use.
The implementation class comes from a jar that is the plugin's dependency, but that dependency is included as part of the plugin configuration, not as part of the stock plugin.
This setup works fine when I bind the plugin's configuration via an execution to a normal phase (generate-sources as it happens).
When I bind the plugin's configuration to the default-cli execution, plexus cannot configure the component, claiming that the classname it encounters in the "implementation" attribute cannot be found (even though, again, if I bind it to the generate-sources phase instead, via another execution, same configuration, everything works fine.
I tried to debug this using mvn -X, but the output was totally baffling; sorry. My raw take is that it looks like dependency resolution in the default-cli execution is somehow performed differently than when the plugin is run bound to a phase.
Issue Links
- relates to
-
MNG-4580
Plugin dependencies for module ignored when building from aggregator project using direct plugin invocation
-
Well, it's cool if you try and not suprising if you struggle, but it's crucial that you enable us to debug it. This issue has neither a reproducible test project nor the debug log attached, i.e. chances are high that this issue will hang around for quite some time.