[JBoss JIRA] Created: (SHRINKDESC-47) Support for Java 1.5
by David Allen (JIRA)
Support for Java 1.5
--------------------
Key: SHRINKDESC-47
URL: https://issues.jboss.org/browse/SHRINKDESC-47
Project: ShrinkWrap Descriptors
Issue Type: Feature Request
Components: api
Environment: Release 0.1.4
Java 1.5.0_06 (Sun)
Reporter: David Allen
The compiler plugin was setup to target Java 1.6 only. Despite ShrinkWrap and Arquillian targeting 1.5, with this project included, everything is limited to Java 1.6 environments only.
I have already re-built 0.1.4 locally with 1.5 and everything works fine. Is there some reason why Java 1.6 is required for ShrinkWrap Descriptors?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] Created: (SHRINKWRAP-233) addClass with DefaultPackage opens addPackage to null arguments
by Aslak Knutsen (JIRA)
addClass with DefaultPackage opens addPackage to null arguments
---------------------------------------------------------------
Key: SHRINKWRAP-233
URL: https://jira.jboss.org/browse/SHRINKWRAP-233
Project: ShrinkWrap
Issue Type: Bug
Reporter: Aslak Knutsen
When adding a Class in addClass, we do a addPackage with a Filter to match inner classes of that class.
When adding a Class in Default package, the Package we padd to addPackage is null. Meaning addPackage can't verify non null values.
The downside is, if someone happens to add, e.g.
addPakcage(true, Package.get("some-missing-package")), addPackage will be called with null, and null means /, which means all found packages are added.
We need to split addPackage(boolean, Filter, Package...) into two methods, one external which does the null checks from the user and one internal that does not check for null(to support Class in default package).
--
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
[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
[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
[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
[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
[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