March 2011 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] Created: (SHRINKWRAP-193) Should be able to 'mount' a added jar

by Aslak Knutsen (JIRA)

Should be able to 'mount' a added jar ------------------------------------- Key: SHRINKWRAP-193 URL: https://jira.jboss.org/browse/SHRINKWRAP-193 Project: ShrinkWrap Issue Type: Feature Request Components: api, impl-base Reporter: Aslak Knutsen You can only manipulate on ShrinkWrap(open/uncompressed) archives when they are ArchiveAssets. Some times it can be useful to manipulate an existing(closed/compressed) nested archive. Add something to a library added by 'someone' else... We should support to import/mount a already added compressed library. [code] WebArchive war = ShrinkWrap.create(WebArchive.class) .addLibrary(new File("blag.jar")) JavaArchive jar = war.as(Importer.class) .import( JavaArchive.class, Archivepaths.create("lib/blag.jar")) [code] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
4
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-268) MavenDependencyResolver.loadReposFromPom and loadDependenciesFromPom methods are missleading

by Karel Piwko (JIRA)

MavenDependencyResolver.loadReposFromPom and loadDependenciesFromPom methods are missleading -------------------------------------------------------------------------------------------- Key: SHRINKWRAP-268 URL: https://issues.jboss.org/browse/SHRINKWRAP-268 Project: ShrinkWrap Issue Type: Enhancement Components: ext-resolver Affects Versions: 1.0.0-alpha-12 Reporter: Karel Piwko Current state: {code} loadReposFromPom(String file) {code} Loads a POM file and activates all repositories present there, moreover it loads all <dependencies> into cache so user can omit version in artifact specification. => should be renamed to loadMetadataFromPom(String file) or split to loadReposFromPom(String file), loadDependencyVersionsFromPom(String file) and aggregator loadMetadataFromPom(String file) {code} loadDepedenciesFromPom(String file) {code} Loads a POM file and adds all dependencies present there to the dependency chain. This means once the resolveXYZ() is called dependencies from POM are resolved. => should be renamed to includeDependenciesFromPom(String file) {code} loadDependenciesFromPom(String file, MavenResolutionFilter filter) {code} Does the same as previous, filter is not used there but during resolveXYZ() => should be removed -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
3
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-240) addServiceProvider should add class to archive

by Dan Allen (JIRA)

addServiceProvider should add class to archive ---------------------------------------------- Key: SHRINKWRAP-240 URL: https://jira.jboss.org/browse/SHRINKWRAP-240 Project: ShrinkWrap Issue Type: Feature Request Components: api Affects Versions: 1.0.0-alpha-11 Reporter: Dan Allen Priority: Minor My intuition tells me that addServiceProvider should add the service provider classes I specify to the archive. To my surprise, it does not. I can't see any scenario in which you specify a service provider for a class that isn't in the archive. For the edge case, you could always extract it manually after the call to addServiceProvider. Currently: addClass(MyServiceImpl.class).addServiceProvider(Service.class, MyServiceImpl.class) Proposed: addServiceProvider(Service.class, MyServiceImpl.class) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

3
6
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-227) Assignable#as() is confusing for Archive implementors

by Pete Muir (JIRA)

Assignable#as() is confusing for Archive implementors ----------------------------------------------------- Key: SHRINKWRAP-227 URL: https://jira.jboss.org/browse/SHRINKWRAP-227 Project: ShrinkWrap Issue Type: Bug Components: api Affects Versions: 1.0.0-alpha-11 Reporter: Pete Muir Assignee: Aslak Knutsen Assignable#as() needs an @see ExtensionLoader ExtensionLoader needs to explain the default strategy clearly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

3
5
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-191) Automatic creation of MANIFEST.MF

by Peter Skopek (JIRA)

Automatic creation of MANIFEST.MF --------------------------------- Key: SHRINKWRAP-191 URL: https://jira.jboss.org/browse/SHRINKWRAP-191 Project: ShrinkWrap Issue Type: Feature Request Components: impl-base Reporter: Peter Skopek While working with ShrinkWrap on my tests project I have come to need of automatic creation of default MANIFEST.MF file in META-INF directory. I would like to have it for every archive which extends ManifestContainer<?>. So, it would work the best when it will be created at the creation of archive and in case of user add his own the default one will be overwritten. Content of the default MANIFEST.MF could be as simple as this: Manifest-Version: 1.0 Created-By: 1.0.0 (ShrinkWrap) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

3
4
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-253) ClassAsset / ClassLoaderAsset should not use TCCL

by Aslak Knutsen (JIRA)

ClassAsset / ClassLoaderAsset should not use TCCL ------------------------------------------------- Key: SHRINKWRAP-253 URL: https://issues.jboss.org/browse/SHRINKWRAP-253 Project: ShrinkWrap Issue Type: Bug Reporter: Aslak Knutsen ClassAsset.openStream should not fall back to using TCCL if class.getClassLoader is null. That means it's a System resource and static ClassLoader.getResourceAsStream should be used instead. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

4
8
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-266) Manifest container for WebArchive should be WEB-INF/classes/META-INF

by Dan Allen (JIRA)

Manifest container for WebArchive should be WEB-INF/classes/META-INF -------------------------------------------------------------------- Key: SHRINKWRAP-266 URL: https://issues.jboss.org/browse/SHRINKWRAP-266 Project: ShrinkWrap Issue Type: Bug Components: impl-base Affects Versions: 1.0.0-alpha-12 Reporter: Dan Allen This issue is a regression of SHRINKWRAP-186. The location of the ManifestContainer for a WebArchive should be /WEB-INF/classes/META-INF, not /META-INF. This location is backed up by our target locations per archive type page. http://community.jboss.org/wiki/Containerrootsperspecarchive A sample use case is bundling a persistence.xml in a web archive: {code:java} WebArchive war = ShrinkWrap.create(WebArchive.class, "test.war") .addAsManifestResource("test-persistence.xml", "persistence.xml"); System.out.println(war.toString(true)); {code} Current output: {code} test.war /META-INF/ /META-INF/persistence.xml {code} Expected output: {code} test.war /WEB-INF/ /WEB-INF/classes/ /WEB-INF/classes/persistence.xml {code} This also breaks the ServiceLoader registrations, as they appear in /META-INF/services/ rather than in /WEB-INF/classes/META-INF/services/ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

4
20
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-88) Look at Import/Export API methods for consistency/convenience

by Aslak (JIRA)

Look at Import/Export API methods for consistency/convenience ------------------------------------------------------------- Key: SHRINKWRAP-88 URL: https://jira.jboss.org/jira/browse/SHRINKWRAP-88 Project: ShrinkWrap Issue Type: Task Components: api, impl-base Reporter: Aslak make import/export api naming/arguments equalequal import(url|file|resource) export(url|file) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 12 months

4
7
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-110) Code Review and Action Items on ExtensionLoader/ServiceExtensionLoader

by Andrew Lee Rubinger (JIRA)

Code Review and Action Items on ExtensionLoader/ServiceExtensionLoader ---------------------------------------------------------------------- Key: SHRINKWRAP-110 URL: https://jira.jboss.org/jira/browse/SHRINKWRAP-110 Project: ShrinkWrap Issue Type: Task Components: api, impl-base Reporter: Andrew Lee Rubinger We should do a community review on the ExtensionLoader API and ServiceExtensionLoader implementation. This is the mechanism used to power Assignable.as(); * Archives API should not expose extension loading configuration (SHRINKWRAP-102) * ServiceExtensionLoader needs documentation at class-level and on methods * ServiceExtensionLoader is not Thread-safe (or documented that this is the responsibility of the client, ArchiveBase, which does not sync access) * OK to always use TCCL at time of instantiation to find extension impls and classes? * ServiceExtensionLoader instance needs to be carried in the state of every archive? Should some Assignable types be given access to different service extension loaders? To me this looks like a singular point of configuration possibly warranting use of a Singleton. * All extension loading as a feature needs Wiki documentation -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 12 months

2
2
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-175) Review Filter usage in API for consistency and applicability

by Andrew Lee Rubinger (JIRA)

Review Filter usage in API for consistency and applicability ------------------------------------------------------------ Key: SHRINKWRAP-175 URL: https://jira.jboss.org/browse/SHRINKWRAP-175 Project: ShrinkWrap Issue Type: Task Components: api Reporter: Andrew Lee Rubinger Fix For: 1.0.0-beta-1 Usage of "Filter" is currently sprinkled about inconsistenty. Ensure it's applied on all multi-* operations (like ClassContainer.addClasses) and its JavaDoc is updated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 12 months

3
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues March 2011