[
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)