[
http://jira.codehaus.org/browse/MASSEMBLY-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=226779#action_226779
]
Chetan Mehrotra commented on MASSEMBLY-393:
-------------------------------------------
I am also facing a similar issue with 2.2-beta-5. For now I am using the
workaround where I am re-specifying the dependencies in a dependencyManagement
section of the child pom
>From the code in manageArtifact in DefaultDependencyResolver
{code:java}
// Copied from DefaultArtifactCollector, SVN:
http://svn.apache.org/repos/asf/maven/components/branches/maven-2....@679206
// with modifications to work with non-transitive resolution processes.
protected void manageArtifact( Artifact targetArtifact, Map managedVersions
)
{
Artifact artifact = (Artifact) managedVersions.get(
targetArtifact.getDependencyConflictId() );
if ( artifact == null )
{
return;
}
// Before we update the version of the artifact, we need to know
// whether we are working on a transitive dependency or not. This
// allows depMgmt to always override transitive dependencies, while
// explicit child override depMgmt (viz. depMgmt should only
// provide defaults to children, but should override transitives).
// We can do this by calling isChildOfRootNode on the current node.
if ( artifact.getVersion() != null )
{
if ( getLogger().isDebugEnabled() )
{
getLogger().debug( "Managing version for: " +
targetArtifact.getDependencyConflictId() + " to: " + artifact.getVersion() );
}
targetArtifact.setVersion( artifact.getVersion() );
}
if ( artifact.getScope() != null )
{
if ( getLogger().isDebugEnabled() )
{
getLogger().debug( "Managing scope for: " +
targetArtifact.getDependencyConflictId() + " to: " + artifact.getScope() );
}
targetArtifact.setScope( artifact.getScope() );
}
}
{code}
The comment indicates that intention is correct but the code says otherwise.
And looking at
[DefaultArtifactCollector|http://svn.apache.org/repos/asf/maven/maven-2/branches/maven-2.2.x/maven-artifact/src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactCollector.java]
it looks like it is handled there
> Cannot Override dependencyManagement
> ------------------------------------
>
> Key: MASSEMBLY-393
> URL: http://jira.codehaus.org/browse/MASSEMBLY-393
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Affects Versions: 2.2-beta-3
> Environment: maven 2.0.9,2.0.10, windows xp, debian gnu linux,
> solaris 10
> Reporter: deckrider
> Attachments: my-app-pom-packaging.zip, my-app.zip
>
>
> This was not a problem in 2.2-beta-2.
> I've provided a test case. It should produce a zip file containing
> log4j-1.2.14.jar but instead contains log4j-1.2.12.jar
> To run the test case:
> unzip my-app.zip
> cd my-app.zip
> mvn clean package
> This is critical for us, because we have a master parent pom where we keep
> all our versions in a dependencyManagement section, but on occasion we want
> to override them. Upgrading from 2.2-beta-2 to 2.2-beta-3 broke that ability.
--
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
