Major It would be nice to send a warning when a scope is illegal, and fallback to compile. At least, when the dependency is not nedded. For example it is a transitive dependency, but i try to resolve without transitivity.
Now resolver sends an exception, and my test blows.
My exact use-case:
PomEquippedResolveStage resolver = Maven.resolver().offline().loadPomFromFile("pom.xml");
MavenStrategyStage strategy = resolver.resolve(
"org.modeshape:modeshape-jcr-api",
"org.modeshape:modeshape-jcr",
"org.modeshape:modeshape-common");
File[] jars = strategy.withoutTransitivity().asFile();
In pom.xml i have:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.modeshape.bom</groupId>
<artifactId>modeshape-bom-embedded</artifactId>
<version>3.2.0.Final</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
I get an exception:
java.lang.IllegalArgumentException: Scope type test,provided is not supported. at org.jboss.shrinkwrap.resolver.api.maven.ScopeType.fromScopeType(ScopeType.java:72) at org.jboss.shrinkwrap.resolver.impl.maven.convert.MavenConverter.fromDependency(MavenConverter.java:116) at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenResolutionFilterWrap.accept(MavenRepositorySystem.java:211) at org.sonatype.aether.util.graph.FilteringDependencyVisitor.visitEnter(FilteringDependencyVisitor.java:73) at org.sonatype.aether.util.graph.TreeDependencyVisitor.visitEnter(TreeDependencyVisitor.java:61) at org.sonatype.aether.impl.internal.GraphEdge.accept(GraphEdge.java:198) at org.sonatype.aether.impl.internal.GraphEdge.accept(GraphEdge.java:202) at org.sonatype.aether.impl.internal.GraphEdge.accept(GraphEdge.java:202) at org.sonatype.aether.impl.internal.GraphEdge.accept(GraphEdge.java:202) at org.sonatype.aether.impl.internal.GraphEdge.accept(GraphEdge.java:202) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:352) at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenRepositorySystem.resolveDependencies(MavenRepositorySystem.java:122) at org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:251) at org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:67) at org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withoutTransitivity(MavenStrategyStageBaseImpl.java:54) at org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withoutTransitivity(MavenStrategyStageBaseImpl.java:38)
The real problem is in a transitive dependency. http://repo1.maven.org/maven2/org/gagravarr/vorbis-java-tika/0.1/vorbis-java-tika-0.1.pom
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>vorbis-java-core</artifactId>
<version>${project.version}</version>
<classifier>tests</classifier>
<scope>test,provided</scope>
</dependency>
The scope is illegal. But in my case it is irrelavant. My workaround was to upload a fixed java-tika pom.xml to our corporate nexus. I think it would be nice to tolerate this error in shrinkwrap-resolver. My other tools like maven, and netbeans are tolerate it too. (maven fallbacks to compile scope as i understand)
I should file a bug report to vorbis-java-tika, but i'm afraid there are some other projects in the wild with similar errors.
[SHRINKRES-143] tolerate illegal dependency scopes
Tamás Kimmel (Inactive)
added a comment - Hi!
Checked by running 'mvn dependency:tree'
Maven 3.0.5 prints runtime, 3.1.1 prints 'test,provided' for vorbis-java-core.
After checked with 'mvn dependency:build-classpath -DincludeScope=runtime'
Both 3.0.5 and 3.1.1 puts vorbis-java-core in the classpath. So the real fallback seems to be runtime.
My test pom is a simple pom.xml skeleton with a single dependency.
<dependency> <groupId>org.gagravarr</groupId> <artifactId>vorbis-java-tika</artifactId> <version>0.1</version> </dependency>
Tamás Kimmel (Inactive)
added a comment - Hi!
Checked by running 'mvn dependency:tree'
Maven 3.0.5 prints runtime, 3.1.1 prints 'test,provided' for vorbis-java-core.
After checked with 'mvn dependency:build-classpath -DincludeScope=runtime'
Both 3.0.5 and 3.1.1 puts vorbis-java-core in the classpath. So the real fallback seems to be runtime.
My test pom is a simple pom.xml skeleton with a single dependency.
<dependency>
<groupId> org.gagravarr </groupId>
<artifactId> vorbis-java-tika </artifactId>
<version> 0.1 </version>
</dependency>
Karel Piwko
added a comment - Tamas, what happens in Maven? Does it fallback to compile? Any changes in behavior in between Maven 3.0 and 3.1?
Karel Piwko
added a comment - Tamas, what happens in Maven? Does it fallback to compile? Any changes in behavior in between Maven 3.0 and 3.1? 
Michal Matloka (Inactive)
added a comment - Hello,
I had exactly the same problem. However vorbis scopes are really invalid according to maven specs and I have not found any other project which had similiar problems. My solution was to simply exclude this dependency in our projects pom.xml. If I remember correctly newest version of vorbis does not have this invalid scopes, but it is not updated yet in modeshape dependencies. I have informed back then rhauch about this problem.
Michal Matloka (Inactive)
added a comment - Hello,
I had exactly the same problem. However vorbis scopes are really invalid according to maven specs and I have not found any other project which had similiar problems. My solution was to simply exclude this dependency in our projects pom.xml. If I remember correctly newest version of vorbis does not have this invalid scopes, but it is not updated yet in modeshape dependencies. I have informed back then rhauch about this problem. 
Pushed upstream in https://github.com/shrinkwrap/resolver/commit/8734e1eba8f1840e925e77521718dd4a4171bf3e