[
https://issues.apache.org/jira/browse/MRESOLVER-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17893628#comment-17893628
]
ASF GitHub Bot commented on MRESOLVER-614:
------------------------------------------
gnodet commented on code in PR #595:
URL: https://github.com/apache/maven-resolver/pull/595#discussion_r1819798250
##########
maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/manager/AbstractDependencyManager.java:
##########
@@ -229,37 +231,46 @@ public DependencyManagement manageDependency(Dependency
dependency) {
}
}
+ // system scope paths always applied to have them aligned
+ // (same artifact > same path) in whole graph
if (systemDependencyScope != null
- && (systemDependencyScope.is(scope)
+ && (scope != null &&
systemDependencyScope.is(scope.getValue())
|| (scope == null &&
systemDependencyScope.is(dependency.getScope())))) {
- String localPath = managedLocalPaths.get(key);
+ Holder<String> localPath = managedLocalPaths.get(key);
if (localPath != null) {
if (management == null) {
management = new DependencyManagement();
}
Map<String, String> properties =
new
HashMap<>(dependency.getArtifact().getProperties());
- systemDependencyScope.setSystemPath(properties, localPath);
+ systemDependencyScope.setSystemPath(properties,
localPath.getValue());
management.setProperties(properties);
}
}
- Boolean optional = managedOptionals.get(key);
+ // optional is not managed by model builder
+ // if rule exists, apply it
Review Comment:
> MNG-4600: It introduced the empty method
https://svn.apache.org/viewvc/maven/maven-3/trunk/maven-model-builder/src/main/java/org/apache/maven/model/management/DefaultDependencyManagementInjector.java?r1=925481&r2=925480&pathrev=925481
MNG-5227: there is comment "is solved in resolver but not in ModelBuilder".
This clearly says "handled by dependency manager but not model builder"
Are you saying that optional can be managed already ?
> Collector applies depMgt entries coming from a self onto itself
> ---------------------------------------------------------------
>
> Key: MRESOLVER-614
> URL: https://issues.apache.org/jira/browse/MRESOLVER-614
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
> Affects Versions: 2.0.2
> Reporter: Tamas Cservenak
> Assignee: Tamas Cservenak
> Priority: Major
> Fix For: 2.0.3
>
>
> In Maven3 this was not a problem, as Maven3 could add depMgt only on "root
> level".
> In Maven4 with use of new/old transitive Dependency Managers this became a
> problem. The dependency manager first receives depMgt entries for currently
> processed node, and then applies it onto same entry, overriding direct
> dependency versions.
> Example with Maven beta-5: it cannot build Resolver master
> (88a96ac0606d4d2372452a677d9f93c0b55105a4) as bnd-maven-plugin do depend on
> plexus-utils via path of {{bnd-maven-plugin > build-api > plexus-utils}} as
> it explodes due lack of org.plexus.utils.Scanner on classpath. This class was
> introduced in plexus-utils 1.5.8, and build-api do depend on it. But alas,
> build-api parent contains depMgt entry for plexus-utils 1.5.5 and is applied
> onto build-api overriding it's own dependency version.
> Basically current resolver code is NOT prepared for any "transitive
> dependency management" (despite DependencyManagers are there) as node would
> apply it's own depManagement rules onto itself.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
