You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Laird Nelson (JIRA)" <ji...@codehaus.org> on 2009/12/03 17:20:55 UTC
[jira] Created: (MNG-4479) Dependency resolution for plugins with
default-cli execution happens too late
Dependency resolution for plugins with default-cli execution happens too late
-----------------------------------------------------------------------------
Key: MNG-4479
URL: http://jira.codehaus.org/browse/MNG-4479
Project: Maven 2
Issue Type: Bug
Components: Class Loading, Dependencies, Plugins and Lifecycle
Affects Versions: 2.2.1
Reporter: Laird Nelson
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4479) [regression] Project-level plugin
dependencies ignored for direct CLI invocation if plugin key uses
properties
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Bentmann updated MNG-4479:
-----------------------------------
Affects Version/s: 2.1.0-M1
2.1.0
2.2.0
Assignee: Benjamin Bentmann
Summary: [regression] Project-level plugin dependencies ignored for direct CLI invocation if plugin key uses properties (was: Dependency resolution for plugins with default-cli execution happens too late)
> [regression] Project-level plugin dependencies ignored for direct CLI invocation if plugin key uses properties
> --------------------------------------------------------------------------------------------------------------
>
> Key: MNG-4479
> URL: http://jira.codehaus.org/browse/MNG-4479
> Project: Maven 2
> Issue Type: Bug
> Components: Class Loading, Dependencies, Plugins and Lifecycle
> Affects Versions: 2.1.0-M1, 2.1.0, 2.2.0, 2.2.1
> Reporter: Laird Nelson
> Assignee: Benjamin Bentmann
> Attachments: mng-4479.zip
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4479) Dependency resolution for plugins with
default-cli execution happens too late
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=200874#action_200874 ]
Benjamin Bentmann commented on MNG-4479:
----------------------------------------
bq. I tried to debug this using mvn -X, but the output was totally baffling
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.
> Dependency resolution for plugins with default-cli execution happens too late
> -----------------------------------------------------------------------------
>
> Key: MNG-4479
> URL: http://jira.codehaus.org/browse/MNG-4479
> Project: Maven 2
> Issue Type: Bug
> Components: Class Loading, Dependencies, Plugins and Lifecycle
> Affects Versions: 2.2.1
> Reporter: Laird Nelson
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4479) [regression] Project-level plugin
dependencies ignored for direct CLI invocation if plugin key uses
properties
Posted by "Laird Nelson (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201638#action_201638 ]
Laird Nelson commented on MNG-4479:
-----------------------------------
Perhaps consider applying the fix to the 2.1 branch?
> [regression] Project-level plugin dependencies ignored for direct CLI invocation if plugin key uses properties
> --------------------------------------------------------------------------------------------------------------
>
> Key: MNG-4479
> URL: http://jira.codehaus.org/browse/MNG-4479
> Project: Maven 2
> Issue Type: Bug
> Components: Class Loading, Dependencies, Plugins and Lifecycle
> Affects Versions: 2.1.0-M1, 2.1.0, 2.2.0, 2.2.1
> Reporter: Laird Nelson
> Assignee: Benjamin Bentmann
> Fix For: 3.0-alpha-2
>
> Attachments: mng-4479.zip
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4479) Dependency resolution for plugins with
default-cli execution happens too late
Posted by "Laird Nelson (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201209#action_201209 ]
Laird Nelson commented on MNG-4479:
-----------------------------------
Quite right of course. See attachment. Now hopefully it won't hang around for quite some time! :-)
> Dependency resolution for plugins with default-cli execution happens too late
> -----------------------------------------------------------------------------
>
> Key: MNG-4479
> URL: http://jira.codehaus.org/browse/MNG-4479
> Project: Maven 2
> Issue Type: Bug
> Components: Class Loading, Dependencies, Plugins and Lifecycle
> Affects Versions: 2.2.1
> Reporter: Laird Nelson
> Attachments: mng-4479.zip
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4479) Dependency resolution for plugins with
default-cli execution happens too late
Posted by "Laird Nelson (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Laird Nelson updated MNG-4479:
------------------------------
Attachment: mng-4479.zip
Reproducible test projects attached.
To build and reproduce:
mvn clean install in mng-4479-plugin
mvn clean install in mng-4479-implementations
Then in mng-4479-harness:
First do mvn generate-sources. Observe that the build completes normally.
Next do mvn mavenbugs:mng-4479-plugin:frobnicate. Observe that the build fails with the dependency resolution behavior described in this bug.
> Dependency resolution for plugins with default-cli execution happens too late
> -----------------------------------------------------------------------------
>
> Key: MNG-4479
> URL: http://jira.codehaus.org/browse/MNG-4479
> Project: Maven 2
> Issue Type: Bug
> Components: Class Loading, Dependencies, Plugins and Lifecycle
> Affects Versions: 2.2.1
> Reporter: Laird Nelson
> Attachments: mng-4479.zip
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-4479) [regression] Project-level
plugin dependencies ignored for direct CLI invocation if plugin key uses
properties
Posted by "Laird Nelson (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201638#action_201638 ]
Laird Nelson edited comment on MNG-4479 at 12/7/09 7:07 PM:
------------------------------------------------------------
Perhaps consider applying the fix to the 2.2.1 branch?
was (Author: ljnelson):
Perhaps consider applying the fix to the 2.1 branch?
> [regression] Project-level plugin dependencies ignored for direct CLI invocation if plugin key uses properties
> --------------------------------------------------------------------------------------------------------------
>
> Key: MNG-4479
> URL: http://jira.codehaus.org/browse/MNG-4479
> Project: Maven 2
> Issue Type: Bug
> Components: Class Loading, Dependencies, Plugins and Lifecycle
> Affects Versions: 2.1.0-M1, 2.1.0, 2.2.0, 2.2.1
> Reporter: Laird Nelson
> Assignee: Benjamin Bentmann
> Fix For: 3.0-alpha-2
>
> Attachments: mng-4479.zip
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4479) [regression] Project-level plugin
dependencies ignored for direct CLI invocation if plugin key uses
properties
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Bentmann closed MNG-4479.
----------------------------------
Resolution: Fixed
Fix Version/s: 3.0-alpha-2
The problem is related to interpolation. As such a workaround is to use a constant value for the group-/artifactId of the plugin, i.e. your test project passes if you replace {{<groupId>${project.groupId}</groupId>}} with {{<groupId>mavenbugs</groupId>}} in the plugin declaration.
> [regression] Project-level plugin dependencies ignored for direct CLI invocation if plugin key uses properties
> --------------------------------------------------------------------------------------------------------------
>
> Key: MNG-4479
> URL: http://jira.codehaus.org/browse/MNG-4479
> Project: Maven 2
> Issue Type: Bug
> Components: Class Loading, Dependencies, Plugins and Lifecycle
> Affects Versions: 2.1.0-M1, 2.1.0, 2.2.0, 2.2.1
> Reporter: Laird Nelson
> Assignee: Benjamin Bentmann
> Fix For: 3.0-alpha-2
>
> Attachments: mng-4479.zip
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira