[
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)