[ 
https://jira.codehaus.org/browse/MNG-5156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276188#comment-276188
 ] 

Bisser commented on MNG-5156:
-----------------------------

After you directed me to lines 68-72, I examined the code there and then I 
debugged it again to see why it doesn't enter that branch. The reason was that 
the 'root' project was not on top level. It was wrapped on the fly into a dummy 
project like this:

{noformat}
   private ModelSource createStubModelSource(String groupId, String artifactId, 
String version)
                                                                  throws 
ProjectBuildingException {
      StringBuilder sb = new StringBuilder();

      sb.append("<?xml version='1.0'?>");
      sb.append("<project>");
      sb.append("<modelVersion>4.0.0</modelVersion>");
      sb.append("<groupId>com.acme.dynamic.project</groupId>");
      sb.append("<artifactId>dummy-dynamic-project</artifactId>");
      sb.append("<version>1.0.0</version>");
      sb.append("<packaging>pom</packaging>");
      sb.append("<dependencies>");
      sb.append(   "<dependency>");
      sb.append(      "<groupId>").append(groupId).append("</groupId>");
      sb.append(      
"<artifactId>").append(artifactId).append("</artifactId>");
      sb.append(      "<version>").append(version).append("</version>");
      sb.append(      "<scope>compile</scope>");
      sb.append(   "</dependency>");
      sb.append("</dependencies>");
      sb.append("</project>");

      ModelSource modelSource = new StringModelSource(sb.toString());
      return modelSource;
   }
{noformat}

So, in fact, the hierarchy was like this:

{noformat}
com.acme.dynamic.project:dummy-dynamic-project:pom:1.0.0
\- com.acme:root:jar:1.0.0:compile
   +- com.acme:test-framework:jar:1.0.0:test
   \- com.acme:another-module:jar:1.0.0:compile
      \- com.acme:test-framework:jar:1.0.0:compile
{noformat}

I still think that it makes more sense for the 'test-framework' dependency to 
have a 'test' scope because the 'root' dependency enforces the 'test' scope 
explicitly, so it's whole sub-tree should use the 'test' scope for the 
'test-framework'.

However, if the Maven team has decided that the scope should be 'compile' in 
this case, then ok.

Thank you for replying so quickly!

> org.sonatype.aether.util.graph.transformer.JavaEffectiveScopeCalculator 
> doesn't take into account direct vs. transitive dependencies
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: MNG-5156
>                 URL: https://jira.codehaus.org/browse/MNG-5156
>             Project: Maven 2 & 3
>          Issue Type: Bug
>          Components: Dependencies
>    Affects Versions: 3.0.2, 3.0.3
>         Environment: Irrelevant (I debugged the code and I provide an exact 
> location of the problem)
>            Reporter: Bisser
>            Priority: Minor
>         Attachments: pom.xml
>
>
> When calculating the scope of a dependency, Maven should assign to direct 
> dependencies higher priority than transitive dependencies.
> For example:
> com.acme:root:jar:1.0.0
> +- com.acme:test-framework:jar:1.0.0:test                 <<<<<<<<<<<<< 
> direct dependency
> \- com.acme:another-module:jar:1.0.0:compile
>    \- com.acme:test-framework:jar:1.0.0:compile           <<<<<<<<<<<<< 
> transitive dependency
> We can see that the 'root' project references test-framework directly with 
> scope 'test'. However, the same test-framework also has a 'compile' scope, 
> but via a transitive dependency. I believe that the final scope should be 
> 'test' -- that's the explicit desire of the author of project 'root'.
> However, when I do roughly the following:
>    ProjectBuilder projectBuilder = 
> plexusContainer.lookup(ProjectBuilder.class);
>    ProjectBuildingRequest projectBuildingRequest = ....;
>    projectBuildingRequest.setResolveDependencies(true);
>    ...
>    ProjectBuildingResult result = projectBuilder.build(pom, 
> projectBuildingRequest);
>    MavenProject proj = result.getProject();
>    ...
>    Set<Artifact> artifacts = proj.getArtifacts();
> The 'test-framework' Artifact has a scope of 'compile'!!! (I will provide 
> more code, if you'd like.)
> After some debugging to find out the reason for this, I reached class 
> org.sonatype.aether.util.graph.transformer.JavaEffectiveScopeCalculator. 
> There, in method chooseEffectiveScope, there's the following code:
>         else if ( scopes.contains( JavaScopes.COMPILE ) )
>         {
>             effectiveScope = JavaScopes.COMPILE;
>         }
> So, no attention is paid whether the dependency is direct or transitive. If 
> there's *any* dependency with scope 'compile', then the conflict is resolved 
> by setting the final scope to 'compile'. But, as I said above, I believe the 
> final scope should be 'test'.
> Here's a relevant stack trace:
> JavaEffectiveScopeCalculator.chooseEffectiveScope(Set<String>) line: 220      
> JavaEffectiveScopeCalculator.resolve(ConflictGroup, Map<?,?>, Set<?>) line: 
> 139       
> JavaEffectiveScopeCalculator.transformGraph(DependencyNode, 
> DependencyGraphTransformationContext) line: 92    
> ChainedDependencyGraphTransformer.transformGraph(DependencyNode, 
> DependencyGraphTransformationContext) line: 75       
> DefaultDependencyCollector.collectDependencies(RepositorySystemSession, 
> CollectRequest) line: 253     
> DefaultRepositorySystem.collectDependencies(RepositorySystemSession, 
> CollectRequest) line: 345        
> DefaultProjectDependenciesResolver.resolve(DependencyResolutionRequest) line: 
> 131     
> DefaultProjectBuilder.build(File, ModelSource, 
> DefaultProjectBuilder$InternalConfig) line: 166        
> DefaultProjectBuilder.build(ModelSource, ProjectBuildingRequest) line: 108    
> .
> .
> .
> By the way, the Dependency Plugin reports this:
> ...
> +- com.acme:test-framework:jar:1.0.0:test (scope not updated to compile)
> The plugin resolves the conflict properly! The scope remains 'test', it's not 
> set to 'compile'.
> I detected this problem with versions 3.0.3 and 3.0.2. It might be present in 
> other versions too but I didn't bother to check any more versions.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to