March 2013 - shrinkwrap-issues - Jboss List Archives

[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: -------------------------------------------- Any chance of getting -alpha-5 ? > 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] (SHRINKWRAP-446) Incorrect behaviour of adding packages by name

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-446?page=com.atlassian.jira.pl... ] Andrew Rubinger commented on SHRINKWRAP-446: -------------------------------------------- Scanning all JARs on the CP is a solution I'd like to avoid where possible; it's a lengthy task with arbitrarily large (and uncapped) input. So "addPackages" requires the CL layer to know what it's capable of loading...thinking on this. More ideas welcome. > Incorrect behaviour of adding packages by name > ---------------------------------------------- > > Key: SHRINKWRAP-446 > URL: https://issues.jboss.org/browse/SHRINKWRAP-446 > Project: ShrinkWrap > Issue Type: Bug > Components: impl-base > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) (does not really matter though) > Java version: 1.7.0_15, vendor: Oracle Corporation > OS name: "linux", version: "3.2.0-38-generic", arch: "amd64", family: "unix" > Arquillian 1.0.3.Final > Shrinkwrap 2.0.0-alpha-3 > Reporter: Bartosz Majsak > > Following routine can fail if JAR is constructed with "filesonly" approach (as can be done through ANT). > {code:java} > addPackages(true, "groovy") > {code} > This invocation involves {{URLPackageScanner}}, which down under calls {{classLoader.getResources(name)}}. > I came across this behaviour while working on Groovy 2.0 support for Spock Test Runner. First I thought that there is some essential difference in the MANIFEST file. But after repacking ({{jar xvf}} and then {{jar cvf}}) including the same manifest file the test was passing. Here's the isolated problem shared as mvn project on [github|https://github.com/bartoszmajsak/groovy-classloading]. > Interestingly enough those two JARs are identical in terms of the content (at least based on what [pkgdiff|http://pkgdiff.github.com/pkgdiff/] is showing), but they were still different in the size. Then I tried {{zipinfo}}, and here's when I saw the real problem. Original groovy JAR was packaged without the directory entries, and therefore, according to this [bug evaluation from Sun|http://bugs.sun.com/view_bug.do?bug_id=4761949] the JAR is not found through the {{classLoader.getResource()}} call. To quote: > {quote} > In general, {{Class.getResource()}} is intended to access file based resources > (on the filesystem, or from jar files or wherever..) It is not specified > what the effect of accessing a directory entry is, and therefore this > behavior can not be expected to be the same across different URL schemes. > {quote} > As a solution we should scan all the jars from the classpath directly in case when {{classLoader.getResource()}} will return ambiguous {{null}} (as it can also mean that we don't have sufficient privileges according to the javadoc). -- 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-449) TarGzExporter wrong packing of paths with more than 100 characters

by Matej Lazar (JIRA)

Matej Lazar created SHRINKWRAP-449: -------------------------------------- Summary: TarGzExporter wrong packing of paths with more than 100 characters Key: SHRINKWRAP-449 URL: https://issues.jboss.org/browse/SHRINKWRAP-449 Project: ShrinkWrap Issue Type: Bug Components: impl-base Reporter: Matej Lazar Prefixes of long paths (> 100 chars) are ignored when unpacking archives with tar on linux. Packing "moreThan100/long/path/to/file.class" with TarGzExporter, is unpacked by linux tar as "long/path/to/file.class". Where "long/path/to/file.class" is just bellow 100 chars. -- 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 John Ament (JIRA)

John Ament created SHRINKWRAP-448: ------------------------------------- Summary: 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

[JBoss JIRA] (SHRINKRES-116) Gradle support

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-116?page=com.atlassian.jira.plu... ] Work on SHRINKRES-116 started by Michal Matloka. > Gradle support > -------------- > > Key: SHRINKRES-116 > URL: https://issues.jboss.org/browse/SHRINKRES-116 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Affects Versions: 2.0.0-beta-2 > Reporter: Michal Matloka > Assignee: Michal Matloka > > ShrinkWrap Resolver was designed to support multiple dependency management/build systems. It seems that there are already people using Gradle wanting to use ShrinkWrap. API seems much more friendly than Aether ;) and probably even supports build in 'build' feature. > http://forums.gradle.org/gradle/topics/dependency_resolution_with_gradle_... > http://gradle.1045684.n5.nabble.com/Gradle-support-for-Arquillian-maybe-a... > https://community.jboss.org/message/772433 -- 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-440) Create a CDI Archive

by John Ament (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-440?page=com.atlassian.jira.pl... ] John Ament commented on SHRINKWRAP-440: --------------------------------------- This might be a case for having reusable archives. Perhaps in your deployment utils, you create a "createCdiArchive" method that returns a JavaArchive w/ META-INF/beans.xml setup. What if it's a WAR File? > Create a CDI Archive > --------------------- > > Key: SHRINKWRAP-440 > URL: https://issues.jboss.org/browse/SHRINKWRAP-440 > Project: ShrinkWrap > Issue Type: Feature Request > Reporter: George Gastaldi > > A lot of projects do this to make an archive CDI-enabled: > {code} > addAsManifestResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml")); > {code} > It would be nice to have a addBeansXml() method together with a CdiArchive (or maybe automatically add it as the default behavior). -- 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-447) Need a better way to update a descriptor in a JAR

by John Ament (JIRA)

John Ament created SHRINKWRAP-447: ------------------------------------- Summary: Need a better way to update a descriptor in a JAR Key: SHRINKWRAP-447 URL: https://issues.jboss.org/browse/SHRINKWRAP-447 Project: ShrinkWrap Issue Type: Feature Request Reporter: John Ament Let's say I have a persistence.xml descriptor in a JAR. I've imported this prebuilt JAR from the file system or through a maven resolver. In my production code, I have a hibernate property "hibernate.hbm2ddl.auto" set to none. In my Arquillian test cases I want this to be "create-drop" so that the schema gets cleaned out frequently. Right now, in order to get that persistence.xml I need to "get" it, which returns a Node. I think need to use that Node to somehow (??) convert it to a string, then make it a descriptor. It would be much nicer if there was a get(String path, Class<?> retvalClass) that could do implicit conversion. -- 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-119) ClasspathWorkspaceReader may return a wrong POM file when run inside Surefire

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-119?page=com.atlassian.jira.plu... ] George Gastaldi updated SHRINKRES-119: -------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/shrinkwrap/resolver/pull/43 > ClasspathWorkspaceReader may return a wrong POM file when run inside Surefire > ----------------------------------------------------------------------------- > > Key: SHRINKRES-119 > URL: https://issues.jboss.org/browse/SHRINKRES-119 > Project: ShrinkWrap Resolvers > Issue Type: Bug > Components: impl-maven > Affects Versions: 2.0.0-beta-2 > Reporter: George Gastaldi > Assignee: George Gastaldi > > The ClasspathWorkspaceReader returns a wrong pom.xml file when the tests are run in Surefire as 'mvn package'. > This is the offending code: > {code} > final File pomFile = new File(file.getParentFile().getParentFile(), "pom.xml"); > {code} > A check against the requested artifact must be done before assuming that this pom.xml is the correct file to be returned in method findArtifact. -- 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-119) ClasspathWorkspaceReader may return a wrong POM file when run inside Surefire

by George Gastaldi (JIRA)

George Gastaldi created SHRINKRES-119: ----------------------------------------- Summary: ClasspathWorkspaceReader may return a wrong POM file when run inside Surefire Key: SHRINKRES-119 URL: https://issues.jboss.org/browse/SHRINKRES-119 Project: ShrinkWrap Resolvers Issue Type: Bug Components: impl-maven Affects Versions: 2.0.0-beta-2 Reporter: George Gastaldi Assignee: George Gastaldi The ClasspathWorkspaceReader returns a wrong pom.xml file when the tests are run in Surefire as 'mvn package'. This is the offending code: {code} final File pomFile = new File(file.getParentFile().getParentFile(), "pom.xml"); {code} A check against the requested artifact must be done before assuming that this pom.xml is the correct file to be returned in method findArtifact. -- 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-446) Incorrect behaviour of adding packages by name

by Bartosz Majsak (JIRA)

Bartosz Majsak created SHRINKWRAP-446: ----------------------------------------- Summary: Incorrect behaviour of adding packages by name Key: SHRINKWRAP-446 URL: https://issues.jboss.org/browse/SHRINKWRAP-446 Project: ShrinkWrap Issue Type: Bug Components: impl-base Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) (does not really matter though) Java version: 1.7.0_15, vendor: Oracle Corporation OS name: "linux", version: "3.2.0-38-generic", arch: "amd64", family: "unix" Arquillian 1.0.3.Final Shrinkwrap 2.0.0-alpha-3 Reporter: Bartosz Majsak Following routine can fail if JAR is constructed with "filesonly" approach (as can be done through ANT). {code:java} addPackages(true, "groovy") {code} This invocation involves {{URLPackageScanner}}, which down under calls {{classLoader.getResources(name)}}. I came across this behaviour while working on Groovy 2.0 support for Spock Test Runner. First I thought that there is some essential difference in the MANIFEST file. But after repacking ({{jar xvf}} and then {{jar cvf}}) including the same manifest file the test was passing. Here's the isolated problem shared as mvn project on [github|https://github.com/bartoszmajsak/groovy-classloading]. Interestingly enough those two JARs are identical in terms of the content (at least based on what [pkgdiff|http://pkgdiff.github.com/pkgdiff/] is showing), but they were still different in the size. Then I tried {{zipinfo}}, and here's when I saw the real problem. Original groovy JAR was packaged without the directory entries, and therefore, according to this [bug evaluation from Sun|http://bugs.sun.com/view_bug.do?bug_id=4761949] the JAR is not found through the {{classLoader.getResource()}} call. To quote: {quote} In general, {{Class.getResource()}} is intended to access file based resources (on the filesystem, or from jar files or wherever..) It is not specified what the effect of accessing a directory entry is, and therefore this behavior can not be expected to be the same across different URL schemes. {quote} As a solution we should scan all the jars from the classpath directly in case when {{classLoader.getResource()}} will return ambiguous {{null}} (as it can also mean that we don't have sufficient privileges according to the javadoc). -- 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