January 2014 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] (SHRINKRES-143) tolerate illegal dependency scopes

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-143?page=com.atlassian.jira.plu... ] Karel Piwko updated SHRINKRES-143: ---------------------------------- Fix Version/s: 2.0.2 > tolerate illegal dependency scopes > ---------------------------------- > > Key: SHRINKRES-143 > URL: https://issues.jboss.org/browse/SHRINKRES-143 > Project: ShrinkWrap Resolvers > Issue Type: Enhancement > Reporter: Tamás Kimmel > Assignee: Karel Piwko > Fix For: 2.0.2 > > > 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: > {noformat} > 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(); > {noformat} > In pom.xml i have: > {noformat} > <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> > {noformat} > I get an exception: > {noformat} > 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) > {noformat} > The real problem is in a transitive dependency. http://repo1.maven.org/maven2/org/gagravarr/vorbis-java-tika/0.1/vorbis-j... > {noformat} > <dependency> > <groupId>${project.groupId}</groupId> > <artifactId>vorbis-java-core</artifactId> > <version>${project.version}</version> > <classifier>tests</classifier> > <scope>test,provided</scope> > </dependency> > {noformat} > 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. -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-143) tolerate illegal dependency scopes

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-143?page=com.atlassian.jira.plu... ] Karel Piwko reassigned SHRINKRES-143: ------------------------------------- Assignee: Karel Piwko (was: Andrew Rubinger) > tolerate illegal dependency scopes > ---------------------------------- > > Key: SHRINKRES-143 > URL: https://issues.jboss.org/browse/SHRINKRES-143 > Project: ShrinkWrap Resolvers > Issue Type: Enhancement > Reporter: Tamás Kimmel > Assignee: Karel Piwko > > 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: > {noformat} > 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(); > {noformat} > In pom.xml i have: > {noformat} > <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> > {noformat} > I get an exception: > {noformat} > 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) > {noformat} > The real problem is in a transitive dependency. http://repo1.maven.org/maven2/org/gagravarr/vorbis-java-tika/0.1/vorbis-j... > {noformat} > <dependency> > <groupId>${project.groupId}</groupId> > <artifactId>vorbis-java-core</artifactId> > <version>${project.version}</version> > <classifier>tests</classifier> > <scope>test,provided</scope> > </dependency> > {noformat} > 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. -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-149) Maven classpathworkspace resolver shouldn't assume classes are under target/classes

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-149?page=com.atlassian.jira.plu... ] Karel Piwko commented on SHRINKRES-149: --------------------------------------- There are approaches to the problem: a/ You let Maven identify what should be done * Resolver will use pom.xml file and it will build artifact itself using MavenImporter b/ You scan the classpath * Classpath resolution is a hack. It basically goes through classpath elements and does some assumptions about what directories belong to what submodules. In case a submodule is identified (via having pom.xml in a specific location, as it is not possible to figure that out from classpath itself), it will grab stuff according to the pom location. So, basically workflow should be following: 1/ Parse classpath 2/ Figure out POM file next to the classpath - that would be a slow operation as it would require us to traverse file system 3/ Parse pom files and identify what elements of classpath match what G:A:Vs 4/ Package classpath directories as jars/wars/ears based on information in pom.xml As you can see, there is no easy way how to propagate information from Eclipse here. If Eclipse has different classpath than pom.xml, we have no information how to build the SNAPSHOT jar. So, I'd rather suggest you to let ShrinkWrap MavenImporter build .../../pom.xml file yourself. If you need some specific Eclipse stuff to get propagated there, the best way would be to create a profile that will be activated (e.g. via a system property) when tested from IDE. [~m_baechler] Would that help? > Maven classpathworkspace resolver shouldn't assume classes are under target/classes > ----------------------------------------------------------------------------------- > > Key: SHRINKRES-149 > URL: https://issues.jboss.org/browse/SHRINKRES-149 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Affects Versions: 2.0.0 > Reporter: Matthieu Baechler > Assignee: Andrew Rubinger > > To avoid conflicting builds between Maven and Eclipse, I put eclipse build into a "eclipse-build/classes" directory. > Considering this configuration, with the following code : > {code:java} > Maven.resolver() > .offline() > .loadPomFromFile("../../pom.xml") > .resolve("com.linagora.obm:services-module:2.6.0-SNAPSHOT") > .withClassPathResolution(true) > .withTransitivity() > .asFile(); > {code} > Maven resolver find my services-module on the classpath, but when trying a build a jar, it fails in MavenResolvedArtifactImpl.artifactToFile : > {code:java} > // SHRINKRES-102, allow test classes to be packaged as well > File root = new File(artifact.getFile().getParentFile(), "target/classes"); > {code} > In my case, target/classes contains maven build result and not what's on the classpath. > Can this resolver use the classes on the classpath instead ? -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-161) Log compiler problems in MavenImporter

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-161?page=com.atlassian.jira.plu... ] Karel Piwko resolved SHRINKRES-161. ----------------------------------- Resolution: Done Pushed upstream in https://github.com/shrinkwrap/resolver/commit/3d771b7d1fe8cda3d12aa2407ed... > Log compiler problems in MavenImporter > -------------------------------------- > > Key: SHRINKRES-161 > URL: https://issues.jboss.org/browse/SHRINKRES-161 > Project: ShrinkWrap Resolvers > Issue Type: Enhancement > Components: impl-maven > Affects Versions: 2.0.1 > Reporter: Karel Piwko > Assignee: Karel Piwko > Fix For: 2.0.2 > > > If MavenImporter fails, before exception is thrown it should be logged. Arquillian sometimes consumes the exception thrown in @Deployment method, making it difficult to spot real problem. -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-160) Compiler Plugin does not support compilerArgs and compilerArgument

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-160?page=com.atlassian.jira.plu... ] Karel Piwko resolved SHRINKRES-160. ----------------------------------- Resolution: Done Pushed upstream in https://github.com/shrinkwrap/resolver/commit/9f62401cc38621825dd4a917758... > Compiler Plugin does not support compilerArgs and compilerArgument > ------------------------------------------------------------------ > > Key: SHRINKRES-160 > URL: https://issues.jboss.org/browse/SHRINKRES-160 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: impl-maven > Affects Versions: 2.0.1 > Reporter: Karel Piwko > Assignee: Karel Piwko > Fix For: 2.0.2 > > > Currently, only compilerArguments are supported from compiler plugin in MavenImporter. -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-158) Wrong parsing of plugins with list configuration

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-158?page=com.atlassian.jira.plu... ] Karel Piwko resolved SHRINKRES-158. ----------------------------------- Resolution: Done Pushed upstream in https://github.com/shrinkwrap/resolver/commit/49db163a38c740befb044cfd5e1... > Wrong parsing of plugins with list configuration > ------------------------------------------------ > > Key: SHRINKRES-158 > URL: https://issues.jboss.org/browse/SHRINKRES-158 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Components: impl-maven > Affects Versions: 2.0.1 > Reporter: Karel Piwko > Assignee: Karel Piwko > Fix For: 2.0.2 > > > *When*: > I want to parse an argument list via MavenImporter in a plugin configuration. > *Then*: > A expect that arguments will be correctly propagated. > *Current behavior*: > Default value is always retrieved due to bug in ConfigurationUtils. -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-159) Update JUnit to 4.11

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-159?page=com.atlassian.jira.plu... ] Karel Piwko resolved SHRINKRES-159. ----------------------------------- Resolution: Done Pushed upstream in https://github.com/shrinkwrap/resolver/commit/735306544d61e98cb389fd6636e... > Update JUnit to 4.11 > -------------------- > > Key: SHRINKRES-159 > URL: https://issues.jboss.org/browse/SHRINKRES-159 > Project: ShrinkWrap Resolvers > Issue Type: Component Upgrade > Affects Versions: 2.0.1 > Reporter: Karel Piwko > Assignee: Karel Piwko > > This change will allow us to work better with assertThat in tests. -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-159) Update JUnit to 4.11

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-159?page=com.atlassian.jira.plu... ] Karel Piwko updated SHRINKRES-159: ---------------------------------- Affects Version/s: 2.0.1 > Update JUnit to 4.11 > -------------------- > > Key: SHRINKRES-159 > URL: https://issues.jboss.org/browse/SHRINKRES-159 > Project: ShrinkWrap Resolvers > Issue Type: Component Upgrade > Affects Versions: 2.0.1 > Reporter: Karel Piwko > Assignee: Karel Piwko > > This change will allow us to work better with assertThat in tests. -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-161) Log compiler problems in MavenImporter

by Karel Piwko (JIRA)

Karel Piwko created SHRINKRES-161: ------------------------------------- Summary: Log compiler problems in MavenImporter Key: SHRINKRES-161 URL: https://issues.jboss.org/browse/SHRINKRES-161 Project: ShrinkWrap Resolvers Issue Type: Enhancement Components: impl-maven Affects Versions: 2.0.1 Reporter: Karel Piwko Assignee: Karel Piwko Fix For: 2.0.2 If MavenImporter fails, before exception is thrown it should be logged. Arquillian sometimes consumes the exception thrown in @Deployment method, making it difficult to spot real problem. -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-160) Compiler Plugin does not support compilerArgs and compilerArgument

by Karel Piwko (JIRA)

Karel Piwko created SHRINKRES-160: ------------------------------------- Summary: Compiler Plugin does not support compilerArgs and compilerArgument Key: SHRINKRES-160 URL: https://issues.jboss.org/browse/SHRINKRES-160 Project: ShrinkWrap Resolvers Issue Type: Feature Request Components: impl-maven Affects Versions: 2.0.1 Reporter: Karel Piwko Assignee: Karel Piwko Fix For: 2.0.2 Currently, only compilerArguments are supported from compiler plugin in MavenImporter. -- 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

12 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues January 2014