June 2014 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] (SHRINKRES-186) MavenResolverSystemBase deprecates offline() but JavaDoc refer to wrong new usage

by Aslak Knutsen (JIRA)

Aslak Knutsen created SHRINKRES-186: --------------------------------------- Summary: MavenResolverSystemBase deprecates offline() but JavaDoc refer to wrong new usage Key: SHRINKRES-186 URL: https://issues.jboss.org/browse/SHRINKRES-186 Project: ShrinkWrap Resolvers Issue Type: Bug Security Level: Public (Everyone can see) Components: api-maven Affects Versions: 2.1.1 Reporter: Aslak Knutsen MavenResolverSystemBase deprecates the methods offline() and offline(boolean), but the JavaDoc suggests the new way to set this flag is via ConfigurableMavenResolverSystem#workOffline(). The link is correct, but the suggest path seems off; Maven.resolver().workOffline() Maven.resolver() will return a MavenResolverSystem, while Maven.configureResolver() returns the ConfigurableMavenResolverSystem which has the new methods.. Either the JavaDoc needs update, or the Maven.resolver() methods needs to return the new interface? -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-185) Add support for the canonical form "G:A:P"

by Samuel Santos (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-185?page=com.atlassian.jira.plu... ] Samuel Santos commented on SHRINKRES-185: ----------------------------------------- Yes, '?' solves it. I've already rejected the issue. Thanks! > Add support for the canonical form "G:A:P" > ------------------------------------------ > > Key: SHRINKRES-185 > URL: https://issues.jboss.org/browse/SHRINKRES-185 > Project: ShrinkWrap Resolvers > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: api-maven > Affects Versions: 2.1.1 > Reporter: Samuel Santos > Labels: resolver, shrinkwrap > > Currently, resolving a dependency with a specific packaging type, requires a version to be specified: > {code:java} > Maven.resolver().loadPomFromFile("pom.xml").resolve("G:A:ejb:V").withoutTransitivity().asSingle(JavaArchive.class); > {code} > The version should be optional and the canonical form "G:A\:P" should be valid/allowed. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-185) Add support for the canonical form "G:A:P"

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-185?page=com.atlassian.jira.plu... ] Karel Piwko commented on SHRINKRES-185: --------------------------------------- Samuel, would not '?' syntax help here? Given version and packaging has no restriction, it is quite complicated to tell those two parts of coordinates apart. https://github.com/shrinkwrap/resolver#resolution-of-artifacts-defined-in... > Add support for the canonical form "G:A:P" > ------------------------------------------ > > Key: SHRINKRES-185 > URL: https://issues.jboss.org/browse/SHRINKRES-185 > Project: ShrinkWrap Resolvers > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: api-maven > Affects Versions: 2.1.1 > Reporter: Samuel Santos > Labels: resolver, shrinkwrap > > Currently, resolving a dependency with a specific packaging type, requires a version to be specified: > {code:java} > Maven.resolver().loadPomFromFile("pom.xml").resolve("G:A:ejb:V").withoutTransitivity().asSingle(JavaArchive.class); > {code} > The version should be optional and the canonical form "G:A\:P" should be valid/allowed. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-185) Add support for the canonical form "G:A:P"

by Samuel Santos (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-185?page=com.atlassian.jira.plu... ] Samuel Santos resolved SHRINKRES-185. ------------------------------------- Resolution: Rejected Please ignore this issue. We can use the alternative syntax with question mark {{?}}, such as {{G:A\:P:?}} to fix this. > Add support for the canonical form "G:A:P" > ------------------------------------------ > > Key: SHRINKRES-185 > URL: https://issues.jboss.org/browse/SHRINKRES-185 > Project: ShrinkWrap Resolvers > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: api-maven > Affects Versions: 2.1.1 > Reporter: Samuel Santos > Labels: resolver, shrinkwrap > > Currently, resolving a dependency with a specific packaging type, requires a version to be specified: > {code:java} > Maven.resolver().loadPomFromFile("pom.xml").resolve("G:A:ejb:V").withoutTransitivity().asSingle(JavaArchive.class); > {code} > The version should be optional and the canonical form "G:A\:P" should be valid/allowed. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-185) Add support for the canonical form "G:A:P"

by Samuel Santos (JIRA)

Samuel Santos created SHRINKRES-185: --------------------------------------- Summary: Add support for the canonical form "G:A:P" Key: SHRINKRES-185 URL: https://issues.jboss.org/browse/SHRINKRES-185 Project: ShrinkWrap Resolvers Issue Type: Enhancement Security Level: Public (Everyone can see) Components: api-maven Affects Versions: 2.1.1 Reporter: Samuel Santos Currently, resolving a dependency with a specific packaging type, requires a version to be specified: {code:java} Maven.resolver().loadPomFromFile("pom.xml").resolve("G:A:ejb:V").withoutTransitivity().asSingle(JavaArchive.class); {code} The version should be optional and the canonical form "G:A\:P" should be valid/allowed. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

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

by Aslak Knutsen (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-184?page=com.atlassian.jira.plu... ] Aslak Knutsen moved ARQ-1798 to SHRINKRES-184: ---------------------------------------------- Project: ShrinkWrap Resolvers (was: Arquillian) Key: SHRINKRES-184 (was: ARQ-1798) Issue Type: Bug (was: Feature Request) Affects Version/s: (was: 1.1.4.Final) Assignee: (was: Davide D'Alto) Component/s: (was: Maven Plugin) > 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 > Security Level: Public(Everyone can see) > Environment: Maven 3.2.1 > Java 7 64 - bit > Windows 7 64 bit > Reporter: Sueleyman Vurucu > > 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.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-183) Resolvers.configure(Class, ClassLoader) ignores ClassLoader?

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-183?page=com.atlassian.jira.plu... ] Karel Piwko resolved SHRINKRES-183. ----------------------------------- Fix Version/s: 2.2.0-alpha-3 Resolution: Done Nice catch Thomas! Fix pushed upstream in https://github.com/shrinkwrap/resolver/commit/f28418141df3ecc22dcd1051ed8... > Resolvers.configure(Class,ClassLoader) ignores ClassLoader? > ----------------------------------------------------------- > > Key: SHRINKRES-183 > URL: https://issues.jboss.org/browse/SHRINKRES-183 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: api > Affects Versions: 2.1.0, 2.2.0-alpha-2, 2.1.1 > Reporter: Thomas Maslen > Assignee: Karel Piwko > Fix For: 2.2.0-alpha-3 > > > [No, I wasn't trying to use this, I just noticed it while looking at the source. It looks to me like a regression, but you gents would be better judges of that than I am] > The Resolvers.configure(Class,ClassLoader) method ignores its ClassLoader argument; the only argument that it passes to ResolverSystemFactory.createFromUserView() is the Class. > Offhand it looks like a cut-and-paste from the method above? > If I'm reading Git right this was introduced in the fix for SHRINKRES-173 that went into 2.1.0, and it's present in 2.1.0 and above, including the current master. > Happily, Resolvers.use(Class,ClassLoader) passes both arguments to ResolverSystemFactory as expected. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-155) Missing methods in generated common parents

by Ralf Battenfeld (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-155?page=com.atlassian.jira.pl... ] Ralf Battenfeld commented on SHRINKDESC-155: -------------------------------------------- I don't know what here the problems is but my latest version provides all of your mentioned fields: Example: PersistencePersistenceUnitCommType /** * Sets the <code>Name</code> attribute * @param Name the value for the attribute <code>Name</code> * @return the current instance of <code>ORIGIN</code> */ public ORIGIN name(String Name); /** * Returns the <code>Name</code> attribute * @return the value defined for the attribute <code>Name</code> */ public String getName(); /** * Removes the <code>Name</code> attribute * @return the current instance of <code>ORIGIN</code> */ public ORIGIN removeName(); /** * Sets the <code>Value</code> attribute * @param Value the value for the attribute <code>Value</code> * @return the current instance of <code>ORIGIN</code> */ public ORIGIN value(String Value); /** * Returns the <code>Value</code> attribute * @return the value defined for the attribute <code>Value</code> */ public String getValue(); /** * Removes the <code>Value</code> attribute * @return the current instance of <code>ORIGIN</code> */ public ORIGIN removeValue(); > Missing methods in generated common parents > ------------------------------------------- > > Key: SHRINKDESC-155 > URL: https://issues.jboss.org/browse/SHRINKDESC-155 > Project: ShrinkWrap Descriptors > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: api-javaee > Affects Versions: 2.0.0-alpha-6 > Reporter: George Gastaldi > Assignee: Ralf Battenfeld > > Some common parents generated from SHRINKDESC-151 do not have all the required methods declared in the common interface. > For example: > - JavaeeServletMappingCommonType > -- see https://github.com/forge/javaee-descriptors/blob/master/api/src/main/java... > - WebAppCommonDescriptor > -- see https://github.com/forge/javaee-descriptors/blob/master/api/src/main/java... > Other parent interfaces might be missing methods as well, they should be reviewed and have the common methods created. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-183) Resolvers.configure(Class, ClassLoader) ignores ClassLoader?

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-183?page=com.atlassian.jira.plu... ] Karel Piwko updated SHRINKRES-183: ---------------------------------- Affects Version/s: 2.1.1 2.2.0-alpha-2 > Resolvers.configure(Class,ClassLoader) ignores ClassLoader? > ----------------------------------------------------------- > > Key: SHRINKRES-183 > URL: https://issues.jboss.org/browse/SHRINKRES-183 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: api > Affects Versions: 2.1.0, 2.2.0-alpha-2, 2.1.1 > Reporter: Thomas Maslen > Assignee: Karel Piwko > > [No, I wasn't trying to use this, I just noticed it while looking at the source. It looks to me like a regression, but you gents would be better judges of that than I am] > The Resolvers.configure(Class,ClassLoader) method ignores its ClassLoader argument; the only argument that it passes to ResolverSystemFactory.createFromUserView() is the Class. > Offhand it looks like a cut-and-paste from the method above? > If I'm reading Git right this was introduced in the fix for SHRINKRES-173 that went into 2.1.0, and it's present in 2.1.0 and above, including the current master. > Happily, Resolvers.use(Class,ClassLoader) passes both arguments to ResolverSystemFactory as expected. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-183) Resolvers.configure(Class, ClassLoader) ignores ClassLoader?

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-183?page=com.atlassian.jira.plu... ] Karel Piwko reassigned SHRINKRES-183: ------------------------------------- Assignee: Karel Piwko (was: Andrew Rubinger) > Resolvers.configure(Class,ClassLoader) ignores ClassLoader? > ----------------------------------------------------------- > > Key: SHRINKRES-183 > URL: https://issues.jboss.org/browse/SHRINKRES-183 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: api > Affects Versions: 2.1.0 > Reporter: Thomas Maslen > Assignee: Karel Piwko > > [No, I wasn't trying to use this, I just noticed it while looking at the source. It looks to me like a regression, but you gents would be better judges of that than I am] > The Resolvers.configure(Class,ClassLoader) method ignores its ClassLoader argument; the only argument that it passes to ResolverSystemFactory.createFromUserView() is the Class. > Offhand it looks like a cut-and-paste from the method above? > If I'm reading Git right this was introduced in the fix for SHRINKRES-173 that went into 2.1.0, and it's present in 2.1.0 and above, including the current master. > Happily, Resolvers.use(Class,ClassLoader) passes both arguments to ResolverSystemFactory as expected. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 9 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 June 2014