[
https://issues.jboss.org/browse/SHRINKRES-112?page=com.atlassian.jira.plu...
]
Karel Piwko edited comment on SHRINKRES-112 at 4/30/13 4:56 AM:
----------------------------------------------------------------
I pushed a few tests for Scopes in
https://github.com/shrinkwrap/resolver/commit/4fbb087627fbd04e8fb078cf164....
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 bug
*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/4fbb087627fbd04e8fb078cf164....
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?
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