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)