December 2015 - shrinkwrap-issues

[JBoss JIRA] (SHRINKRES-234) Declared dependency order is not the same as in Maven

by Karel Piwko (JIRA)

Karel Piwko created SHRINKRES-234: ------------------------------------- Summary: Declared dependency order is not the same as in Maven Key: SHRINKRES-234 URL: https://issues.jboss.org/browse/SHRINKRES-234 Project: ShrinkWrap Resolvers Issue Type: Feature Request Affects Versions: 2.2.0 Reporter: Karel Piwko It looks that SWR does not preserve order of dependencies as they are coming from Aether because of HashSet storage in MavenDependencySession. https://github.com/shrinkwrap/resolver/blob/0da07b860d34ce048270b06200a56... This might cause problems if constructing classpath manually from resolved dependencies. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-497) Maven resolver does not support global settings file

by Jeff MAURY (JIRA)

Jeff MAURY created SHRINKWRAP-497: ------------------------------------- Summary: Maven resolver does not support global settings file Key: SHRINKWRAP-497 URL: https://issues.jboss.org/browse/SHRINKWRAP-497 Project: ShrinkWrap Issue Type: Bug Components: ext-resolver Reporter: Jeff MAURY When using the Maven resolver together with the shrinkwrap-resolver-maven-plugin, the Maven session can be configured with the user settings file but not with the global settings file. See ConfigureSettingsFromPluginTask -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-496) Implement CacheUrlAsset

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-496?page=com.atlassian.jira.pl... ] Andrew Rubinger closed SHRINKWRAP-496. -------------------------------------- Resolution: Won't Fix Marking as won't fix for now, as Alex will handle it in Cube, but we can reopen if the need persists. > Implement CacheUrlAsset > ----------------------- > > Key: SHRINKWRAP-496 > URL: https://issues.jboss.org/browse/SHRINKWRAP-496 > Project: ShrinkWrap > Issue Type: Feature Request > Components: api > Affects Versions: 1.2.3 > Reporter: Alex Soto > Priority: Minor > > In ShrinkWrap UrlAsset downloaded an asset from a URL, which can be external and then it creates the Archive element with that info. The problem is that sometimes you might want to download a big file (2MB) to put inside an Archive, and this means that for each test class that you execute you end up by downloading this file. > A possible solution could be create a CacheUrlAsset that downloads the content and stores it in {java.io.tmp}/shrinkwrap so in successive calls before downloading the file again, it can take it directly from cache directory. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-496) Implement CacheUrlAsset

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-496?page=com.atlassian.jira.pl... ] Andrew Rubinger commented on SHRINKWRAP-496: -------------------------------------------- [~asotobu] Sounds like a good approach to me, fixing it closest to the defining use case for now. Only issue I might see is if we want to move it and you've already locked the Cube API (and are putting this in a public API), then you're bound to it. Thanks for working through this so we can find the most appropriate spot for it. In ShrinkWrap proper I'd be hesitant to throw this in unless it was *REALLY* clear that its use is non-idempotent and wouldn't take the exact same action from test run to test run. > Implement CacheUrlAsset > ----------------------- > > Key: SHRINKWRAP-496 > URL: https://issues.jboss.org/browse/SHRINKWRAP-496 > Project: ShrinkWrap > Issue Type: Feature Request > Components: api > Affects Versions: 1.2.3 > Reporter: Alex Soto > Priority: Minor > > In ShrinkWrap UrlAsset downloaded an asset from a URL, which can be external and then it creates the Archive element with that info. The problem is that sometimes you might want to download a big file (2MB) to put inside an Archive, and this means that for each test class that you execute you end up by downloading this file. > A possible solution could be create a CacheUrlAsset that downloads the content and stores it in {java.io.tmp}/shrinkwrap so in successive calls before downloading the file again, it can take it directly from cache directory. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SHRINKWRAP-496) Implement CacheUrlAsset

by Alex Soto (JIRA)

[ https://issues.jboss.org/browse/SHRINKWRAP-496?page=com.atlassian.jira.pl... ] Alex Soto commented on SHRINKWRAP-496: -------------------------------------- As first approach I am going to implement it inside Cube. Since this requirement comes from Cube, let's implement there and if you think it can be moved to Shrinkwrap core then we can choose where it fits better. > Implement CacheUrlAsset > ----------------------- > > Key: SHRINKWRAP-496 > URL: https://issues.jboss.org/browse/SHRINKWRAP-496 > Project: ShrinkWrap > Issue Type: Feature Request > Components: api > Affects Versions: 1.2.3 > Reporter: Alex Soto > Priority: Minor > > In ShrinkWrap UrlAsset downloaded an asset from a URL, which can be external and then it creates the Archive element with that info. The problem is that sometimes you might want to download a big file (2MB) to put inside an Archive, and this means that for each test class that you execute you end up by downloading this file. > A possible solution could be create a CacheUrlAsset that downloads the content and stores it in {java.io.tmp}/shrinkwrap so in successive calls before downloading the file again, it can take it directly from cache directory. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues December 2015