[shrinkwrap-issues] [JBoss JIRA] (SHRINKRES-263) Shrinkwrap resolver does not honor war dependencies

[Florian Besser (JIRA)]

     [ https://issues.jboss.org/browse/SHRINKRES-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Florian Besser updated SHRINKRES-263:
-------------------------------------
    Description: 
The class MavenResolvedArtifactImpl will try to resolve mvn artifacts. This works well since 2.2.5, for jar and test dependencies.

For war dependencies this is still problematic though. The code looks like this:

{code:java}
// SHRINKRES-102, allow test classes to be packaged as well
File root = new File(artifact.getFile().getParentFile(), "target/classes");
if (!Validate.isNullOrEmpty(classifier) && "tests".equals(classifier)) {
  root = new File(artifact.getFile().getParentFile(), "target/test-classes");
}
{code}

In other words, it will locate the pom, say _foo/bar/pom.xml_, and from there try to resolve _../target/classes_ or  _../target/test-classes_ for tests.

In case the pom has _<packaging>war</packaging>_ this is not sufficient however. The Maven war plugin creates its output in _../target/$project.artifactId-$project.version_.

So if the Shrinkwrap resolver is used to resolve a .war, it will create a .war file with the wrong contents. This can be demonstrated for JavaEE with the _beans.xml_ resource.

Test setup:
A WAR project, with a _beans.xml_ resource located at _src/main/resources/META-INF/beans.xml_

Current behaviour:
Shrinkwrap will build a .war file with the contents of _../target/classes_, so the _beans.xml_ is added as _META-INF/beans.xml_ inside the .war. This is the wrong location.

Correct behaviour:
Shrinkwrap should look for a _../target/$project.artifactId-$project.version_ directory for .war files, where the mvn war plugin places the exploded war file contents. This results in a .war file where the _beans.xml_ is added as _WEB-INF/classes/META-INF/beans.xml_.

  was:
The class MavenResolvedArtifactImpl will try to resolve mvn artifacts. This works well since 2.2.5, for jar and test dependencies.

For war dependencies this is still problematic though. The code looks like this:

{code:java}
// SHRINKRES-102, allow test classes to be packaged as well
File root = new File(artifact.getFile().getParentFile(), "target/classes");
if (!Validate.isNullOrEmpty(classifier) && "tests".equals(classifier)) {
  root = new File(artifact.getFile().getParentFile(), "target/test-classes");
}
{code}

In other words, it will locate the pom, say_ foo/bar/pom.xml_, and from there try to resolve _../target/classes_ or  _../target/test-classes_ for tests.

In case the pom has _<packaging>war</packaging>_ this is not sufficient however. The Maven war plugin creates its output in _../target/$project.artifactId-$project.version_.

So if the Shrinkwrap resolver is used to resolve a .war, it will create a .war file with the wrong contents. This can be demonstrated for JavaEE with the _beans.xml_ resource.

Test setup:
A WAR project, with a _beans.xml_ resource located at _src/main/resources/META-INF/beans.xml_

Current behaviour:
Shrinkwrap will build a .war file with the contents of _../target/classes_, so the _beans.xml_ is added as _META-INF/beans.xml_ inside the .war. This is the wrong location.

Correct behaviour:
Shrinkwrap should look for a _../target/$project.artifactId-$project.version_ directory for .war files, where the mvn war plugin places the exploded war file contents. This results in a .war file where the _beans.xml_ is added as _WEB-INF/classes/META-INF/beans.xml_.



> Shrinkwrap resolver does not honor war dependencies
> ---------------------------------------------------
>
>                 Key: SHRINKRES-263
>                 URL: https://issues.jboss.org/browse/SHRINKRES-263
>             Project: ShrinkWrap Resolvers
>          Issue Type: Bug
>          Components: maven
>    Affects Versions: 2.2.0, 2.2.1, 2.2.2, 2.2.3, 2.2.4, 2.2.5
>            Reporter: Florian Besser
>
> The class MavenResolvedArtifactImpl will try to resolve mvn artifacts. This works well since 2.2.5, for jar and test dependencies.
> For war dependencies this is still problematic though. The code looks like this:
> {code:java}
> // SHRINKRES-102, allow test classes to be packaged as well
> File root = new File(artifact.getFile().getParentFile(), "target/classes");
> if (!Validate.isNullOrEmpty(classifier) && "tests".equals(classifier)) {
>   root = new File(artifact.getFile().getParentFile(), "target/test-classes");
> }
> {code}
> In other words, it will locate the pom, say _foo/bar/pom.xml_, and from there try to resolve _../target/classes_ or  _../target/test-classes_ for tests.
> In case the pom has _<packaging>war</packaging>_ this is not sufficient however. The Maven war plugin creates its output in _../target/$project.artifactId-$project.version_.
> So if the Shrinkwrap resolver is used to resolve a .war, it will create a .war file with the wrong contents. This can be demonstrated for JavaEE with the _beans.xml_ resource.
> Test setup:
> A WAR project, with a _beans.xml_ resource located at _src/main/resources/META-INF/beans.xml_
> Current behaviour:
> Shrinkwrap will build a .war file with the contents of _../target/classes_, so the _beans.xml_ is added as _META-INF/beans.xml_ inside the .war. This is the wrong location.
> Correct behaviour:
> Shrinkwrap should look for a _../target/$project.artifactId-$project.version_ directory for .war files, where the mvn war plugin places the exploded war file contents. This results in a .war file where the _beans.xml_ is added as _WEB-INF/classes/META-INF/beans.xml_.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)