[JBoss JIRA] (SHRINKRES-263) Shrinkwrap resolver does not honor war dependencies
by Florian Besser (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-263?page=com.atlassian.jira.plu... ]
Florian Besser commented on SHRINKRES-263:
------------------------------------------
I've created a pull request:
https://github.com/shrinkwrap/resolver/pull/109
I'd be more than happy if this fix could be included in the 2.2.6 release :)
> 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)
9 years, 2 months
[JBoss JIRA] (SHRINKRES-263) Shrinkwrap resolver does not honor war dependencies
by Florian Besser (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-263?page=com.atlassian.jira.plu... ]
Florian Besser updated SHRINKRES-263:
-------------------------------------
Steps to Reproduce:
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:
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)
9 years, 2 months
[JBoss JIRA] (SHRINKRES-263) Shrinkwrap resolver does not honor war dependencies
by Florian Besser (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-263?page=com.atlassian.jira.plu... ]
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)
9 years, 2 months
[JBoss JIRA] (SHRINKRES-263) Shrinkwrap resolver does not honor war dependencies
by Florian Besser (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-263?page=com.atlassian.jira.plu... ]
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)
9 years, 2 months
[JBoss JIRA] (SHRINKRES-263) Shrinkwrap resolver does not honor war dependencies
by Florian Besser (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-263?page=com.atlassian.jira.plu... ]
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)
9 years, 2 months
[JBoss JIRA] (SHRINKRES-263) Shrinkwrap resolver does not honor war dependencies
by Florian Besser (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-263?page=com.atlassian.jira.plu... ]
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)
9 years, 2 months
[JBoss JIRA] (SHRINKRES-263) Shrinkwrap resolver does not honor war dependencies
by Florian Besser (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-263?page=com.atlassian.jira.plu... ]
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)
9 years, 2 months
[JBoss JIRA] (SHRINKRES-263) Shrinkwrap resolver does not honor war dependencies
by Florian Besser (JIRA)
Florian Besser created SHRINKRES-263:
----------------------------------------
Summary: 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.5, 2.2.4, 2.2.3, 2.2.2, 2.2.1, 2.2.0
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)
9 years, 2 months