April 2016 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] (SHRINKWRAP-502) Shrinkwrap-resolver doesn't honor classpath-jars

by Geraint Ascanis (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-502?page=com.atlassian.jira.pl... ] Geraint Ascanis updated SHRINKWRAP-502: --------------------------------------- Description: If an arquillian-test is started via command line and the passed class path (via {{-classpath}}) only contains a jar file with a MANIFEST.MF which describes the class path in its {{Class-Path}} directive - the test doesn't honor this extended class path. That's specifically a problem if the test is run from within an IDE that gives dependend changed files to the test run via the class path. For exmaple, the attached jar is used as only parameter to {{-classpath}} with the intention to populate the class path. The problem resides in {code:java}org.jboss.shrinkwrap.resolver.impl.maven.aether.ClasspathWorkspaceReader#getClassPathEntries{code} where the content of the system property {{java.class.path}} ist just exploded at the {{pathSeparatorChar}} and returns just the single jar - that doesn't suffice for the test (i.e. the dependencies are always resolved from the maven repository - without any fresh local changes) The problem affects me only from within IntelliJIDEA under windows where the command line of a specific test sums up to 68k of text - which is too much for windows. That's why, IntelliJ offers the {{dynamic.classpath}} property, which enables the use of a classpath.jar - that isn't honored in the test run. This property is *mandatory* on windows - there's no other way to start the test with this very long command line as using this classpath.jar. was: If an arquillian-test is started via command line and the passes class path via {{-classpath}} only contains a jar file with a MANIFEST.MF which describes the class path in its {{Class-Path}} directive - the test doesn't honor this extended class path. That's specifically a problem if the test is run from within an IDE that gives dependend changed files to the test run via the class path. For exmaple, the attached jar is used as only parameter to {{-classpath}} with the intention to populate the class path. The problem resides in {code:java}org.jboss.shrinkwrap.resolver.impl.maven.aether.ClasspathWorkspaceReader#getClassPathEntries{code} where the content of the system property {{java.class.path}} ist just exploded at the {{pathSeparatorChar}} and returns just the single jar - that doesn't suffice for the test (i.e. the dependencies are always resolved from the maven repository - without any fresh local changes) The problem affects me only from within IntelliJIDEA under windows where the command line of a specific test sums up to 68k of text - which is too much for windows. That's why, IntelliJ offers the {{dynamic.classpath}} property, which enables the use of a classpath.jar - that isn't honored in the test run. This property is *mandatory* on windows - there's no other way to start the test with this very long command line as using this classpath.jar. > Shrinkwrap-resolver doesn't honor classpath-jars > ------------------------------------------------ > > Key: SHRINKWRAP-502 > URL: https://issues.jboss.org/browse/SHRINKWRAP-502 > Project: ShrinkWrap > Issue Type: Bug > Reporter: Geraint Ascanis > Attachments: classpath361.jar > > > If an arquillian-test is started via command line and the passed class path (via {{-classpath}}) only contains a jar file with a MANIFEST.MF which describes the class path in its {{Class-Path}} directive - the test doesn't honor this extended class path. > That's specifically a problem if the test is run from within an IDE that gives dependend changed files to the test run via the class path. For exmaple, the attached jar is used as only parameter to {{-classpath}} with the intention to populate the class path. > The problem resides in > {code:java}org.jboss.shrinkwrap.resolver.impl.maven.aether.ClasspathWorkspaceReader#getClassPathEntries{code} > where the content of the system property {{java.class.path}} ist just exploded at the {{pathSeparatorChar}} and returns just the single jar - that doesn't suffice for the test (i.e. the dependencies are always resolved from the maven repository - without any fresh local changes) > The problem affects me only from within IntelliJIDEA under windows where the command line of a specific test sums up to 68k of text - which is too much for windows. That's why, IntelliJ offers the {{dynamic.classpath}} property, which enables the use of a classpath.jar - that isn't honored in the test run. This property is *mandatory* on windows - there's no other way to start the test with this very long command line as using this classpath.jar. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-502) Shrinkwrap-resolver doesn't honor classpath-jars

by Geraint Ascanis (JIRA)

Geraint Ascanis created SHRINKWRAP-502: ------------------------------------------ Summary: Shrinkwrap-resolver doesn't honor classpath-jars Key: SHRINKWRAP-502 URL: https://issues.jboss.org/browse/SHRINKWRAP-502 Project: ShrinkWrap Issue Type: Bug Reporter: Geraint Ascanis Attachments: classpath361.jar If an arquillian-test is started via command line and the passes class path via {{-classpath}} only contains a jar file with a MANIFEST.MF which describes the class path in its {{Class-Path}} directive - the test doesn't honor this extended class path. That's specifically a problem if the test is run from within an IDE that gives dependend changed files to the test run via the class path. For exmaple, the attached jar is used as only parameter to {{-classpath}} with the intention to populate the class path. The problem resides in {code:java}org.jboss.shrinkwrap.resolver.impl.maven.aether.ClasspathWorkspaceReader#getClassPathEntries{code} where the content of the system property {{java.class.path}} ist just exploded at the {{pathSeparatorChar}} and returns just the single jar - that doesn't suffice for the test (i.e. the dependencies are always resolved from the maven repository - without any fresh local changes) The problem affects me only from within IntelliJIDEA under windows where the command line of a specific test sums up to 68k of text - which is too much for windows. That's why, IntelliJ offers the {{dynamic.classpath}} property, which enables the use of a classpath.jar - that isn't honored in the test run. This property is *mandatory* on windows - there's no other way to start the test with this very long command line as using this classpath.jar. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-199) SWR, Stop searching in other repositories, if it finds the artifact at first.

by Christian Schulz (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-199?page=com.atlassian.jira.plu... ] Christian Schulz edited comment on SHRINKRES-199 at 4/27/16 2:42 AM: --------------------------------------------------------------------- [~mjobanek] What about updating aether version? Currently version 1.0.0.v20140518 is used. In newer maven versions newer aether versions are used. https://github.com/shrinkwrap/resolver/blob/5d5f7e1d47a3ecd70ddcacea3918b... was (Author: chschulz): [~mjobanek] What about updating aether version? Currently version 1.0.0.v20140518 is used. In newer maven versions newer aether versions are used. > SWR, Stop searching in other repositories, if it finds the artifact at first. > ----------------------------------------------------------------------------- > > Key: SHRINKRES-199 > URL: https://issues.jboss.org/browse/SHRINKRES-199 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: maven > Reporter: Srinivas Akula > Fix For: 3.0.0 > > > Shrinkwraps Resolver always look into all the repositories > configured in POM/settings.xml including http://repo1.maven.org/maven/ even though it found the artifact and it waits for time out there. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-199) SWR, Stop searching in other repositories, if it finds the artifact at first.

by Christian Schulz (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-199?page=com.atlassian.jira.plu... ] Christian Schulz commented on SHRINKRES-199: -------------------------------------------- [~mjobanek] What about updating aether version? Currently version 1.0.0.v20140518 is used. In newer maven versions newer aether versions are used. > SWR, Stop searching in other repositories, if it finds the artifact at first. > ----------------------------------------------------------------------------- > > Key: SHRINKRES-199 > URL: https://issues.jboss.org/browse/SHRINKRES-199 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: maven > Reporter: Srinivas Akula > Fix For: 3.0.0 > > > Shrinkwraps Resolver always look into all the repositories > configured in POM/settings.xml including http://repo1.maven.org/maven/ even though it found the artifact and it waits for time out there. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-242) Files without license headers

by Matous Jobanek (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-242?page=com.atlassian.jira.plu... ] Matous Jobanek reassigned SHRINKRES-242: ---------------------------------------- Assignee: Matous Jobanek > Files without license headers > ----------------------------- > > Key: SHRINKRES-242 > URL: https://issues.jboss.org/browse/SHRINKRES-242 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Affects Versions: 2.2.2 > Environment: Fedora Linux > Reporter: gil cattaneo > Assignee: Matous Jobanek > > Hi > The following source files are without license headers: > ./api-maven/src/main/java/org/jboss/shrinkwrap/resolver/api/maven/repository/MavenChecksumPolicy.java > ./api-maven/src/main/java/org/jboss/shrinkwrap/resolver/api/maven/repository/MavenUpdatePolicy.java > ./api-maven/src/main/java/org/jboss/shrinkwrap/resolver/api/maven/repository/MavenRemoteRepository.java > ./api-maven/src/main/java/org/jboss/shrinkwrap/resolver/api/maven/repository/MavenRemoteRepositories.java > ./api-maven/src/main/java/org/jboss/shrinkwrap/resolver/api/maven/repository/MavenRemoteRepositoryImpl.java > ./api-maven/src/main/java/org/jboss/shrinkwrap/resolver/api/maven/MavenArtifactInfo.java > ./impl-maven/src/main/java/org/jboss/shrinkwrap/resolver/impl/maven/MavenArtifactInfoImpl.java > ./impl-maven/src/main/java/org/jboss/shrinkwrap/resolver/impl/maven/GetTcclAction.java > ./impl-maven/src/main/java/org/jboss/shrinkwrap/resolver/impl/maven/MavenResolveStageBaseImpl.java > ./impl-gradle-embedded-archive/src/it/jar-sample/src/main/java/test/JarClass.java > ./impl-gradle-embedded-archive/src/it/jar-sample/src/main/java/test/nested/NestedJarClass.java > ./impl-gradle-embedded-archive/src/it/multi-module-sample/module-one/src/main/java/test/JarClass.java > ./impl-gradle-embedded-archive/src/it/war-sample/src/main/java/test/nested/NestedWarClass.java > ./impl-maven-archive/src/it/jar-sample/src/main/java/test/JarClass.java > ./impl-maven-archive/src/it/jar-sample/src/main/java/test/nested/NestedJarClass.java > ./impl-maven-archive/src/it/jar-with-mf-sample/src/main/java/test/JarClass.java > ./impl-maven-archive/src/it/jar-without-resources/src/main/java/test/JarClass.java > ./impl-maven-archive/src/it/jar-without-resources/src/main/java/test/nested/NestedJarClass.java > ./impl-maven-archive/src/it/war-sample/src/main/java/test/nested/NestedWarClass.java > ./impl-maven-integration-tests/jar-sample/src/main/java/test/JarClass.java > ./maven-plugin/src/it/context-propagation/src/test/java/org/jboss/shrinkwrap/resolver/plugin/test/PluginIntegrationTestCase.java > ./maven-plugin/src/it/context-propagation/src/test/java/org/jboss/shrinkwrap/resolver/plugin/test/ExecutionPropagationTestCase.java > Please, add license header > https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging... > Thanks in advance > Regards -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-243) org.jboss.shrinkwrap.resolver.api.ResolutionException: Unable to get version for dependency specified by ..., it was not provided in neither <dependencyManagement> nor <dependencies> sections.

by Gunther v. Wolffersdorff (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-243?page=com.atlassian.jira.plu... ] Gunther v. Wolffersdorff updated SHRINKRES-243: ----------------------------------------------- Environment: Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 14:51:28+0100) Java version: 1.8.0_45, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.8.0_45\jre Default locale: de_DE, platform encoding: Cp1252 OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos" was: Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 14:51:28+0100) Maven home: D:\development\jbossDev\maven Java version: 1.8.0_45, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.8.0_45\jre Default locale: de_DE, platform encoding: Cp1252 OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos" > org.jboss.shrinkwrap.resolver.api.ResolutionException: Unable to get version for dependency specified by ..., it was not provided in neither <dependencyManagement> nor <dependencies> sections. > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > Key: SHRINKRES-243 > URL: https://issues.jboss.org/browse/SHRINKRES-243 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Components: maven > Affects Versions: 2.1.0, 2.2.1, 2.2.2 > Environment: Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 14:51:28+0100) > Java version: 1.8.0_45, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.8.0_45\jre > Default locale: de_DE, platform encoding: Cp1252 > OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos" > Reporter: Gunther v. Wolffersdorff > Attachments: sample.zip > > > shrinkwrap-resolver-impl-maven : Unable to get version for dependency specified by ..., it was not provided in neither <dependencyManagement> nor <dependencies> sections. > In Java EE Project based upon arche type wildfly-javaee7-webapp-ear-archetype we have the following pom-situation: > - parent-project > - ejb-project > - web-project ( depends on ejb-project) > - parent-project defines versions of subprojects by dependency management > In web-project, if we want to resolve the ejb-project by: > {{resolver.resolve("de.alvara.ticket:sample-ejb").withoutTransitivity().asSingleFile();}} > we get: > org.jboss.shrinkwrap.resolver.api.ResolutionException: Unable to get version for dependency specified by de.alvara.ticket:sample-ejb:compile, it was not provided in neither <dependencyManagement> nor <dependencies> sections. > at org.jboss.shrinkwrap.resolver.impl.maven.task.ResolveVersionFromMetadataTask.execute(ResolveVersionFromMetadataTask.java:122) > at org.jboss.shrinkwrap.resolver.impl.maven.PomEquippedResolveStageBaseImpl.resolveVersion(PomEquippedResolveStageBaseImpl.java:85) > at org.jboss.shrinkwrap.resolver.impl.maven.ResolveStageBaseImpl.resolveDependency(ResolveStageBaseImpl.java:190) > at org.jboss.shrinkwrap.resolver.impl.maven.ResolveStageBaseImpl.resolveDependency(ResolveStageBaseImpl.java:185) > at org.jboss.shrinkwrap.resolver.impl.maven.ResolveStageBaseImpl.resolve(ResolveStageBaseImpl.java:79) > at org.jboss.shrinkwrap.resolver.impl.maven.ResolveStageBaseImpl.resolve(ResolveStageBaseImpl.java:44) > at ShrinkwrapResolverTest.test(ShrinkwrapResolverTest.java:15) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-243) org.jboss.shrinkwrap.resolver.api.ResolutionException: Unable to get version for dependency specified by ..., it was not provided in neither <dependencyManagement> nor <dependencies> sections.

by Gunther v. Wolffersdorff (JIRA)

Gunther v. Wolffersdorff created SHRINKRES-243: -------------------------------------------------- Summary: org.jboss.shrinkwrap.resolver.api.ResolutionException: Unable to get version for dependency specified by ..., it was not provided in neither <dependencyManagement> nor <dependencies> sections. Key: SHRINKRES-243 URL: https://issues.jboss.org/browse/SHRINKRES-243 Project: ShrinkWrap Resolvers Issue Type: Bug Components: maven Affects Versions: 2.2.2, 2.2.1, 2.1.0 Environment: Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 14:51:28+0100) Maven home: D:\development\jbossDev\maven Java version: 1.8.0_45, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.8.0_45\jre Default locale: de_DE, platform encoding: Cp1252 OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "dos" Reporter: Gunther v. Wolffersdorff Attachments: sample.zip shrinkwrap-resolver-impl-maven : Unable to get version for dependency specified by ..., it was not provided in neither <dependencyManagement> nor <dependencies> sections. In Java EE Project based upon arche type wildfly-javaee7-webapp-ear-archetype we have the following pom-situation: - parent-project - ejb-project - web-project ( depends on ejb-project) - parent-project defines versions of subprojects by dependency management In web-project, if we want to resolve the ejb-project by: {{resolver.resolve("de.alvara.ticket:sample-ejb").withoutTransitivity().asSingleFile();}} we get: org.jboss.shrinkwrap.resolver.api.ResolutionException: Unable to get version for dependency specified by de.alvara.ticket:sample-ejb:compile, it was not provided in neither <dependencyManagement> nor <dependencies> sections. at org.jboss.shrinkwrap.resolver.impl.maven.task.ResolveVersionFromMetadataTask.execute(ResolveVersionFromMetadataTask.java:122) at org.jboss.shrinkwrap.resolver.impl.maven.PomEquippedResolveStageBaseImpl.resolveVersion(PomEquippedResolveStageBaseImpl.java:85) at org.jboss.shrinkwrap.resolver.impl.maven.ResolveStageBaseImpl.resolveDependency(ResolveStageBaseImpl.java:190) at org.jboss.shrinkwrap.resolver.impl.maven.ResolveStageBaseImpl.resolveDependency(ResolveStageBaseImpl.java:185) at org.jboss.shrinkwrap.resolver.impl.maven.ResolveStageBaseImpl.resolve(ResolveStageBaseImpl.java:79) at org.jboss.shrinkwrap.resolver.impl.maven.ResolveStageBaseImpl.resolve(ResolveStageBaseImpl.java:44) at ShrinkwrapResolverTest.test(ShrinkwrapResolverTest.java:15) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues April 2016