March 2013 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] (SHRINKWRAP-449) TarGzExporter wrong packing of paths with more than 100 characters

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-449?page=com.atlassian.jira.pl... ] Michal Matloka commented on SHRINKWRAP-449: ------------------------------------------- >From ant manual but describes tar behaviour. http://ant.apache.org/manual/Tasks/tar.html {noformat} Early versions of tar did not support path lengths greater than 100 characters. Modern versions of tar do so, but in incompatible ways. The behaviour of the tar task when it encounters such paths is controlled by the longfile attribute. If the longfile attribute is set to fail, any long paths will cause the tar task to fail. If the longfile attribute is set to truncate, any long paths will be truncated to the 100 character maximum length prior to adding to the archive. If the value of the longfile attribute is set to omit then files containing long paths will be omitted from the archive. Either option ensures that the archive can be untarred by any compliant version of tar. {noformat} > 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-449) TarGzExporter wrong packing of paths with more than 100 characters

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-449?page=com.atlassian.jira.pl... ] Michal Matloka edited comment on SHRINKWRAP-449 at 3/23/13 9:36 AM: -------------------------------------------------------------------- >From ant manual but describes tar behaviour. http://ant.apache.org/manual/Tasks/tar.html {quote} Early versions of tar did not support path lengths greater than 100 characters. Modern versions of tar do so, but in incompatible ways. The behaviour of the tar task when it encounters such paths is controlled by the longfile attribute. If the longfile attribute is set to fail, any long paths will cause the tar task to fail. If the longfile attribute is set to truncate, any long paths will be truncated to the 100 character maximum length prior to adding to the archive. If the value of the longfile attribute is set to omit then files containing long paths will be omitted from the archive. Either option ensures that the archive can be untarred by any compliant version of tar. {quote} was (Author: mmatloka): From ant manual but describes tar behaviour. http://ant.apache.org/manual/Tasks/tar.html {noformat} Early versions of tar did not support path lengths greater than 100 characters. Modern versions of tar do so, but in incompatible ways. The behaviour of the tar task when it encounters such paths is controlled by the longfile attribute. If the longfile attribute is set to fail, any long paths will cause the tar task to fail. If the longfile attribute is set to truncate, any long paths will be truncated to the 100 character maximum length prior to adding to the archive. If the value of the longfile attribute is set to omit then files containing long paths will be omitted from the archive. Either option ensures that the archive can be untarred by any compliant version of tar. {noformat} > 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-445) Export of uncompressed ZIP

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-445?page=com.atlassian.jira.pl... ] Michal Matloka updated SHRINKWRAP-445: -------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/shrinkwrap/shrinkwrap/pull/69 Proposal. Usage: {code} archive.as(ZipExporter.class).uncompressed().exportAsInputStream(); {code} > 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-114) Support resolution of versions from a specific artifact

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-114?page=com.atlassian.jira.plu... ] Michal Matloka commented on SHRINKRES-114: ------------------------------------------ Added PR - proposed API additions. > 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] (SHRINKRES-114) Support resolution of versions from a specific artifact

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-114?page=com.atlassian.jira.plu... ] Michal Matloka updated SHRINKRES-114: ------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/shrinkwrap/resolver/pull/45 > 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] (SHRINKRES-121) WarMavenImporterTestCase fails under Windows

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-121?page=com.atlassian.jira.plu... ] Michal Matloka updated SHRINKRES-121: ------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/shrinkwrap/resolver/pull/44 > 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 > > {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-121) WarMavenImporterTestCase fails under Windows

by Michal Matloka (JIRA)

Michal Matloka created SHRINKRES-121: ---------------------------------------- Summary: 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 {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-120) ClasspathWorkspaceReader does not implement findVersions method

by Michal Matloka (JIRA)

Michal Matloka created SHRINKRES-120: ---------------------------------------- Summary: ClasspathWorkspaceReader does not implement findVersions method Key: SHRINKRES-120 URL: https://issues.jboss.org/browse/SHRINKRES-120 Project: ShrinkWrap Resolvers Issue Type: Task Affects Versions: 2.0.0-beta-2 Reporter: Michal Matloka Assignee: Michal Matloka [~gastaldi] has implemented this method for Forge. Migration of implementation is possible. -- 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-143) Descriptors.importAs(ManifestDescriptor.class) crashes

by Rohan McGovern (JIRA)

Rohan McGovern created SHRINKDESC-143: ----------------------------------------- Summary: Descriptors.importAs(ManifestDescriptor.class) crashes Key: SHRINKDESC-143 URL: https://issues.jboss.org/browse/SHRINKDESC-143 Project: ShrinkWrap Descriptors Issue Type: Bug Components: impl-base Affects Versions: 2.0.0-alpha-3 Reporter: Rohan McGovern The following code: {code} DescriptorImporter<ManifestDescriptor> importer = Descriptors.importAs(ManifestDescriptor.class); {code} ... looks like it should work, but instead raises an exception like the following: {noformat} java.lang.RuntimeException: Configured importer for org.jboss.shrinkwrap.descriptor.api.spec.se.manifest.ManifestDescriptor of type: class org.jboss.shrinkwrap.descriptor.impl.base.spec.se.manifest.ManifestDescriptorImporter could not be created at org.jboss.shrinkwrap.descriptor.api.DescriptorInstantiator.createImporterFromUserView(DescriptorInstantiator.java:202) at org.jboss.shrinkwrap.descriptor.api.Descriptors.importAs(Descriptors.java:108) at org.jboss.shrinkwrap.descriptor.api.Descriptors.importAs(Descriptors.java:85) ... 68 more Caused by: java.lang.NoSuchMethodException: org.jboss.shrinkwrap.descriptor.impl.base.spec.se.manifest.ManifestDescriptorImporter.<init>(java.lang.Class, java.lang.String) at java.lang.Class.getConstructor0(Class.java:2730) at java.lang.Class.getConstructor(Class.java:1676) at org.jboss.shrinkwrap.descriptor.api.DescriptorInstantiator.createImporterFromUserView(DescriptorInstantiator.java:198) ... 72 more {noformat} It is possible to use {code}(new ManifestDescriptorImporter(null)){code} as 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

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: Resolved (was: Pull Request Sent) Fix Version/s: 2.0.0-beta-3 Resolution: Done > 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 > Fix For: 2.0.0-beta-3 > > > 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues March 2013