March 2013 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] (SHRINKDESC-144) Upgrade APIViz

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-144?page=com.atlassian.jira.pl... ] Andrew Rubinger resolved SHRINKDESC-144. ---------------------------------------- Resolution: Done Upstream: https://github.com/shrinkwrap/descriptors/commit/9690c5b6c97340f5727c952f... > Upgrade APIViz > -------------- > > Key: SHRINKDESC-144 > URL: https://issues.jboss.org/browse/SHRINKDESC-144 > Project: ShrinkWrap Descriptors > Issue Type: Task > Reporter: Andrew Rubinger > Assignee: Andrew Rubinger > > Avoid error in release: > {code}[INFO] [ERROR] javadoc: error - An error occurred during diagram generation: java.lang.IllegalStateException: Failed to find an insertion point.{code} -- 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

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-144) Upgrade APIViz

by Andrew Rubinger (JIRA)

Andrew Rubinger created SHRINKDESC-144: ------------------------------------------ Summary: Upgrade APIViz Key: SHRINKDESC-144 URL: https://issues.jboss.org/browse/SHRINKDESC-144 Project: ShrinkWrap Descriptors Issue Type: Task Reporter: Andrew Rubinger Assignee: Andrew Rubinger Avoid error in release: {code}[INFO] [ERROR] javadoc: error - An error occurred during diagram generation: java.lang.IllegalStateException: Failed to find an insertion point.{code} -- 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

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-124) MetadataParser verbose flag doesn't take effect

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-124?page=com.atlassian.jira.pl... ] Jesper Pedersen commented on SHRINKDESC-124: -------------------------------------------- I got 3 other JIRAs open, but the -alpha-5 would help a lot > MetadataParser verbose flag doesn't take effect > ----------------------------------------------- > > Key: SHRINKDESC-124 > URL: https://issues.jboss.org/browse/SHRINKDESC-124 > Project: ShrinkWrap Descriptors > Issue Type: Bug > Components: metadata-parser > Affects Versions: 2.0.0-alpha-3 > Reporter: Jesper Pedersen > Assignee: Ralf Battenfeld > Fix For: 2.0.0-alpha-5 > > > Even with the 'verbose' flag set to 'false' the following is outputted: > {noformat} > compile: > [metadata-parser] Jul 3, 2012 11:05:28 AM org.jboss.shrinkwrap.descriptor.metadata.MetadataParser parse > [metadata-parser] INFO: common/src/main/resources/schema/ironjacamar_1_0.xsd > [metadata-parser] Jul 3, 2012 11:05:28 AM org.jboss.shrinkwrap.descriptor.metadata.MetadataParser parse > [metadata-parser] INFO: file:///xyz/shrinkwrap/common/src/main/resources/schema/ironjacamar_1_0.xsd > [metadata-parser] isDataType: xs:token found > [metadata-parser] isDataType: xs:nonNegativeInteger found > [metadata-parser] isDataType: xs:nonNegativeInteger found > [metadata-parser] isDataType: xs:nonNegativeInteger found > [metadata-parser] isDataType: xs:nonNegativeInteger found > [metadata-parser] isDataType: xs:nonNegativeInteger found > [metadata-parser] isDataType: xs:nonNegativeInteger found > [metadata-parser] isDataType: xs:nonNegativeInteger found > [metadata-parser] isDataType: xs:nonNegativeInteger found > [metadata-parser] isDataType: xs:token found > [metadata-parser] isDataType: xs:token found > [metadata-parser] isDataType: xs:token found > [metadata-parser] isDataType: xs:token found > [metadata-parser] isDataType: xs:token found > [metadata-parser] isDataType: xs:token found > [metadata-parser] isDataType: xs:token found > [metadata-parser] Jul 3, 2012 11:05:28 AM org.jboss.shrinkwrap.descriptor.metadata.dom.DomWriter write > [metadata-parser] INFO: Saved: /tmp/tempMetadata6961769825835560580.xml > [metadata-parser] Generating Enum: TransactionSupportType > [metadata-parser] Generating Interface: ConfigPropertyType > [metadata-parser] Generating Interface: IronjacamarType > [metadata-parser] Generating Interface: AdminObjectType > [metadata-parser] Generating Interface: TimeoutType > [metadata-parser] Generating Interface: ValidationType > [metadata-parser] Generating Interface: ConnectionDefinitionsType > [metadata-parser] Generating Interface: ConnectionDefintionType > [metadata-parser] Generating Interface: PoolType > [metadata-parser] Generating Interface: XaPoolType > [metadata-parser] Generating Interface: SecurityType > [metadata-parser] Generating Interface: AdminObjectsType > [metadata-parser] Generating Interface: BeanValidationGroupsType > [metadata-parser] Generating Interface: RecoverType > [metadata-parser] Generating Interface: ExtensionType > [metadata-parser] Generating Interface: CredentialType > [metadata-parser] Generating Descriptor Api: IronjacamarDescriptor > [metadata-parser] Generating DescriptorImpl: IronjacamarDescriptorImpl > [metadata-parser] Generating Implementation Class: ConfigPropertyTypeImpl > [metadata-parser] Generating Implementation Class: IronjacamarTypeImpl > [metadata-parser] Generating Implementation Class: AdminObjectTypeImpl > [metadata-parser] Generating Implementation Class: TimeoutTypeImpl > [metadata-parser] Generating Implementation Class: ValidationTypeImpl > [metadata-parser] Generating Implementation Class: ConnectionDefinitionsTypeImpl > [metadata-parser] Generating Implementation Class: ConnectionDefintionTypeImpl > [metadata-parser] Generating Implementation Class: PoolTypeImpl > [metadata-parser] Generating Implementation Class: XaPoolTypeImpl > [metadata-parser] Generating Implementation Class: SecurityTypeImpl > [metadata-parser] Generating Implementation Class: AdminObjectsTypeImpl > [metadata-parser] Generating Implementation Class: BeanValidationGroupsTypeImpl > [metadata-parser] Generating Implementation Class: RecoverTypeImpl > [metadata-parser] Generating Implementation Class: ExtensionTypeImpl > [metadata-parser] Generating Implementation Class: CredentialTypeImpl > [metadata-parser] Generating api package-info: /xyz/shrinkwrap/build/embedded/src/main/java/org/jboss/ironjacamar/api/package-info.java > [metadata-parser] Generating impl package-info: /xyz/shrinkwrap/build/embedded/src/main/java/org/jboss/ironjacamar/impl/package-info.java > [metadata-parser] Generating service file: /xyz/shrinkwrap/build/embedded/src/main/resources/META-INF/services/org.jboss.ironjacamar.api.IronjacamarDescriptor > {noformat} > If verbose is false only the out come of the command should be displayed -- 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

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-124) MetadataParser verbose flag doesn't take effect

by Ralf Battenfeld (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-124?page=com.atlassian.jira.pl... ] Ralf Battenfeld commented on SHRINKDESC-124: -------------------------------------------- Sorry for the late response. This question is related to Andrew. By the way, do you have additional requirements? > MetadataParser verbose flag doesn't take effect > ----------------------------------------------- > > Key: SHRINKDESC-124 > URL: https://issues.jboss.org/browse/SHRINKDESC-124 > Project: ShrinkWrap Descriptors > Issue Type: Bug > Components: metadata-parser > Affects Versions: 2.0.0-alpha-3 > Reporter: Jesper Pedersen > Assignee: Ralf Battenfeld > Fix For: 2.0.0-alpha-5 > > > Even with the 'verbose' flag set to 'false' the following is outputted: > {noformat} > compile: > [metadata-parser] Jul 3, 2012 11:05:28 AM org.jboss.shrinkwrap.descriptor.metadata.MetadataParser parse > [metadata-parser] INFO: common/src/main/resources/schema/ironjacamar_1_0.xsd > [metadata-parser] Jul 3, 2012 11:05:28 AM org.jboss.shrinkwrap.descriptor.metadata.MetadataParser parse > [metadata-parser] INFO: file:///xyz/shrinkwrap/common/src/main/resources/schema/ironjacamar_1_0.xsd > [metadata-parser] isDataType: xs:token found > [metadata-parser] isDataType: xs:nonNegativeInteger found > [metadata-parser] isDataType: xs:nonNegativeInteger found > [metadata-parser] isDataType: xs:nonNegativeInteger found > [metadata-parser] isDataType: xs:nonNegativeInteger found > [metadata-parser] isDataType: xs:nonNegativeInteger found > [metadata-parser] isDataType: xs:nonNegativeInteger found > [metadata-parser] isDataType: xs:nonNegativeInteger found > [metadata-parser] isDataType: xs:nonNegativeInteger found > [metadata-parser] isDataType: xs:token found > [metadata-parser] isDataType: xs:token found > [metadata-parser] isDataType: xs:token found > [metadata-parser] isDataType: xs:token found > [metadata-parser] isDataType: xs:token found > [metadata-parser] isDataType: xs:token found > [metadata-parser] isDataType: xs:token found > [metadata-parser] Jul 3, 2012 11:05:28 AM org.jboss.shrinkwrap.descriptor.metadata.dom.DomWriter write > [metadata-parser] INFO: Saved: /tmp/tempMetadata6961769825835560580.xml > [metadata-parser] Generating Enum: TransactionSupportType > [metadata-parser] Generating Interface: ConfigPropertyType > [metadata-parser] Generating Interface: IronjacamarType > [metadata-parser] Generating Interface: AdminObjectType > [metadata-parser] Generating Interface: TimeoutType > [metadata-parser] Generating Interface: ValidationType > [metadata-parser] Generating Interface: ConnectionDefinitionsType > [metadata-parser] Generating Interface: ConnectionDefintionType > [metadata-parser] Generating Interface: PoolType > [metadata-parser] Generating Interface: XaPoolType > [metadata-parser] Generating Interface: SecurityType > [metadata-parser] Generating Interface: AdminObjectsType > [metadata-parser] Generating Interface: BeanValidationGroupsType > [metadata-parser] Generating Interface: RecoverType > [metadata-parser] Generating Interface: ExtensionType > [metadata-parser] Generating Interface: CredentialType > [metadata-parser] Generating Descriptor Api: IronjacamarDescriptor > [metadata-parser] Generating DescriptorImpl: IronjacamarDescriptorImpl > [metadata-parser] Generating Implementation Class: ConfigPropertyTypeImpl > [metadata-parser] Generating Implementation Class: IronjacamarTypeImpl > [metadata-parser] Generating Implementation Class: AdminObjectTypeImpl > [metadata-parser] Generating Implementation Class: TimeoutTypeImpl > [metadata-parser] Generating Implementation Class: ValidationTypeImpl > [metadata-parser] Generating Implementation Class: ConnectionDefinitionsTypeImpl > [metadata-parser] Generating Implementation Class: ConnectionDefintionTypeImpl > [metadata-parser] Generating Implementation Class: PoolTypeImpl > [metadata-parser] Generating Implementation Class: XaPoolTypeImpl > [metadata-parser] Generating Implementation Class: SecurityTypeImpl > [metadata-parser] Generating Implementation Class: AdminObjectsTypeImpl > [metadata-parser] Generating Implementation Class: BeanValidationGroupsTypeImpl > [metadata-parser] Generating Implementation Class: RecoverTypeImpl > [metadata-parser] Generating Implementation Class: ExtensionTypeImpl > [metadata-parser] Generating Implementation Class: CredentialTypeImpl > [metadata-parser] Generating api package-info: /xyz/shrinkwrap/build/embedded/src/main/java/org/jboss/ironjacamar/api/package-info.java > [metadata-parser] Generating impl package-info: /xyz/shrinkwrap/build/embedded/src/main/java/org/jboss/ironjacamar/impl/package-info.java > [metadata-parser] Generating service file: /xyz/shrinkwrap/build/embedded/src/main/resources/META-INF/services/org.jboss.ironjacamar.api.IronjacamarDescriptor > {noformat} > If verbose is false only the out come of the command should be displayed -- 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

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-113) resolving of maven artifacts with classifier failed

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-113?page=com.atlassian.jira.plu... ] Andrew Rubinger updated SHRINKRES-113: -------------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 2.0.0-beta-3 Resolution: Done Upstream: https://github.com/shrinkwrap/resolver/commit/f2c49d973f629e7ca6a0bf55b27... > resolving of maven artifacts with classifier failed > --------------------------------------------------- > > Key: SHRINKRES-113 > URL: https://issues.jboss.org/browse/SHRINKRES-113 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: api-maven > Affects Versions: 2.0.0-beta-2 > Reporter: Juergen Biersack > Assignee: Michal Matloka > Fix For: 2.0.0-beta-3 > > > The following code is not working: > {code:title=ArquillianTest.java|borderStyle=solid} > @Deployment > public static EnterpriseArchive createDeployment() { > ... > JavaArchive[] ejbModule = mavenResolver > .resolve("groupId:artifactId:jar:classifier") > .withoutTransitivity() > .as(JavaArchive.class); > ... > } > {code} > The class org.jboss.shrinkwrap.resolver.api.maven.coordinate.MavenCoordinates should be able to interprete the coordinate above with the documented pattern: > *<groupId>:<artifactId>[:<packagingType>[:<classifier>]][:<version>]* > It seems, that the classifier is interpreted as version. > The following workaround is running well: > {code:title=ArquillianTest.java|borderStyle=solid} > @Deployment > public static EnterpriseArchive createDeployment() { > ... > JavaArchive[] warDependenciesClientViews = mavenResolver > .addDependency( > MavenDependencies.createDependency( > MavenCoordinates.createCoordinate( > "groupId", > "artifactId", > null, > PackagingType.JAR, > "classifier"), > null, > false)) > .resolve() > .withoutTransitivity() > .as(JavaArchive.class); > ... > } > {code} -- 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

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-113) resolving of maven artifacts with classifier failed

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-113?page=com.atlassian.jira.plu... ] Andrew Rubinger commented on SHRINKRES-113: ------------------------------------------- Agree w/ Karel and wildcard/unknown syntax. > resolving of maven artifacts with classifier failed > --------------------------------------------------- > > Key: SHRINKRES-113 > URL: https://issues.jboss.org/browse/SHRINKRES-113 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: api-maven > Affects Versions: 2.0.0-beta-2 > Reporter: Juergen Biersack > Assignee: Michal Matloka > > The following code is not working: > {code:title=ArquillianTest.java|borderStyle=solid} > @Deployment > public static EnterpriseArchive createDeployment() { > ... > JavaArchive[] ejbModule = mavenResolver > .resolve("groupId:artifactId:jar:classifier") > .withoutTransitivity() > .as(JavaArchive.class); > ... > } > {code} > The class org.jboss.shrinkwrap.resolver.api.maven.coordinate.MavenCoordinates should be able to interprete the coordinate above with the documented pattern: > *<groupId>:<artifactId>[:<packagingType>[:<classifier>]][:<version>]* > It seems, that the classifier is interpreted as version. > The following workaround is running well: > {code:title=ArquillianTest.java|borderStyle=solid} > @Deployment > public static EnterpriseArchive createDeployment() { > ... > JavaArchive[] warDependenciesClientViews = mavenResolver > .addDependency( > MavenDependencies.createDependency( > MavenCoordinates.createCoordinate( > "groupId", > "artifactId", > null, > PackagingType.JAR, > "classifier"), > null, > false)) > .resolve() > .withoutTransitivity() > .as(JavaArchive.class); > ... > } > {code} -- 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

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-445) Export of uncompressed ZIP

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-445?page=com.atlassian.jira.pl... ] Andrew Rubinger commented on SHRINKWRAP-445: -------------------------------------------- Comments on the PR. > Export of uncompressed ZIP > -------------------------- > > Key: SHRINKWRAP-445 > URL: https://issues.jboss.org/browse/SHRINKWRAP-445 > Project: ShrinkWrap > Issue Type: Feature Request > Affects Versions: 1.1.2 > Reporter: Michal Matloka > Assignee: Michal Matloka > > https://community.jboss.org/message/801704#801704 suggests: > "Would it be possible to control the compression level in shrinkwrap's ZipExporters implementation? The compression in this use case is unnecessary and slows down the deployment quite a bit." > We have to think, if it should be realised as sepearete UncompressedZipExporter, or to add general configurable compression level option to all compressing exporters. -- 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

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-121) WarMavenImporterTestCase fails under Windows

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-121?page=com.atlassian.jira.plu... ] Andrew Rubinger updated SHRINKRES-121: -------------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 2.0.0-beta-3 Resolution: Done Upstream: https://github.com/shrinkwrap/resolver/commit/437fc489f5dbe0d19dba787d82a... > WarMavenImporterTestCase fails under Windows > -------------------------------------------- > > Key: SHRINKRES-121 > URL: https://issues.jboss.org/browse/SHRINKRES-121 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Reporter: Michal Matloka > Assignee: Michal Matloka > Fix For: 2.0.0-beta-3 > > > {noformat} > Failed tests: importWarWithIncludes(org.jboss.shrinkwrap.resolver.impl.maven.archive.importer.WarMavenImporterTestCase): WEB-INF/web.xml should be included in archive war-sample.war: > importWar(org.jboss.shrinkwrap.resolver.impl.maven.archive.importer.WarMavenImporterTestCase): WEB-INF/web.xml should be included in archive war-sample.war: > {noformat} > Importer finds /WEB-INF\web.xml and compares it with /WEB-INF/web.xml -- 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

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-114) Support resolution of versions from a specific artifact

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-114?page=com.atlassian.jira.plu... ] Andrew Rubinger commented on SHRINKRES-114: ------------------------------------------- My comments on the PR. > Support resolution of versions from a specific artifact > ------------------------------------------------------- > > Key: SHRINKRES-114 > URL: https://issues.jboss.org/browse/SHRINKRES-114 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: impl-maven > Affects Versions: 2.0.0-beta-2 > Reporter: George Gastaldi > Assignee: Michal Matloka > > There are cases where a version of a specific artifact is unknown during test execution. > Aether supports version ranging: > {code}org.sonatype.aether.RepositorySystem.resolveVersionRange(RepositorySystemSession, VersionRangeRequest){code} > It would be nice to provide an API in ShrinkWrap Resolver to: > - Resolve the available versions from a specific given range > - From that range, the possibility to retrieve the lowest and the highest version > - Reuse this information to resolve artifacts using the already existing ShrinkWrap Resolver APIs -- 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

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-448) Using asSingleFile only works if you return a single file

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-448?page=com.atlassian.jira.pl... ] Michal Matloka commented on SHRINKWRAP-448: ------------------------------------------- IRC discussion from Mar 18. Filtered messages only concerning this issue. {quote} Mar 18 20:38:28 <jbossbot> new jira [SHRINKWRAP-448] Using asSingleFile only works if you return a single file [Open (Unresolved) Feature Request, Major, Unassigned] https://issues.jboss.org/browse/SHRINKWRAP-448 Mar 18 20:40:31 <mmatloka> johnament: I think asSingleFile intends to work as it works now - if returns more than one file throw exception Mar 18 20:41:13 <johnament> mmatloka: might be, but i've been told by ALR in the past that I should use asSingleFile whenever I use asFile()[0] :-) Mar 18 20:45:13 <mmatloka> johnament: 1. concerning asSingleFile - so when it resolves more than one file, and order is not specified, how would asSingleFiel work - return random one really? Mar 18 20:46:00 <johnament> mmatloka: it's a crap shoot, but would have the same issue here. Mar 18 20:47:12 <vineetreynolds> asSingleFile should throw some runtimeexception if there's more than one file in the resolution result imho Mar 18 20:47:47 <mmatloka> vineetreynolds: it throws NonUniqueResultException Mar 18 20:48:18 <johnament> but then it should only be available if you are using withoutTransitivity. Mar 18 20:48:19 <vineetreynolds> hmm Mar 18 20:49:42 <mmatloka> but even with withTransitivity it can return only single file? Mar 18 20:49:57 <johnament> mmatloka: no Mar 18 20:50:07 <johnament> mmatloka: with transitivity you get the file + all its dependencies. Mar 18 20:50:16 <johnament> without you should just get the file. Mar 18 20:50:25 <johnament> at least that's my understanding of maven Mar 18 20:50:25 <mmatloka> but it can have no dependencies what I mean :P Mar 18 20:50:39 <johnament> mmatloka: possible, but not likely. Mar 18 20:50:51 <johnament> if you had no depenendencies, then why use maven? Mar 18 20:51:27 <mmatloka> you're resolving project which internals you dont know, and to be sure you use transitivity Mar 18 20:53:08 <johnament> mmatloka: exactly. Mar 18 20:53:19 <johnament> so in that case, i'm pretty sure my file is in [0] Mar 18 20:53:29 <johnament> because its the top of the resolver chain Mar 18 20:55:48 <mmatloka> 1. so theoretically, If we would assume that shrinkwrap does not change anywhere order of artifacts, maybe something like getSingleTopXXX would be more appropriate Mar 18 20:57:05 <johnament> mmatloka: getFirstFile Mar 18 20:57:14 <mmatloka> yeah Mar 18 20:57:19 <johnament> but that's longer than .asFile()[0] Mar 18 20:57:40 <johnament> plus then you need to reresolve for .asFile()]1] Mar 18 20:57:44 <johnament> [1] Mar 18 21:08:24 <mmatloka> johnament: but using current asSingleFile still would be longer than .asFile()[0]? Mar 18 21:08:55 <johnament> mmatloka: yes Mar 18 21:09:05 <johnament> mmatloka: i'm not a fan of asSingleFile {quote} > Using asSingleFile only works if you return a single file > --------------------------------------------------------- > > Key: SHRINKWRAP-448 > URL: https://issues.jboss.org/browse/SHRINKWRAP-448 > Project: ShrinkWrap > Issue Type: Feature Request > Reporter: John Ament > > In this code example > return Maven.resolver().offline().loadPomFromFile("pom.xml") > .resolve(artifact) > .withTransitivity().asFile()[0]; > You should be able to replace asFile()[0] with asSingleFile, however it doesn't work since multiple files are actually returned. -- 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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues March 2013