[JBoss JIRA] (SHRINKWRAP-506) shrinkwrap maven plugin tests fail with current maven on windows
by Dave Levitt (JIRA)
Dave Levitt created SHRINKWRAP-506:
--------------------------------------
Summary: shrinkwrap maven plugin tests fail with current maven on windows
Key: SHRINKWRAP-506
URL: https://issues.jboss.org/browse/SHRINKWRAP-506
Project: ShrinkWrap
Issue Type: Bug
Components: ext-resolver
Affects Versions: 1.2.3
Environment: Windows 7, Maven 3.3.9, Java 1.8.0_66
Reporter: Dave Levitt
Priority: Minor
The maven-invoker-plugin version specified for integration tests in side the shrinkwrap-resolver-maven-plugin looks to execute mvn.bat on Windows systems.
In the current maven, the windows batch file is mvn.cmd so the test fails to invoke the daughter maven process.
The simple fix is updating the maven-invoker-plugin to the current release version 2.0.0.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (SHRINKWRAP-505) Allow archive.addPackage() flavors to slurp from a .war
by Bob McWhirter (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-505?page=com.atlassian.jira.pl... ]
Bob McWhirter updated SHRINKWRAP-505:
-------------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/shrinkwrap/shrinkwrap/pull/99
> Allow archive.addPackage() flavors to slurp from a .war
> -------------------------------------------------------
>
> Key: SHRINKWRAP-505
> URL: https://issues.jboss.org/browse/SHRINKWRAP-505
> Project: ShrinkWrap
> Issue Type: Feature Request
> Reporter: Bob McWhirter
> Assignee: Bob McWhirter
>
> In WildFly Swarm, we have the case where a .war is on the classpath or otherwise available for constructing subsequent ShrinkWrap archives.
> In the case of
> {code}
> JavaArchive archive = ...
> archive.addPacakge( "some.package.in.the.war" );
> {code}
> ... the classes are not locatable from the .war, given the URL shenanigans that occur and the ClassLoader asset that is used ultimately to load them.
> Ultimately URLPackageScanner should be smart enough to know that classes inside a .war-centric URL are relocated under {WEB-INF/classes}.
> PR is en-route, please hold.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (SHRINKWRAP-505) Allow archive.addPackage() flavors to slurp from a .war
by Bob McWhirter (JIRA)
Bob McWhirter created SHRINKWRAP-505:
----------------------------------------
Summary: Allow archive.addPackage() flavors to slurp from a .war
Key: SHRINKWRAP-505
URL: https://issues.jboss.org/browse/SHRINKWRAP-505
Project: ShrinkWrap
Issue Type: Feature Request
Reporter: Bob McWhirter
Assignee: Bob McWhirter
In WildFly Swarm, we have the case where a .war is on the classpath or otherwise available for constructing subsequent ShrinkWrap archives.
In the case of
{code}
JavaArchive archive = ...
archive.addPacakge( "some.package.in.the.war" );
{code}
... the classes are not locatable from the .war, given the URL shenanigans that occur and the ClassLoader asset that is used ultimately to load them.
Ultimately URLPackageScanner should be smart enough to know that classes inside a .war-centric URL are relocated under {WEB-INF/classes}.
PR is en-route, please hold.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months