[shrinkwrap-issues] [JBoss JIRA] (SHRINKRES-112) MavenImporter ignores AcceptScopesStrategy for dependency inclusion

[Karel Piwko (JIRA)]

    [ https://issues.jboss.org/browse/SHRINKRES-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760465#comment-12760465 ] 

Karel Piwko edited comment on SHRINKRES-112 at 3/12/13 4:35 AM:
----------------------------------------------------------------

I pushed a few tests for Scopes in https://github.com/shrinkwrap/resolver/commit/4fbb087627fbd04e8fb078cf16469b417a7f696b.

When I tried to identify the problem, I realized that we use AcceptScopesStrategy for two different purposes:

*Handling transitive dependencies*::
Suppose you want to resolve test scoped dependencies of org.jboss.artifact:foobar:1. Then you do the following

{code}
Maven.resolver().resolve("org.jboss.artifact:foobar:1").using(new AcceptScopesStrategy(ScopeType.TEST)).asFiles()
{code}

This call will simply get a dependency, constructs it's tree and get only test scope. 
This is default behavior for AcceptScopesStrategy - no preFiltering is done
Note, that it seems to me that it works only for the first level of dependency tree, might be a 

*Handling scopes defined in pom*::
Suppose that you have a project and you want to resolve all scopes it defines as <scope>test</scope>

{code}
Maven.resolver().loadPomFromFile("pom.xml").importRuntimeAndTestDependencies(new AcceptScopesStrategy(ScopeType.TEST)).asFiles()
{code}

This call has completely different behavior! The purpose would be to get whole <dependencies> section and select only those that are defined as <scope>test</scope>.
So this is prefiltering. Then you obviously expect Maven to grab compile and runtime dependencie of the test dependencies and resolve those.

You don't really want to get all test scoped dependencies in the tree, as it happens now due to resolution filtering.

[~alrubinger], I was thinking of making the strategy context dependent, but it does not seem to solve the problem without bringing confusion, e.g. for PomLess calls it would filter graph, with PomIncluded calls it will filter <dependencies> defined so far.

The confusion will come from following calls:

{code}
// prefiltering will remove defined-in-pom:defined-in-pom as resolver call will put it into compile scope(no scope defined)
// will fail with no dependencies to be resolved
Maven.resolver().loadPomFromFile("pom.xml").resolve("defined-in-pom:defined-in-pom").using(new AcceptScopesStrategy(ScopeType.TEST)).asFiles(); 

// will grab test scoped dependencies if no pom, because no prefiltering will be applied
Maven.resolver().resolve("defined-in-pom:defined-in-pom:version-not-in-pom").using(new AcceptScopesStrategy(ScopeType.TEST)).asFiles(); 

{code}

Any other idea?




                
      was (Author: kpiwko):
    I pushed a few tests for Scopes in https://github.com/shrinkwrap/resolver/commit/4fbb087627fbd04e8fb078cf16469b417a7f696b.

When I tried to identify the problem, I realized that we use AcceptScopesStrategy for two different purposes:

*Handling transitive dependencies*::
Suppose you want to resolve test scoped dependencies of org.jboss.artifact:foobar:1. Then you do the following

{code}
Maven.resolver().resolve("org.jboss.artifact:foobar:1").using(new AcceptScopesStrategy(ScopeType.TEST)).asFiles()
{code}

This call will simply get a dependency, constructs it's tree and get only test scope. 
This is default behavior for AcceptScopesStrategy - no preFiltering is done
Note, that it seems to me that it works only for the first level of dependency tree, might be a 

*Handling scopes defined in pom*::
Suppose that you have a project and you want to resolve all scopes it defines as <scope>test</scope>

{code}
Maven.resolver().loadPomFromFile("pom.xml").importRuntimeAndTestDependencies(new AcceptScopesStrategy(ScopeType.TEST)).asFiles()
{code}

This call has completely different behavior! The purpose would be to get whole <dependencies> section and select only those that are defined as <scope>test</scope>.
So this is prefiltering. Then you obviously expect Maven to grab compile and runtime dependencie of the test dependencies and resolve those.

You don't really want to get all test scoped dependencies in the tree, as it happens now due to resolution filtering.

[~alrubinger], I was thinking of making the strategy context dependent, but it does not seem to solve the problem without bringing confusion, e.g. for PomLess calls it would filter graph, with PomIncluded calls it will filter <dependencies> defined so far.

The confusion will come from following calls:

{code}
// prefiltering will remove defined-in-pom:defined-in-pom as resolver call will put it into compile scope(no scope defined)
// will fail with no dependencies to be resolved
Maven.resolver().loadPomFromFile("pom.xml").resolve("defined-in-pom:defined-in-pom").using(new AcceptScopesStrategy(ScopeType.TEST)).asFiles(); 

// will grap test scoped dependencies if no pom, because no prefiltering will be applied
Maven.resolver().resolve("defined-in-pom:defined-in-pom:version-not-in-pom").using(new AcceptScopesStrategy(ScopeType.TEST)).asFiles(); 

{code}

Any other idea?




                  
> MavenImporter ignores AcceptScopesStrategy for dependency inclusion
> -------------------------------------------------------------------
>
>                 Key: SHRINKRES-112
>                 URL: https://issues.jboss.org/browse/SHRINKRES-112
>             Project: ShrinkWrap Resolvers
>          Issue Type: Feature Request
>          Components: impl-maven
>    Affects Versions: 2.0.0-beta-2
>            Reporter: Karel Piwko
>            Priority: Blocker
>
> AcceptScopesStrategy is not correctly propagated:
> {code}
>   @Deployment(testable = false)
>   public static WebArchive createDeployment()
>   {
>     return ShrinkWrap.create(MavenImporter.class)
>       .loadPomFromFile("pom.xml")
>       .importBuildOutput(new AcceptScopesStrategy(ScopeType.COMPILE, ScopeType.RUNTIME))
>       .as(WebArchive.class);
>   }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira