August 2015 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] (SHRINKRES-184) Shrinkwrap maven local repo resolution not working since ARQ 1.1.4.Final

by Matous Jobanek (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-184?page=com.atlassian.jira.plu... ] Matous Jobanek updated SHRINKRES-184: ------------------------------------- Fix Version/s: 3.0.0 (was: 2.2.0-beta-3) > Shrinkwrap maven local repo resolution not working since ARQ 1.1.4.Final > ------------------------------------------------------------------------ > > Key: SHRINKRES-184 > URL: https://issues.jboss.org/browse/SHRINKRES-184 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Environment: Maven 3.2.1 > Java 7 64 - bit > Windows 7 64 bit > Reporter: Sueleyman Vurucu > Fix For: 3.0.0 > > > I update ARQ from 1.1.3.Final to 1.1.4.Final. > After I try to excecute my testsuite I had a Exception that some of the artifacts could not be resolved. After Debugging I see that shrinkwrap looks for that artifacts on our local nexus server. Unfortunately we dont deploy our development artifact on nexus. > The MavenResolverSystem is configured like shown below: > // ARQ 1.1.3.Final > private static MavenResolverSystem getMavenDependencyResolver() { > MavenResolverSystem mavenResolverSystem = Maven.configureResolver().fromFile(pathToSettingsXML); > mavenResolverSystem.offline(); > return mavenResolverSystem; > } > // ARQ 1.1.4.Final > private static ConfigurableMavenResolverSystem getMavenDependencyResolver() { > ConfigurableMavenResolverSystem mavenResolverSystem = Resolvers.configure(ConfigurableMavenResolverSystem.class); > mavenResolverSystem.withClassPathResolution(true); > mavenResolverSystem.fromFile(pathToSettingsXML); > mavenResolverSystem.workOffline(); > return mavenResolverSystem; > } > As you can see I say to MavenResolverSystem that it should work offline. > After deep debugging I see that the resolversystem try to find all the artifacts on our nexus. > //ARQ 1.1.3.Final > DefaultRepositorySystem:367 > com.siemag.base:wms-base-controller:ejb:3.0.0-SNAPSHOT <(compile) > //ARQ 1.1.4.Final > In the class DefaultRepositorySystem:367 > com.siemag.base:wms-base-controller:ejb:3.0.0-SNAPSHOT < [nexus (http://172.16.55.1:8081/nexus/content/groups/public, releases)] -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-180) transitive dependencies updated from provided to compile

by Matous Jobanek (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-180?page=com.atlassian.jira.plu... ] Matous Jobanek updated SHRINKRES-180: ------------------------------------- Fix Version/s: 3.0.0 (was: 2.2.0-beta-3) > transitive dependencies updated from provided to compile > -------------------------------------------------------- > > Key: SHRINKRES-180 > URL: https://issues.jboss.org/browse/SHRINKRES-180 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Affects Versions: 2.2.0-alpha-2 > Reporter: Markus Schulz > Fix For: 3.0.0 > > Attachments: deptree.txt, MavenResolverTest.java, transitivetest-pom.xml > > > i have a pom with something like: > <dependency> > <groupId>org.hibernate</groupId> > <artifactId>hibernate-search</artifactId> > <version>4.2.0.Final</version> > </dependency> > <dependency> > <groupId>org.hibernate</groupId> > <artifactId>hibernate-core</artifactId> > <scope>provided</scope> > </dependency> > hibernate-search internally dependes on hibernate-core (scope compile). But in don't want to get hbernate-core in my deployment, therefore it's forced to provided. > But: > File[] testLibs = Maven.configureResolver() > .workOffline() > .loadPomFromClassLoaderResource("transitivetest-pom.xml") > .importRuntimeDependencies() > .resolve() > .withTransitivity() > .asFile(); > still contains hibernate-core.jar -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-192) embedded gradle shrinkwrap-resolver - propagate project properties via API

by Matous Jobanek (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-192?page=com.atlassian.jira.plu... ] Matous Jobanek commented on SHRINKRES-192: ------------------------------------------ Hi [~mmatloka], is there any progress regarding to this issue > embedded gradle shrinkwrap-resolver - propagate project properties via API > -------------------------------------------------------------------------- > > Key: SHRINKRES-192 > URL: https://issues.jboss.org/browse/SHRINKRES-192 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Environment: gradle 1.12, jdk 1.7_u45, fedora, org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-impl-gradle-embedded-archive:2.2.0-alpha-1 > Reporter: Peter Butkovic > Assignee: Michal Matloka > Labels: gradle > > I'd like to propagate project properties to embedded gradle build. > I tried following: > {code} > ShrinkWrap.create(EmbeddedGradleImporter.class) > .forThisProjectDirectory().forTasks("build").withArguments("-x", "test", "-Psomepropname=somepropvalue") > .importBuildOutput().as(WebArchive.class) > {code} > but the {{somepropname}} is not set in embedded build. > Using the gradle.properties is not an option for me, as {{somepropname}} value changes from build to build. > Workaround was to write temp properties file and read it in embedded build with silent failure (as suggested here: http://issues.gradle.org/browse/GRADLE-1419?focusedCommentId=16245&page=c...) but that sounds too much work to do for such a simple task. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-163) Implements importTestBuildOutput for type JAR

by Matous Jobanek (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-163?page=com.atlassian.jira.plu... ] Matous Jobanek updated SHRINKRES-163: ------------------------------------- Fix Version/s: 3.1.0 > Implements importTestBuildOutput for type JAR > --------------------------------------------- > > Key: SHRINKRES-163 > URL: https://issues.jboss.org/browse/SHRINKRES-163 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Components: maven > Affects Versions: 2.0.2 > Reporter: Karel Piwko > Fix For: 3.1.0 > > > While default use case - merging src/main and src/test together might not be seen as useful, there is at least an option that user will be willing to import src/test only. > That said, implementing importTestBuildOutput() for a archive of type jar is a valid operation. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-150) Wrong built WebArchive using Shrinkwrap Classpath resolution

by Matous Jobanek (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-150?page=com.atlassian.jira.plu... ] Matous Jobanek updated SHRINKRES-150: ------------------------------------- Fix Version/s: 3.0.0 > Wrong built WebArchive using Shrinkwrap Classpath resolution > ------------------------------------------------------------ > > Key: SHRINKRES-150 > URL: https://issues.jboss.org/browse/SHRINKRES-150 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Affects Versions: 2.0.0 > Environment: win 7 (64 bit), glassfish 3.1.2 > Reporter: Gunther Klein > Fix For: 3.0.0 > > > Hi, > 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: > {code:borderStyle=solid} > @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 > } > } > {code} > 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: > {code:xml} > <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> >  > <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> >  > <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> > {code} > 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 was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-152) Maven dependency resolution ignores transitive exclusions

by Matous Jobanek (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-152?page=com.atlassian.jira.plu... ] Matous Jobanek closed SHRINKRES-152. ------------------------------------ Resolution: Cannot Reproduce Bug Cannot reproduce bug, feel free to reopen this issue if it is still valid > Maven dependency resolution ignores transitive exclusions > --------------------------------------------------------- > > Key: SHRINKRES-152 > URL: https://issues.jboss.org/browse/SHRINKRES-152 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Affects Versions: 2.0.0 > 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 was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-149) Maven classpathworkspace resolver shouldn't assume classes are under target/classes

by Matous Jobanek (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-149?page=com.atlassian.jira.plu... ] Matous Jobanek updated SHRINKRES-149: ------------------------------------- Fix Version/s: 3.1.0 > Maven classpathworkspace resolver shouldn't assume classes are under target/classes > ----------------------------------------------------------------------------------- > > Key: SHRINKRES-149 > URL: https://issues.jboss.org/browse/SHRINKRES-149 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Affects Versions: 2.0.0 > Reporter: Matthieu Baechler > Fix For: 3.1.0 > > > To avoid conflicting builds between Maven and Eclipse, I put eclipse build into a "eclipse-build/classes" directory. > Considering this configuration, with the following code : > {code:java} > Maven.resolver() > .offline() > .loadPomFromFile("../../pom.xml") > .resolve("com.linagora.obm:services-module:2.6.0-SNAPSHOT") > .withClassPathResolution(true) > .withTransitivity() > .asFile(); > {code} > Maven resolver find my services-module on the classpath, but when trying a build a jar, it fails in MavenResolvedArtifactImpl.artifactToFile : > {code:java} > // SHRINKRES-102, allow test classes to be packaged as well > File root = new File(artifact.getFile().getParentFile(), "target/classes"); > {code} > In my case, target/classes contains maven build result and not what's on the classpath. > Can this resolver use the classes on the classpath instead ? -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-132) MavenImport should have different name

by Matous Jobanek (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-132?page=com.atlassian.jira.plu... ] Matous Jobanek updated SHRINKRES-132: ------------------------------------- Fix Version/s: 3.0.0 > MavenImport should have different name > -------------------------------------- > > Key: SHRINKRES-132 > URL: https://issues.jboss.org/browse/SHRINKRES-132 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: maven > Affects Versions: 2.0.0 > Reporter: Karel Piwko > Assignee: Michal Matloka > Priority: Minor > Fix For: 3.0.0 > > > MavenImporter is now able to build the project from pom.xml. This means that MavenImporter name is no longer valid, as it does not promote the fact that project will be build from scratch. > It might be MavenBuilder instead. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-131) Align property name in between Maven Plugin and rest of ShrinkRes

by Matous Jobanek (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-131?page=com.atlassian.jira.plu... ] Matous Jobanek updated SHRINKRES-131: ------------------------------------- Fix Version/s: 3.0.0 > Align property name in between Maven Plugin and rest of ShrinkRes > ----------------------------------------------------------------- > > Key: SHRINKRES-131 > URL: https://issues.jboss.org/browse/SHRINKRES-131 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: maven-plugin > Reporter: Karel Piwko > Priority: Minor > Fix For: 3.0.0 > > > Maven plugin should be using the same property names as the rest of the ShrinkWrap Maven Resolver. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-128) Improve JavaDocs of methods taking coordinate in canonical form

by Matous Jobanek (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-128?page=com.atlassian.jira.plu... ] Matous Jobanek updated SHRINKRES-128: ------------------------------------- Fix Version/s: 3.0.0 (was: 2.2.0-beta-3) > Improve JavaDocs of methods taking coordinate in canonical form > --------------------------------------------------------------- > > Key: SHRINKRES-128 > URL: https://issues.jboss.org/browse/SHRINKRES-128 > Project: ShrinkWrap Resolvers > Issue Type: Enhancement > Reporter: Michal Matloka > Priority: Minor > Fix For: 3.0.0 > > > Descriptions in exception and internal classes was improved in SHRINKRES-113. It appears that some API methods JavaDocs still needs improvements. See last post in forum reference. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues August 2015