[JBoss JIRA] (SHRINKRES-263) Shrinkwrap resolver does not honor war dependencies
by Matous Jobanek (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-263?page=com.atlassian.jira.plu... ]
Matous Jobanek closed SHRINKRES-263.
------------------------------------
Resolution: Done
Pushed upstream in master branch: https://github.com/shrinkwrap/resolver/commit/f04847288f077f396c2592c07c8...
and in 2.2.x branch: https://github.com/shrinkwrap/resolver/commit/16c21f2d634d152d86d3980194a...
I've just released the staging repo, so the version 2.2.6 should be in maven cetral tomorrow (or the next day).
Thank you [~florian.besser] for your contribution
> 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
> Assignee: Florian Besser
> Fix For: 3.0.0-alpha-3, 2.2.6
>
>
> 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)
7 years, 2 months
[JBoss JIRA] (SHRINKRES-263) Shrinkwrap resolver does not honor war dependencies
by Matous Jobanek (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-263?page=com.atlassian.jira.plu... ]
Matous Jobanek updated SHRINKRES-263:
-------------------------------------
Fix Version/s: 2.2.6
3.0.0-alpha-3
> 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
> Fix For: 3.0.0-alpha-3, 2.2.6
>
>
> 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)
7 years, 2 months
[JBoss JIRA] (SHRINKRES-263) Shrinkwrap resolver does not honor war dependencies
by Matous Jobanek (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-263?page=com.atlassian.jira.plu... ]
Matous Jobanek reassigned SHRINKRES-263:
----------------------------------------
Assignee: Florian Besser
> 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
> Assignee: Florian Besser
> Fix For: 3.0.0-alpha-3, 2.2.6
>
>
> 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)
7 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 commented on SHRINKRES-263:
------------------------------------------
Hi [~mjobanek]. We've successfully tested the 2.2.6 from staging - from our side we'd be happy with this new version.
Thanks again for your efforts :)
> 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)
7 years, 2 months
[JBoss JIRA] (SHRINKWRAP-511) ArchiveFactory fails to close ZipFile and retains a Windows file lock
by Andy Gumbrecht (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-511?page=com.atlassian.jira.pl... ]
Andy Gumbrecht commented on SHRINKWRAP-511:
-------------------------------------------
Please take a look at org.jboss.shrinkwrap.impl.base.asset.ZipFileEntryAsset vs org.wildfly.swarm.tools.ZipFileHeaderAsset
*ZipFileHeaderAsset* has return zipFile.getInputStream(fileHeader); <-- This is the culprit. zipFile never gets closed.
*ZipFileEntryAsset* wraps both the stream and file. When the stream is closed, so is the file.
I think you'll find that net.lingala.zip4j.core.ZipFile is not required if you make that change.
> ArchiveFactory fails to close ZipFile and retains a Windows file lock
> ---------------------------------------------------------------------
>
> Key: SHRINKWRAP-511
> URL: https://issues.jboss.org/browse/SHRINKWRAP-511
> Project: ShrinkWrap
> Issue Type: Bug
> Components: api
> Affects Versions: 1.2.6
> Environment: Windows only - All versions
> Reporter: Andy Gumbrecht
> Fix For: 1.2.7
>
>
> org/jboss/shrinkwrap/api/ArchiveFactory.java:187
> The ZipFile is never closed and results in a file lock on Windows only platforms.
> https://github.com/shrinkwrap/shrinkwrap/pull/102
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (SHRINKRES-263) Shrinkwrap resolver does not honor war dependencies
by Matous Jobanek (JIRA)
[ https://issues.jboss.org/browse/SHRINKRES-263?page=com.atlassian.jira.plu... ]
Matous Jobanek commented on SHRINKRES-263:
------------------------------------------
Hi,
you don't bother at all. I'm so sorry that I didn't reply earlier. I don't know why, but I haven't received any notification - I need to check my email-notification-settings.
Thank you so much for reporting and fixing another issue. I checked the code, and it looks good.
Your commits are now on both branches master and 2.2.x.
Here is staging repository for 2.2.6 release containing your fix: https://repository.jboss.org/nexus/content/repositories/jboss_releases_st...
You can try it if you find any other issue. If it is OK, I'll release it tomorrow.
Thank you very much
> 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)
7 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 commented on SHRINKRES-263:
------------------------------------------
Sorry to bother you again, but this issue is currently blocking testing - could you give me feedback whether the pull request is any good or not?
[~mjobanek]: You might be familiar with my previous issue SHRINKRES-259
> 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)
7 years, 2 months