July 2013 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] (SHRINKWRAP-460) Provide a ManifestBuilder

by Thomas Diesler (JIRA)

Thomas Diesler created SHRINKWRAP-460: ----------------------------------------- Summary: Provide a ManifestBuilder Key: SHRINKWRAP-460 URL: https://issues.jboss.org/browse/SHRINKWRAP-460 Project: ShrinkWrap Issue Type: Task Reporter: Thomas Diesler WildFly has a dependency on [jbosgi-metadata|https://github.com/tdiesler/jbosgi-metadata] because of frequent usage of it's [ManifestBuilder|https://github.com/tdiesler/jbosgi-metadata/blob/master/s...] Please also consider moving the [OSGiManifestBuilder|https://github.com/tdiesler/jbosgi-metadata/blob/mast...] to shrinkwrap. -- 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

10 years, 9 months

1
0
0 / 0

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

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-143?page=com.atlassian.jira.plu... ] Michal Matloka commented on SHRINKRES-143: ------------------------------------------ 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. > 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: Andrew Rubinger > > 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-459) Misleading exception message when creating an Archive from a Zip file

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-459?page=com.atlassian.jira.pl... ] Michal Matloka reassigned SHRINKWRAP-459: ----------------------------------------- Assignee: Michal Matloka > Misleading exception message when creating an Archive from a Zip file > --------------------------------------------------------------------- > > Key: SHRINKWRAP-459 > URL: https://issues.jboss.org/browse/SHRINKWRAP-459 > Project: ShrinkWrap > Issue Type: Bug > Affects Versions: 1.1.2 > Reporter: René Link > Assignee: Michal Matloka > > When I try to create an Archive from a zip file using > ShrinkWrap.createFromZipFile(WebArchive.class, new File("not-existent-file.zip")); > I get: > IllegalArgumentException: File for import exist: not-existent-file.zip > I took a look at the source code and found that the > org.jboss.shrinkwrap.api.ArchiveFactory.createFromZipFile(Class<T>, File) > contains the statement > if (!(archiveFile.exists())) { > throw new IllegalArgumentException("File for import exist: " > + archiveFile.getAbsolutePath()); > } > I guess the exception message should be: File for import does not exist: -- 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

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-433) Race condition deadlock in TarGz Exporter

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-433?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on SHRINKWRAP-433: ---------------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> made a comment on [bug 875031|https://bugzilla.redhat.com/show_bug.cgi?id=875031] Edited doc text for wfk 2.3 release notes. > Race condition deadlock in TarGz Exporter > ----------------------------------------- > > Key: SHRINKWRAP-433 > URL: https://issues.jboss.org/browse/SHRINKWRAP-433 > Project: ShrinkWrap > Issue Type: Bug > Components: impl-base > Affects Versions: 1.0.1 > Environment: RHEL6 32bit + Oracle JDK 6, Oracle JDK 7, OpenJDK 7 > Windows 2008 32 bit + Oracle JDK 7 > Solaris 10 32 bit + Oracle JDK 6, Oracle JDK 7 > Reporter: Karel Piwko > Assignee: Michal Matloka > Fix For: 1.1.1 > > > There is a deadlock which is triggered on various platforms concerning handling of TarGz archives. Concerned environments are listed in the environment field. > Following error is logged by Jenkins > {code} > 11:48:05 Running org.jboss.shrinkwrap.impl.base.exporter.TarGzExporterTestCase > 16:45:04 Build timed out (after 300 minutes). Marking the build as aborted. > {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

10 years, 10 months

1
0
0 / 0

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

by Tamás Kimmel (JIRA)

Tamás Kimmel created SHRINKRES-143: -------------------------------------- Summary: 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: Andrew Rubinger 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-459) Misleading exception message when creating an Archive from a Zip file

by René Link (JIRA)

René Link created SHRINKWRAP-459: ------------------------------------ Summary: Misleading exception message when creating an Archive from a Zip file Key: SHRINKWRAP-459 URL: https://issues.jboss.org/browse/SHRINKWRAP-459 Project: ShrinkWrap Issue Type: Bug Affects Versions: 1.1.2 Reporter: René Link When I try to create an Archive from a zip file using ShrinkWrap.createFromZipFile(WebArchive.class, new File("not-existent-file.zip")); I get: IllegalArgumentException: File for import exist: not-existent-file.zip I took a look at the source code and found that the org.jboss.shrinkwrap.api.ArchiveFactory.createFromZipFile(Class<T>, File) contains the statement if (!(archiveFile.exists())) { throw new IllegalArgumentException("File for import exist: " + archiveFile.getAbsolutePath()); } I guess the exception message should be: File for import does not exist: -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-132) MavenImport should have different name

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-132?page=com.atlassian.jira.plu... ] Michal Matloka commented on SHRINKRES-132: ------------------------------------------ So I would vote for MavenBuilder > MavenImport should have different name > -------------------------------------- > > Key: SHRINKRES-132 > URL: https://issues.jboss.org/browse/SHRINKRES-132 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: impl-maven > Affects Versions: 2.0.0 > Reporter: Karel Piwko > Assignee: Andrew Rubinger > Priority: Minor > > MavenImporter is now able to build the project from pom.xml. This means that MavenImporter name is no longer valid, as it does not promote the fact that project will be build from scratch. > It might be MavenBuilder 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-132) MavenImport should have different name

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-132?page=com.atlassian.jira.plu... ] Michal Matloka reassigned SHRINKRES-132: ---------------------------------------- Assignee: Michal Matloka (was: Andrew Rubinger) > MavenImport should have different name > -------------------------------------- > > Key: SHRINKRES-132 > URL: https://issues.jboss.org/browse/SHRINKRES-132 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: impl-maven > Affects Versions: 2.0.0 > Reporter: Karel Piwko > Assignee: Michal Matloka > Priority: Minor > > MavenImporter is now able to build the project from pom.xml. This means that MavenImporter name is no longer valid, as it does not promote the fact that project will be build from scratch. > It might be MavenBuilder 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-116) Gradle support

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-116?page=com.atlassian.jira.plu... ] Michal Matloka commented on SHRINKRES-116: ------------------------------------------ Back to coding this feature. I have to research a few important aspects like e.g. build output archive name. > Gradle support > -------------- > > Key: SHRINKRES-116 > URL: https://issues.jboss.org/browse/SHRINKRES-116 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Affects Versions: 2.0.0-beta-2 > Reporter: Michal Matloka > Assignee: Michal Matloka > > ShrinkWrap Resolver was designed to support multiple dependency management/build systems. It seems that there are already people using Gradle wanting to use ShrinkWrap. API seems much more friendly than Aether ;) and probably even supports build in 'build' feature. > http://forums.gradle.org/gradle/topics/dependency_resolution_with_gradle_... > http://gradle.1045684.n5.nabble.com/Gradle-support-for-Arquillian-maybe-a... > https://community.jboss.org/message/772433 -- 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

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-132) MavenImport should have different name

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-132?page=com.atlassian.jira.plu... ] Karel Piwko commented on SHRINKRES-132: --------------------------------------- I think we can always keep current MavenImporter as a @Deprecated facade to the new name, keeping backwards compatibility. > MavenImport should have different name > -------------------------------------- > > Key: SHRINKRES-132 > URL: https://issues.jboss.org/browse/SHRINKRES-132 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: impl-maven > Affects Versions: 2.0.0 > Reporter: Karel Piwko > Assignee: Andrew Rubinger > Priority: Minor > > MavenImporter is now able to build the project from pom.xml. This means that MavenImporter name is no longer valid, as it does not promote the fact that project will be build from scratch. > It might be MavenBuilder 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

10 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues July 2013