January 2013 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] (SHRINKRES-81) Poor encapsulation, passing around Aether (Artifact) objects when we should be using our own

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-81?page=com.atlassian.jira.plug... ] Michal Matloka updated SHRINKRES-81: ------------------------------------ Assignee: Karel Piwko (was: Michal Matloka) > Poor encapsulation, passing around Aether (Artifact) objects when we should be using our own > -------------------------------------------------------------------------------------------- > > Key: SHRINKRES-81 > URL: https://issues.jboss.org/browse/SHRINKRES-81 > Project: ShrinkWrap Resolvers > Issue Type: Task > Components: api-maven, impl-maven > Reporter: Michal Matloka > Assignee: Karel Piwko > Fix For: 2.0.0-alpha-7 > > > TODO located in MavenStrategyBaseImpl > // TODO Poor encapsulation, passing around Aether (Artifact) objects when we should be using our own > // representation > and > MavenWorkingSession > // TODO We're not really encapsulating much here, as we expose out Aether and Maven classes. Refactor this class and > // usages to hide all implementation details of Maven and Aether *behind* this SPI facade > Some of this refactors has to be made for SHRINKRES-27 -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-61) Reimplement MavenImporter

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-61?page=com.atlassian.jira.plug... ] Karel Piwko resolved SHRINKRES-61. ---------------------------------- Fix Version/s: 2.0.0-alpha-7 Resolution: Done Pushed upstream in https://github.com/shrinkwrap/resolver/commit/d0bd2cc89835075dd82d58c3ed5... > Reimplement MavenImporter > ------------------------- > > Key: SHRINKRES-61 > URL: https://issues.jboss.org/browse/SHRINKRES-61 > Project: ShrinkWrap Resolvers > Issue Type: Task > Components: api-maven > Affects Versions: 2.0.0-alpha-1 > Reporter: Karel Piwko > Assignee: Karel Piwko > Fix For: 2.0.0-alpha-7 > > > Current MavenImporter implementation have many usability concerns. > Spawn a discussion about MavenImporter use cases and reimplement it in order to be independent of previous Maven execution. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-81) Poor encapsulation, passing around Aether (Artifact) objects when we should be using our own

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-81?page=com.atlassian.jira.plug... ] Karel Piwko resolved SHRINKRES-81. ---------------------------------- Fix Version/s: 2.0.0-alpha-7 Resolution: Done Fixed in https://github.com/shrinkwrap/resolver/commit/d0bd2cc89835075dd82d58c3ed5... > Poor encapsulation, passing around Aether (Artifact) objects when we should be using our own > -------------------------------------------------------------------------------------------- > > Key: SHRINKRES-81 > URL: https://issues.jboss.org/browse/SHRINKRES-81 > Project: ShrinkWrap Resolvers > Issue Type: Task > Components: api-maven, impl-maven > Reporter: Michal Matloka > Assignee: Michal Matloka > Fix For: 2.0.0-alpha-7 > > > TODO located in MavenStrategyBaseImpl > // TODO Poor encapsulation, passing around Aether (Artifact) objects when we should be using our own > // representation > and > MavenWorkingSession > // TODO We're not really encapsulating much here, as we expose out Aether and Maven classes. Refactor this class and > // usages to hide all implementation details of Maven and Aether *behind* this SPI facade > Some of this refactors has to be made for SHRINKRES-27 -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-104) Programmatic offline set can be overriden unexpectedly

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-104?page=com.atlassian.jira.plu... ] Karel Piwko resolved SHRINKRES-104. ----------------------------------- Assignee: Karel Piwko (was: Andrew Rubinger) Resolution: Done Pushed upstream in https://github.com/shrinkwrap/resolver/commit/2ceb3c3c7f9a9c07e3e5ba99505... > Programmatic offline set can be overriden unexpectedly > ------------------------------------------------------ > > Key: SHRINKRES-104 > URL: https://issues.jboss.org/browse/SHRINKRES-104 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: impl-maven > Affects Versions: 2.0.0-alpha-6 > Reporter: Karel Piwko > Assignee: Karel Piwko > Fix For: 2.0.0-alpha-7 > > > There are some use cases where offline() flag settings is ignored, for instance when user calls offline() and than loads a settings.xml or if he loads pom.xml that contains <repository>ies. > Basically every call that regenerates Maven working session might lead to missing programmatic settings in some circumstances. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-104) Programmatic offline set can be overriden unexpectedly

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-104?page=com.atlassian.jira.plu... ] Karel Piwko updated SHRINKRES-104: ---------------------------------- Summary: Programmatic offline set can be overriden unexpectedly (was: Programmatic offline set can be overriden) > Programmatic offline set can be overriden unexpectedly > ------------------------------------------------------ > > Key: SHRINKRES-104 > URL: https://issues.jboss.org/browse/SHRINKRES-104 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: impl-maven > Affects Versions: 2.0.0-alpha-6 > Reporter: Karel Piwko > Assignee: Andrew Rubinger > Fix For: 2.0.0-alpha-7 > > > There are some use cases where offline() flag settings is ignored, for instance when user calls offline() and than loads a settings.xml or if he loads pom.xml that contains <repository>ies. > Basically every call that regenerates Maven working session might lead to missing programmatic settings in some circumstances. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-104) Programmatic offline set can be overriden

by Karel Piwko (JIRA)

Karel Piwko created SHRINKRES-104: ------------------------------------- Summary: Programmatic offline set can be overriden Key: SHRINKRES-104 URL: https://issues.jboss.org/browse/SHRINKRES-104 Project: ShrinkWrap Resolvers Issue Type: Feature Request Components: impl-maven Affects Versions: 2.0.0-alpha-6 Reporter: Karel Piwko Assignee: Andrew Rubinger Fix For: 2.0.0-alpha-7 There are some use cases where offline() flag settings is ignored, for instance when user calls offline() and than loads a settings.xml or if he loads pom.xml that contains <repository>ies. Basically every call that regenerates Maven working session might lead to missing programmatic settings in some circumstances. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-102) Maven resolver unable to resolve test-jar dependency

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-102?page=com.atlassian.jira.plu... ] Karel Piwko edited comment on SHRINKRES-102 at 1/13/13 4:59 AM: ---------------------------------------------------------------- Hi Jay, I wrote a few tests and figured out that it is working correctly for dependencies available in a remote repository. I added possibility to resolve these artifacts directly from workspace (classpath). was (Author: kpiwko): Hi Jay, I wrote a few tests and figured out that it is working correctly for dependencies not resolved from reactor, but available in a remote repository. So I added possibility to resolve these artifacts directly from workspace (classpath). > Maven resolver unable to resolve test-jar dependency > ---------------------------------------------------- > > Key: SHRINKRES-102 > URL: https://issues.jboss.org/browse/SHRINKRES-102 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Affects Versions: 2.0.0-alpha-6 > Environment: Win7, Maven 3.0.4, Java7 > Reporter: jay shaughnessy > Assignee: Karel Piwko > > A possible regression as similar code, using the old API, worked for me with Shrinkwrap-1. > Example: given the following dependency in the local pom.xml: > <dependencies> > ... > <dependency> > <groupId>${project.groupId}</groupId> > <artifactId>rhq-core-client-api</artifactId> > <version>${project.version}</version> > <type>test-jar</type> > <scope>test</scope> > </dependency> > ... > </dependencies> > And the following SW-2 code: > MavenResolverSystem resolver = Maven.resolver(); > resolver.loadPomFromFile("pom.xml").resolve("org.rhq:rhq-core-client-api:jar:tests:4.6.0-SNAPSHOT).withTransitivity().as(JavaArchive.class) > I don't get an exception but the retuened Archive is the production jar: > rhq-core-client-api-4.6.0-SNAPSHOT.jar > As opposed to the expected test jar: > rhq-core-client-api-4.6.0-SNAPSHOT-tests.jar > The test jar is generated by us in that module's pom, using the maven-jar plugin with phase=package and goal=test-jar, which I believe is the standard mechanism. And both of the jars are available in my M2 repo in the same place (.m2/repository/org/rhq/rhq-core-client-api/4.6.0-SNAPSHOT). > At the moment I have not been able to find a 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-102) Maven resolver unable to resolve test-jar dependency

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-102?page=com.atlassian.jira.plu... ] Karel Piwko resolved SHRINKRES-102. ----------------------------------- Resolution: Done Pushed upstream in https://github.com/shrinkwrap/resolver/commit/c99cd0fe5a0794b1dcc550221d5... If you are interested how it is tested, have a look here: https://github.com/shrinkwrap/resolver/blob/master/impl-maven/src/test/ja... and for classpath resolution here: https://github.com/shrinkwrap/resolver/blob/master/impl-maven/src/test/ja... > Maven resolver unable to resolve test-jar dependency > ---------------------------------------------------- > > Key: SHRINKRES-102 > URL: https://issues.jboss.org/browse/SHRINKRES-102 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Affects Versions: 2.0.0-alpha-6 > Environment: Win7, Maven 3.0.4, Java7 > Reporter: jay shaughnessy > Assignee: Karel Piwko > > A possible regression as similar code, using the old API, worked for me with Shrinkwrap-1. > Example: given the following dependency in the local pom.xml: > <dependencies> > ... > <dependency> > <groupId>${project.groupId}</groupId> > <artifactId>rhq-core-client-api</artifactId> > <version>${project.version}</version> > <type>test-jar</type> > <scope>test</scope> > </dependency> > ... > </dependencies> > And the following SW-2 code: > MavenResolverSystem resolver = Maven.resolver(); > resolver.loadPomFromFile("pom.xml").resolve("org.rhq:rhq-core-client-api:jar:tests:4.6.0-SNAPSHOT).withTransitivity().as(JavaArchive.class) > I don't get an exception but the retuened Archive is the production jar: > rhq-core-client-api-4.6.0-SNAPSHOT.jar > As opposed to the expected test jar: > rhq-core-client-api-4.6.0-SNAPSHOT-tests.jar > The test jar is generated by us in that module's pom, using the maven-jar plugin with phase=package and goal=test-jar, which I believe is the standard mechanism. And both of the jars are available in my M2 repo in the same place (.m2/repository/org/rhq/rhq-core-client-api/4.6.0-SNAPSHOT). > At the moment I have not been able to find a 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-102) Maven resolver unable to resolve test-jar dependency

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-102?page=com.atlassian.jira.plu... ] Karel Piwko commented on SHRINKRES-102: --------------------------------------- Hi Jay, I wrote a few tests and figured out that it is working correctly for dependencies not resolved from reactor, but available in a remote repository. So I added possibility to resolve these artifacts directly from workspace (classpath). > Maven resolver unable to resolve test-jar dependency > ---------------------------------------------------- > > Key: SHRINKRES-102 > URL: https://issues.jboss.org/browse/SHRINKRES-102 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Affects Versions: 2.0.0-alpha-6 > Environment: Win7, Maven 3.0.4, Java7 > Reporter: jay shaughnessy > Assignee: Karel Piwko > > A possible regression as similar code, using the old API, worked for me with Shrinkwrap-1. > Example: given the following dependency in the local pom.xml: > <dependencies> > ... > <dependency> > <groupId>${project.groupId}</groupId> > <artifactId>rhq-core-client-api</artifactId> > <version>${project.version}</version> > <type>test-jar</type> > <scope>test</scope> > </dependency> > ... > </dependencies> > And the following SW-2 code: > MavenResolverSystem resolver = Maven.resolver(); > resolver.loadPomFromFile("pom.xml").resolve("org.rhq:rhq-core-client-api:jar:tests:4.6.0-SNAPSHOT).withTransitivity().as(JavaArchive.class) > I don't get an exception but the retuened Archive is the production jar: > rhq-core-client-api-4.6.0-SNAPSHOT.jar > As opposed to the expected test jar: > rhq-core-client-api-4.6.0-SNAPSHOT-tests.jar > The test jar is generated by us in that module's pom, using the maven-jar plugin with phase=package and goal=test-jar, which I believe is the standard mechanism. And both of the jars are available in my M2 repo in the same place (.m2/repository/org/rhq/rhq-core-client-api/4.6.0-SNAPSHOT). > At the moment I have not been able to find a 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-103) Maven resolver unable to resolve dependencies with explicit version

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-103?page=com.atlassian.jira.plu... ] Karel Piwko updated SHRINKRES-103: ---------------------------------- Priority: Critical (was: Major) > Maven resolver unable to resolve dependencies with explicit version > ------------------------------------------------------------------- > > Key: SHRINKRES-103 > URL: https://issues.jboss.org/browse/SHRINKRES-103 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Components: impl-maven > Affects Versions: 2.0.0-alpha-6 > Environment: Win7, Maven 3.0.4, Java7 > Reporter: jay shaughnessy > Assignee: Karel Piwko > Priority: Critical > Fix For: 2.0.0-alpha-7 > > > Actual version: 2.0.0-alpha-6 (not in the version drop down) > A possible regression as similar code, using the old API, worked for me with Shrinkwrap-1. > Example: given the following dependency in the local pom.xml: > <dependencies> > ... > <dependency> > <groupId>org.powermock</groupId> > <artifactId>powermock-api-mockito</artifactId> > <version>${powermock.version}</version> > <scope>test</scope> > </dependency> > ... > </dependencies> > And the following SW-2 code: > MavenResolverSystem resolver = Maven.resolver(); > resolver.loadPomFromFile("pom.xml").resolve("org.powermock:powermock-api-mockito").withTransitivity().as(JavaArchive.class) > I get the follwoing exception: > org.jboss.shrinkwrap.resolver.api.ResolutionException: Unable to get version for dependency specified by org.powermock:powermock-api-mockito, it was not provided in <dependencyManagement> section. > Again, this worked for me in SW-1. > If I do in fact create a <dependencyManagement> section in the pom, and define the version there, it works as a workaround. But it would seem that an explicit <version> element in the <dependency> should be sufficient. -- 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

13 years, 2 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 January 2013