November 2015 - shrinkwrap-issues

[JBoss JIRA] (SHRINKDESC-163) Deal with descriptors with multiple possible roots better

by Ralf Battenfeld (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-163?page=com.atlassian.jira.pl... ] Ralf Battenfeld commented on SHRINKDESC-163: -------------------------------------------- Hi Toby and Bob, did you had the chance to have a look at the proposed solution? > Deal with descriptors with multiple possible roots better > --------------------------------------------------------- > > Key: SHRINKDESC-163 > URL: https://issues.jboss.org/browse/SHRINKDESC-163 > Project: ShrinkWrap Descriptors > Issue Type: Feature Request > Affects Versions: 2.0.0-alpha-8 > Reporter: Toby Crawley > Assignee: Ralf Battenfeld > > When implementing SHRINKDESC-162, I created three different > descriptors for module.xml ({{ModuleDescriptor}}, > {{ModuleAliasDescriptor}}, {{ModuleAbsentDescriptor}}) corresponding to > the three root elements listed in the xsd ({{module}}, {{module-alias}}, > {{module-absent}}). This works fine if you are generating a module.xml, > but if you are loading in an existing file, you don't know without > looking at the file contents to know which type to instantiate. > It would be swell if there was a way for descriptors to support > multiple roots and do the correct thing. Or does that already exist > and I missed it? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-164) BeansDescriptor.exportAsString() yields empty xmlns attributes in child elements when Saxon is present on classpath

by Ralf Battenfeld (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-164?page=com.atlassian.jira.pl... ] Ralf Battenfeld commented on SHRINKDESC-164: -------------------------------------------- I executed the attached test case but I couldn't see any differences in the first spot by executing both profiles. Can you point me to the exact differences I should see? > BeansDescriptor.exportAsString() yields empty xmlns attributes in child elements when Saxon is present on classpath > ------------------------------------------------------------------------------------------------------------------- > > Key: SHRINKDESC-164 > URL: https://issues.jboss.org/browse/SHRINKDESC-164 > Project: ShrinkWrap Descriptors > Issue Type: Bug > Affects Versions: 2.0.0-alpha-7, 2.0.0-alpha-8 > Environment: Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00) > Maven home: C:\Program Files\apache-maven-3.2.5 > Java version: 1.7.0_80, vendor: Oracle Corporation > Java home: C:\Develop\CCS\jdk1.7.0_80\jre > Default locale: de_DE, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" > Reporter: Falko M. > Attachments: SHRINKDESC-164-testproject.zip > > > When an existing {{beans.xml}} with child elements like {{alternatives}} is loaded via {{Descriptors.importAs(BeansDescriptor.class).fromStream(...)}} *and [SAXON|http://saxon.sourceforge.net/] is on the classpath*, {{.exportAsString()}} yields child elements like the following : > {noformat}<alternatives xmlns="">{noformat} > This causes deployment warning in JBoss7 like (truncated): > {noformat} > WARN [org.jboss.weld.deployer] JBAS016011: .../META-INF/beans.xml:5 cvc-complex-type.2.4.a: Invalid content was found starting with element 'alternatives'. One of '{"http://java.sun.com/xml/ns/javaee":interceptors, "http://java.sun.com/xml/ns/javaee":decorators, "http://java.sun.com/xml/ns/javaee":alternatives, WC[##other:"http://java.sun.com/xml/ns/javaee"]}' is expected. > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 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: -------------------------------------- Yeah, the problem is not Wildfly since there is also a base image, the problem is for example other applications like Vault which does not have an official image or any application that you would like to run inside docker with an specific version. > 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)

10 years, 4 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: -------------------------------------------- Cool, nice to have that case more fully-spelled out. As a bit of an aside in solving that particular problem, is the WildFly image by chance available in some Maven repo? The ShrinkWrap Resolvers project already uses a cache in that it's backed by a Maven local repo, and anyone using that knows that by definition calls there may not reflect what's in the authoritative repo. > 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)

10 years, 4 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: -------------------------------------- Sure, the story behind this change is that currently in Arquillian Cube we can create docker images \o/ with Shrinkwrap. This means that for example if I want to create an image with Wildfly (I know there is already an official image), you will need to download each time 120MB. > 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)

10 years, 4 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: -------------------------------------------- Correct. :) So ShrinkWrap takes effort to provide really consistent and expected behaviours out of the box, prioritizing those qualities ahead of convenience. In that regard ShrinkWrap is a bit of a low-level tool by design. Now, there are occasions where we have to figure out where to draw the line. While I see your use case here certainly has merit (cutting time and saving resources in redownloading), I'd prefer not to solve it in the ShrinkWrap API. But I *could* be convinced otherwise; also interested in the opinions of [~aslak] and [~kpiwko] here. > 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)

10 years, 4 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: -------------------------------------- But then it is not useful at all, because for each execution you still need to download everything and this is what I would like to know. Of course user should be warned that this cache is common and until some time elapsed (for example 8 hours) the cache data will be the same. Of course user is free to not use the cache. > 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)

10 years, 4 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: -------------------------------------------- {code}Asset a = new UrlCacheableAsset(url); Asset b = new UrlCacheableAsset(url);{code} In the above, a and b have their own caches, not shared. > 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)

10 years, 4 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: -------------------------------------- Sure I can contribute on this, but I am not following you when you say "the cache to that object only". I think that you say that only cache things when user instantiate a new CacheUrlAsset right? In all other Assets there is no cache. > 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)

10 years, 4 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: -------------------------------------------- There be dragons here. :) While I can see sharing a cache scoped to a particular object, I wouldn't implement a cache in the ShrinkWrap API itself to be shared between objects. Especially in testing, calls should be idempotent so that each run of the test class does the same thing each time. Contents behind a URL can change over time, so if machine A and machine B have different caches at time X, they'll return different things. Of course a user is free to implement whatever Asset type they want and extend ShrinkWrap in that way. So +1 to some impl of UrlAsset which caches the content, but I would scope the cache to that object only. Pull requests welcome. Also, a version of this which uses a mem-based cache would be good too (basically wrapping ByteArrayAsset) > 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)

10 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues November 2015