[JBoss JIRA] (SHRINKRES-150) Wrong built WebArchive using Shrinkwrap Classpath resolution
by Gunther Klein (JIRA)
Gunther Klein created SHRINKRES-150:
---------------------------------------
Summary: Wrong built WebArchive using Shrinkwrap Classpath resolution
Key: SHRINKRES-150
URL: https://issues.jboss.org/browse/SHRINKRES-150
Project: ShrinkWrap Resolvers
Issue Type: Bug
Environment: win 7 (64 bit), glassfish 3.1.2
Reporter: Gunther Klein
Assignee: Andrew Rubinger
I have defined a simple war project and setup an arquillian test using shrinkwrap 2.0.0, that - as a test - just resolves the web archive via classpath resolution:
@RunWith(Arquillian.class)
public class ShrinkwrapTestIT {
@Deployment
public static Archive<?> createDeployment() {
WebArchive war = Maven.resolver()
.resolve("shrinkwrap.test:shrinkwrap.test:war:0.0.1-SNAPSHOT").withClassPathResolution(true)
.withoutTransitivity().asSingle(WebArchive.class);
System.out.println(war.toString(true));
return war;
}
@Test
public void test() {
//do nothing
}
}
The output shows, that the archive is incomplete (resource files are missing) and not even war conform:
some_text_file.txt
com/
com/test/
com/test/Test.class
If i change the code to use .withClassPathResolution(false), the output is:
/some_text_file.txt
/index.jsp
/com/
/com/test/
/com/test/Test.class
/WEB-INF/
/WEB-INF/web.xml
/WEB-INF/sun-web.xml
/META-INF/
/META-INF/MANIFEST.MF
Now the resources are included, but the class(es) are packaged at the top level and not under /WEB-INF/classes, so it still doesnt respresent a valid war. My pom looks like:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>shrinkwrap.test</groupId>
<artifactId>shrinkwrap.test</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>war</packaging>
<properties>
<project.build.sourceEncoding>ISO8859-1</project.build.sourceEncoding>
<version.shrinkwrap.resolvers>2.0.0</version.shrinkwrap.resolvers>
</properties>
<dependencies>
<!-- test dependencies -->
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.11</version>
</dependency>
<dependency>
<groupId>org.jboss.arquillian.junit</groupId>
<artifactId>arquillian-junit-container</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jboss.arquillian.container</groupId>
<artifactId>arquillian-glassfish-remote-3.1</artifactId>
<version>1.0.0.CR4</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jboss.shrinkwrap.resolver</groupId>
<artifactId>shrinkwrap-resolver-depchain</artifactId>
<version>${version.shrinkwrap.resolvers}</version>
<scope>test</scope>
<type>pom</type>
</dependency>
</dependencies>
<dependencyManagement>
<dependencies>
<!-- Override dependency resolver with latest version. This must go *BEFORE*
the Arquillian BOM. -->
<dependency>
<groupId>org.jboss.shrinkwrap.resolver</groupId>
<artifactId>shrinkwrap-resolver-bom</artifactId>
<version>${version.shrinkwrap.resolvers}</version>
<scope>import</scope>
<type>pom</type>
</dependency>
<dependency>
<groupId>org.jboss.arquillian</groupId>
<artifactId>arquillian-bom</artifactId>
<version>1.1.1.Final</version>
<scope>import</scope>
<type>pom</type>
</dependency>
</dependencies>
</dependencyManagement>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>2.16</version>
<configuration>
<skipTests>${skipITs}</skipTests>
</configuration>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Why is shrinkwrap giving me corrupt archives here in both cases? For the case with classpath resolution i would expect shrinkwrap to give me the war, that was built by maven in the package phase? Without classpath resolution i would expect shrinkwrap to resolve the war from maven respository (local or remote). Or is my understanding of shrinkwrap (classpath) resolution wrong here?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 6 months
[JBoss JIRA] (SHRINKWRAP-466) Maven dependency resolution ignores transitive exclusions
by Ken H (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-466?page=com.atlassian.jira.pl... ]
Ken H commented on SHRINKWRAP-466:
----------------------------------
I apologize in advance for not having an example. If transitive exclusions are not captured in any test case then there should likely be one created.
> Maven dependency resolution ignores transitive exclusions
> ---------------------------------------------------------
>
> Key: SHRINKWRAP-466
> URL: https://issues.jboss.org/browse/SHRINKWRAP-466
> Project: ShrinkWrap
> Issue Type: Bug
> Reporter: Ken H
>
> In certain circumstances, it seems that the Maven resolver (in v2.0.0) is ignoring transitive exclusions.
> Relevant pom.xml:
> {code}
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-core</artifactId>
> <version>${drools.version}</version>
> </dependency>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-compiler</artifactId>
> <version>${drools.version}</version>
> <exclusions>
> <exclusion>
> <groupId>org.antlr</groupId>
> <artifactId>antlr</artifactId>
> </exclusion>
> <exclusion>
> <groupId>org.antlr</groupId>
> <artifactId>antlr-runtime</artifactId>
> </exclusion>
> <exclusion>
> <groupId>antlr</groupId>
> <artifactId>antlr</artifactId>
> </exclusion>
> <exclusion>
> <groupId>antlr</groupId>
> <artifactId>antlr-runtime</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
>
> <dependency>
> <groupId>org.hibernate</groupId>
> <artifactId>hibernate-core</artifactId>
> <version>4.0.1.Final</version>
> <scope>provided</scope>
> <exclusions>
> <exclusion>
> <groupId>antlr</groupId>
> <artifactId>antlr</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
> {code}
> Expected way to build dependency list:
> {code}
> File[] dependencyFiles = Maven.resolver().loadPomFromFile("pom.xml")
> .importRuntimeAndTestDependencies()
> .resolve().withTransitivity().asFile();
> {code}
> However, this results in antlr still being added to the dependency list and the resulting WebArchive.
> My temporary workaround is to explicitly exclude the G:A:
> {code}
> File[] dependencyFiles = Maven.resolver().loadPomFromFile("pom.xml")
> .importRuntimeAndTestDependencies()
> .resolve()
> .using( new RejectDependenciesStrategy(false, "org.antlr:antlr", "antlr:antlr") )
> .withTransitivity().asFile();
> {code}
> Also note that the false is required in the RejectDependenciesStrategy. Without it, all (yes, all) transitive dependencies are ignored. This may be a separate issue but I want to mention it for anyone attempting this workaround.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (SHRINKWRAP-466) Maven dependency resolution ignores transitive exclusions
by Ken H (JIRA)
[ https://issues.jboss.org/browse/SHRINKWRAP-466?page=com.atlassian.jira.pl... ]
Ken H updated SHRINKWRAP-466:
-----------------------------
Description:
In certain circumstances, it seems that the Maven resolver (in v2.0.0) is ignoring transitive exclusions.
Relevant pom.xml:
{code}
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-core</artifactId>
<version>${drools.version}</version>
</dependency>
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-compiler</artifactId>
<version>${drools.version}</version>
<exclusions>
<exclusion>
<groupId>org.antlr</groupId>
<artifactId>antlr</artifactId>
</exclusion>
<exclusion>
<groupId>org.antlr</groupId>
<artifactId>antlr-runtime</artifactId>
</exclusion>
<exclusion>
<groupId>antlr</groupId>
<artifactId>antlr</artifactId>
</exclusion>
<exclusion>
<groupId>antlr</groupId>
<artifactId>antlr-runtime</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>4.0.1.Final</version>
<scope>provided</scope>
<exclusions>
<exclusion>
<groupId>antlr</groupId>
<artifactId>antlr</artifactId>
</exclusion>
</exclusions>
</dependency>
{code}
Expected way to build dependency list:
{code}
File[] dependencyFiles = Maven.resolver().loadPomFromFile("pom.xml")
.importRuntimeAndTestDependencies()
.resolve().withTransitivity().asFile();
{code}
However, this results in antlr still being added to the dependency list and the resulting WebArchive.
My temporary workaround is to explicitly exclude the G:A:
{code}
File[] dependencyFiles = Maven.resolver().loadPomFromFile("pom.xml")
.importRuntimeAndTestDependencies()
.resolve()
.using( new RejectDependenciesStrategy(false, "org.antlr:antlr", "antlr:antlr") )
.withTransitivity().asFile();
{code}
Also note that the false is required in the RejectDependenciesStrategy. Without it, all (yes, all) transitive dependencies are ignored. This may be a separate issue but I want to mention it for anyone attempting this workaround.
was:
In certain circumstances, it seems that the Maven resolver is ignoring transitive exclusions.
Relevant pom.xml:
{code}
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-core</artifactId>
<version>${drools.version}</version>
</dependency>
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-compiler</artifactId>
<version>${drools.version}</version>
<exclusions>
<exclusion>
<groupId>org.antlr</groupId>
<artifactId>antlr</artifactId>
</exclusion>
<exclusion>
<groupId>org.antlr</groupId>
<artifactId>antlr-runtime</artifactId>
</exclusion>
<exclusion>
<groupId>antlr</groupId>
<artifactId>antlr</artifactId>
</exclusion>
<exclusion>
<groupId>antlr</groupId>
<artifactId>antlr-runtime</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>4.0.1.Final</version>
<scope>provided</scope>
<exclusions>
<exclusion>
<groupId>antlr</groupId>
<artifactId>antlr</artifactId>
</exclusion>
</exclusions>
</dependency>
{code}
Expected way to build dependency list:
{code}
File[] dependencyFiles = Maven.resolver().loadPomFromFile("pom.xml")
.importRuntimeAndTestDependencies()
.resolve().withTransitivity().asFile();
{code}
However, this results in antlr still being added to the dependency list and the resulting WebArchive.
My temporary workaround is to explicitly exclude the G:A:
{code}
File[] dependencyFiles = Maven.resolver().loadPomFromFile("pom.xml")
.importRuntimeAndTestDependencies()
.resolve()
.using( new RejectDependenciesStrategy(false, "org.antlr:antlr", "antlr:antlr") )
.withTransitivity().asFile();
{code}
Also note that the false is required in the RejectDependenciesStrategy. Without it, all (yes, all) transitive dependencies are ignored. This may be a separate issue but I want to mention it for anyone attempting this workaround.
> Maven dependency resolution ignores transitive exclusions
> ---------------------------------------------------------
>
> Key: SHRINKWRAP-466
> URL: https://issues.jboss.org/browse/SHRINKWRAP-466
> Project: ShrinkWrap
> Issue Type: Bug
> Reporter: Ken H
>
> In certain circumstances, it seems that the Maven resolver (in v2.0.0) is ignoring transitive exclusions.
> Relevant pom.xml:
> {code}
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-core</artifactId>
> <version>${drools.version}</version>
> </dependency>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-compiler</artifactId>
> <version>${drools.version}</version>
> <exclusions>
> <exclusion>
> <groupId>org.antlr</groupId>
> <artifactId>antlr</artifactId>
> </exclusion>
> <exclusion>
> <groupId>org.antlr</groupId>
> <artifactId>antlr-runtime</artifactId>
> </exclusion>
> <exclusion>
> <groupId>antlr</groupId>
> <artifactId>antlr</artifactId>
> </exclusion>
> <exclusion>
> <groupId>antlr</groupId>
> <artifactId>antlr-runtime</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
>
> <dependency>
> <groupId>org.hibernate</groupId>
> <artifactId>hibernate-core</artifactId>
> <version>4.0.1.Final</version>
> <scope>provided</scope>
> <exclusions>
> <exclusion>
> <groupId>antlr</groupId>
> <artifactId>antlr</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
> {code}
> Expected way to build dependency list:
> {code}
> File[] dependencyFiles = Maven.resolver().loadPomFromFile("pom.xml")
> .importRuntimeAndTestDependencies()
> .resolve().withTransitivity().asFile();
> {code}
> However, this results in antlr still being added to the dependency list and the resulting WebArchive.
> My temporary workaround is to explicitly exclude the G:A:
> {code}
> File[] dependencyFiles = Maven.resolver().loadPomFromFile("pom.xml")
> .importRuntimeAndTestDependencies()
> .resolve()
> .using( new RejectDependenciesStrategy(false, "org.antlr:antlr", "antlr:antlr") )
> .withTransitivity().asFile();
> {code}
> Also note that the false is required in the RejectDependenciesStrategy. Without it, all (yes, all) transitive dependencies are ignored. This may be a separate issue but I want to mention it for anyone attempting this workaround.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (SHRINKWRAP-466) Maven dependency resolution ignores transitive exclusions
by Ken H (JIRA)
Ken H created SHRINKWRAP-466:
--------------------------------
Summary: Maven dependency resolution ignores transitive exclusions
Key: SHRINKWRAP-466
URL: https://issues.jboss.org/browse/SHRINKWRAP-466
Project: ShrinkWrap
Issue Type: Bug
Reporter: Ken H
In certain circumstances, it seems that the Maven resolver is ignoring transitive exclusions.
Relevant pom.xml:
{code}
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-core</artifactId>
<version>${drools.version}</version>
</dependency>
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-compiler</artifactId>
<version>${drools.version}</version>
<exclusions>
<exclusion>
<groupId>org.antlr</groupId>
<artifactId>antlr</artifactId>
</exclusion>
<exclusion>
<groupId>org.antlr</groupId>
<artifactId>antlr-runtime</artifactId>
</exclusion>
<exclusion>
<groupId>antlr</groupId>
<artifactId>antlr</artifactId>
</exclusion>
<exclusion>
<groupId>antlr</groupId>
<artifactId>antlr-runtime</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>4.0.1.Final</version>
<scope>provided</scope>
<exclusions>
<exclusion>
<groupId>antlr</groupId>
<artifactId>antlr</artifactId>
</exclusion>
</exclusions>
</dependency>
{code}
Expected way to build dependency list:
{code}
File[] dependencyFiles = Maven.resolver().loadPomFromFile("pom.xml")
.importRuntimeAndTestDependencies()
.resolve().withTransitivity().asFile();
{code}
However, this results in antlr still being added to the dependency list and the resulting WebArchive.
My temporary workaround is to explicitly exclude the G:A:
{code}
File[] dependencyFiles = Maven.resolver().loadPomFromFile("pom.xml")
.importRuntimeAndTestDependencies()
.resolve()
.using( new RejectDependenciesStrategy(false, "org.antlr:antlr", "antlr:antlr") )
.withTransitivity().asFile();
{code}
Also note that the false is required in the RejectDependenciesStrategy. Without it, all (yes, all) transitive dependencies are ignored. This may be a separate issue but I want to mention it for anyone attempting this workaround.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months