January 2011 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] Created: (SHRINKWRAP-228) URLPackage scanner returns wrong classname

by Aslak Knutsen (JIRA)

URLPackage scanner returns wrong classname ------------------------------------------ Key: SHRINKWRAP-228 URL: https://jira.jboss.org/browse/SHRINKWRAP-228 Project: ShrinkWrap Issue Type: Bug Components: impl-base Affects Versions: 1.0.0-alpha-11 Reporter: Aslak Knutsen Assignee: Aslak Knutsen When adding a package that contains a Class which contains "class" in the name, the ClassName given to the filter is wrong. -- 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

15 years

2
3
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-229) Should be able to add Packages based on String name

by Aslak Knutsen (JIRA)

Should be able to add Packages based on String name --------------------------------------------------- Key: SHRINKWRAP-229 URL: https://jira.jboss.org/browse/SHRINKWRAP-229 Project: ShrinkWrap Issue Type: Feature Request Components: api, impl-base Reporter: Aslak Knutsen Assignee: Aslak Knutsen Problem: Adding all classes to a parent package that does not contain a class is not possible. The Parent Package is never created by the jvm etc. You have to manually add all sub packages instead. Adding classes from a package where no Classes have been loaded from yet is not possible, jvm lazy creates the packages. e.g. Pakcage.getPackage("my.package") does not exist until a class in "my.package" has been loaded. Workaround is to force load a class e.g. my.package.MyClass.class.getPackage() Solution: Add method to ClassContainer API - addPackage(String packageName) - addPackages(boolean recursive, String... packageNames) - addPackages(boolean recursive, Filter<ArchivePath> filter, String... packageNames) -- 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

15 years

2
3
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-254) Support creation of URLs from a Archive

by Aslak Knutsen (JIRA)

Support creation of URLs from a Archive --------------------------------------- Key: SHRINKWRAP-254 URL: https://issues.jboss.org/browse/SHRINKWRAP-254 Project: ShrinkWrap Issue Type: Feature Request Components: api, impl-base Affects Versions: 1.0.0-alpha-11 Reporter: Aslak Knutsen Assignee: Aslak Knutsen A lot of a external APIs rely on the use of URLs as a means of transferring archives across the wire, it would be useful if a Archive could easily be converted into a URL. {code} deploymentManager.distribute(archive.getName(), archive.toURL(), true); {code} -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years

2
2
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-195) ZipExporterTestCase.testExportArchiveWithOnlyDirectories contains no assertions

by Andrew Lee Rubinger (JIRA)

ZipExporterTestCase.testExportArchiveWithOnlyDirectories contains no assertions ------------------------------------------------------------------------------- Key: SHRINKWRAP-195 URL: https://jira.jboss.org/browse/SHRINKWRAP-195 Project: ShrinkWrap Issue Type: Task Reporter: Andrew Lee Rubinger Fix For: 1.0.0-alpha-11 Check contents are as expected, don't just run the export operation and hope all's well. -- 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

15 years

2
2
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-218) Add multiple modules at once to EnterpriseArchive

by Michael Schuetz (JIRA)

Add multiple modules at once to EnterpriseArchive ------------------------------------------------- Key: SHRINKWRAP-218 URL: https://jira.jboss.org/browse/SHRINKWRAP-218 Project: ShrinkWrap Issue Type: Feature Request Reporter: Michael Schuetz At the moment I can add multiple modules to EnterpriseArchiv like this: final EnterpriseArchive ear = ShrinkWrap.create(EnterpriseArchive.class, "test.ear") .addModule(ejb) .addModule(war) .addModule(ArtifactResolver.resolve("org.jboss.seam:jboss-seam:2.2.0.GA")); Would be nice to shorten this a bit, like this: final EnterpriseArchive ear = ShrinkWrap.create(EnterpriseArchive.class, "test.ear") .addModules(ejb, war, ArtifactResolver.resolve("org.jboss.seam:jboss-seam:2.2.0.GA")); -- 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

15 years

4
6
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-190) Improve Exception on ClassNotFoundException during addPackage

by Aslak Knutsen (JIRA)

Improve Exception on ClassNotFoundException during addPackage ------------------------------------------------------------- Key: SHRINKWRAP-190 URL: https://jira.jboss.org/browse/SHRINKWRAP-190 Project: ShrinkWrap Issue Type: Feature Request Components: impl-base Affects Versions: 1.0.0-alpha-10 Reporter: Aslak Knutsen It's possible to get ClassNotFoundException during addPackage(..) since the Classes found are loaded. If a Class found refers to a Class not in the Classloader. Currently the Exception states only which class it can not find, it would be helpful to add which Class is being loaded that cause the ClassNotFoundException. java.lang.NoClassDefFoundError: org/aopalliance/intercept/MethodInvocation at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:634) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:277) at java.net.URLClassLoader.access$000(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:212) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:205) at java.lang.ClassLoader.loadClass(ClassLoader.java:321) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:266) at org.jboss.shrinkwrap.impl.base.container.ContainerBase$2.classFound(ContainerBase.java:932) at org.jboss.shrinkwrap.impl.base.URLPackageScanner.foundClass(URLPackageScanner.java:178) at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handleArchiveByFile(URLPackageScanner.java:134) at org.jboss.shrinkwrap.impl.base.URLPackageScanner.handle(URLPackageScanner.java:156) at org.jboss.shrinkwrap.impl.base.URLPackageScanner.scanPackage(URLPackageScanner.java:107) at org.jboss.shrinkwrap.impl.base.container.ContainerBase.addPackages(ContainerBase.java:917) -- 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

15 years

2
5
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-243) Dependencies does not find remote repositories set in settings.xml

by Aslak Knutsen (JIRA)

Dependencies does not find remote repositories set in settings.xml ------------------------------------------------------------------ Key: SHRINKWRAP-243 URL: https://jira.jboss.org/browse/SHRINKWRAP-243 Project: ShrinkWrap Issue Type: Feature Request Components: ext-dependencies Affects Versions: 1.0.0-alpha-12 Reporter: Aslak Knutsen Assignee: Karel Piwko Using activeDefault profiles in settings.xml does not seem to be included in the remote repository resolution in Dependencies. e.g. .m2/settings.xml <profiles> <profile> <activation> <activeByDefault>true</activeByDefault> </activation> <repositories> <repository> <id>jboss-public-repository-group</id> <name>JBoss Public Repository Group</name> <url>http://repository.jboss.org/nexus/content/groups/public/</url> <layout>default</layout> <releases> <enabled>true</enabled> <updatePolicy>never</updatePolicy> </releases> <snapshots> <enabled>true</enabled> <updatePolicy>never</updatePolicy> </snapshots> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>jboss-public-repository-group</id> <name>JBoss Public Repository Group</name> <url>http://repository.jboss.org/nexus/content/groups/public/</url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>true</enabled> </snapshots> </pluginRepository> </pluginRepositories> </profile> </profiles> -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

3
6
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-241) remap targets for WebArchive add methods

by Dan Allen (JIRA)

remap targets for WebArchive add methods ---------------------------------------- Key: SHRINKWRAP-241 URL: https://jira.jboss.org/browse/SHRINKWRAP-241 Project: ShrinkWrap Issue Type: Feature Request Components: api Affects Versions: 1.0.0-alpha-11 Reporter: Dan Allen Fix For: 1.0.0-alpha-12 The Servlet specification specifically defines static and dynamic served from the web application as "web resources". Hence, the use of "addWebResource" to refer to WEB-INF is a mistake, and reopens the discussion of how each add* method should be mapped. Currently, the targets for the WebArchive add methods are: add() maps to / addResource() maps to / addWebResource() maps to /WEB-INF addManifestResource() maps to /WEB-INF/classes/META-INF (I know these are being refactor to "addAs". I'm just sticking with the terminology that's currently in place for the purpose of this discussion). To start, I think we should explicitly refer to WEB-INF by name, as in: addWebInfResource() maps to /WEB-INF Next, we should honor the "web resource" definition from the Servlet specification addWebResource() maps to / Now, because WebArchive is inheriting addResource() from ResourceArchive, we should honor the function of the target location, so: addResource() maps to /WEB-INF/classes Finally, we have to address add() inherited from Archive. In this case, I'm okay with sticking with add() as meaning the root of whatever archive we have: add() maps to / So, here's what an example might look like: WebArchive war = ShrinkWrap.create(WebArchive.class, "app.war") .addWebInfResource(EmptyAsset.INSTANCE, "beans.xml") .addWebResource(new StringAsset("<html><body>Hello World!</body></html>"), "index.html") .addResource(new StringAsset("foo=bar"), "messages.properties); System.out.println(war.toString(true)); prints: app.war /index.html /WEB-INF/beans.xml /WEB-INF/classes/messages.properties To me, this makes so much more sense. Hopefully you share the same opinion. -- 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

15 years, 1 month

3
12
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-213) Create a Descriptors Project

by Andrew Lee Rubinger (JIRA)

Create a Descriptors Project ---------------------------- Key: SHRINKWRAP-213 URL: https://jira.jboss.org/browse/SHRINKWRAP-213 Project: ShrinkWrap Issue Type: Feature Request Components: descriptors Reporter: Andrew Lee Rubinger Responsibility of this Project is to provide a DSL object model for generating Java EE Spec XML. Should eventually spin off into modules: - api (The DSL) - shrinkwrap-int (represents the final XML view export view as a ShrinkWrap Asset type) - impl (Does the XML generation logic) -- 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

15 years, 1 month

3
3
0 / 0

[JBoss JIRA] Created: (SHRINKDESC-23) Web app descriptor tests fail because of carriage return

by Andy Gibson (JIRA)

Web app descriptor tests fail because of carriage return -------------------------------------------------------- Key: SHRINKDESC-23 URL: https://jira.jboss.org/browse/SHRINKDESC-23 Project: ShrinkWrap Descriptors Issue Type: Bug Components: api Affects Versions: 1.0.0-alpha-1 Environment: Windows, Dos, maven 3.0, JDK 1.6 Reporter: Andy Gibson The tests for the web app descriptors are failing because of the carriage return in the expected web.xml files in the test/resources used to compare the actual results with what it should be. The fix is to change the assert equals to Assert.assertEquals(expected.toString().replace("\r",""), webApp); for each one to strip out the carriage returns, but leave the line feeds. I'll submit a fix for it through GitHub. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 1 month

2
3
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues January 2011