April 2012 - shrinkwrap-issues - Jboss List Archives

[JBoss JIRA] (SHRINKWRAP-395) ShrinkWrap should be able to exclude its own and Arquillian's -impl archives

by Craig Ringer (JIRA)

Craig Ringer created SHRINKWRAP-395: --------------------------------------- Summary: ShrinkWrap should be able to exclude its own and Arquillian's -impl archives Key: SHRINKWRAP-395 URL: https://issues.jboss.org/browse/SHRINKWRAP-395 Project: ShrinkWrap Issue Type: Feature Request Components: ext-resolver Environment: Linux wallace 3.0.0-14-generic-pae #23-Ubuntu SMP Mon Nov 21 22:07:10 UTC 2011 i686 i686 i386 GNU/Linux java version "1.7.0" Java(TM) SE Runtime Environment (build 1.7.0-b147) Java HotSpot(TM) Server VM (build 21.0-b17, mixed mode) JBoss AS 7.1.1.Final Arquillian 1.0.0.Final Reporter: Craig Ringer I'm using ShrinkWrap via Arquillian 1.0.0.Final. When the Maven Dependency Resolver extension is used to load dependencies from a project pom, the ShrinkWrap and Arquillian dependencies are automatically included in produced ShrinkWrap archives. There doesn't appear to be any easy way to tell ShrinkWrap to leave its own -impl archives out, so a trivial test archive bloats to 31MB or more of Arquilian and ShrinkWrap archives and dependencies. Some of the transitive dependencies could cause conflicts with app server libraries, too. What I'd like to see is a very quick and easy way to tell the Maven resolver to exclude anything from ShrinkWrap or Arquillian when loading dependencies from a pom.xml, eg: MavenDependencyResolver resolver = DependencyResolvers.use(MavenDependencyResolver.class) .includeDependenciesFromPom("pom.xml"); .excludeShrinkWrap().excludeArquillian(); // Imaginary for now Currently one should be able to do something like: MavenDependencyResolver resolver = DependencyResolvers.use(MavenDependencyResolver.class) .includeDependenciesFromPom("pom.xml") .exclusions("org.jboss.shrinkwrap.descriptors:shrinkwrap-descriptors-impl-javaee", "org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-impl-maven", "org.jboss.arquillian.junit:arquillian-junit-container", "org.jboss.as:jboss-as-arquillian-container-remote"); ... but in my quick tests it appeared to have no effect. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

2
2
0 / 0

[JBoss JIRA] (SHRINKWRAP-394) Artifacts from dependencyManagement imported pom not resolved

by Craig Ringer (JIRA)

Craig Ringer created SHRINKWRAP-394: --------------------------------------- Summary: Artifacts from dependencyManagement imported pom not resolved Key: SHRINKWRAP-394 URL: https://issues.jboss.org/browse/SHRINKWRAP-394 Project: ShrinkWrap Issue Type: Bug Affects Versions: 1.0.0-cr-1 Environment: JBoss AS 7.1.1.Final java version "1.7.0_01" Java(TM) SE Runtime Environment (build 1.7.0_01-b08) Java HotSpot(TM) 64-Bit Server VM (build 21.1-b02, mixed mode) Linux ayaki.localdomain 3.3.0-4.fc16.x86_64 #1 SMP Tue Mar 20 18:05:40 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Reporter: Craig Ringer ShrinkWrap's Maven Dependency Resolver (version 1.0.0-beta-5, also tested with 1.0.0-beta-6) fails to resolve artifacts where the version is specified by an imported bom in the dependencyManagement section, or where the artifact isn't in central even if it's in a repo listed by the project's pom.xml. See the attached self contained test case. Examine DemoTest.java; you'll see two different artifact co-ordinates for Seam 3 Security, neither of which works. The project's pom finds seam 3 security fine via the imported seam 3 bom, but the shrinkwrap dependency resolver doesn't even after loading the project's pom.xml via configureFrom(...) . If I use the co-ordinates: org.jboss.seam.security:seam-security ShrinkWrap fails with: java.lang.IllegalArgumentException: Bad artifact coordinates, expected format is <groupId>:<artifactId>[:<extension>[:<classifier>]]:<version> if I specify a version explicitly (which shouldn't be necessary since it's in the seam 3 bom imported via dependencyManagement) it instead says it can't find the artifact in Central, even though the jboss repo is listed in pom.xml: org.jboss.seam.security:seam-security:3.1.0.Final produces: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not find artifact org.jboss.seam.security:seam-security:jar:3.1.0.Final in central (http://repo1.maven.org/maven2) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

2
6
0 / 0

[JBoss JIRA] Created: (SHRINKDESC-26) Env-Entry should be mappable in WebAppDescriptor

by Aslak Knutsen (JIRA)

Env-Entry should be mappable in WebAppDescriptor ------------------------------------------------ Key: SHRINKDESC-26 URL: https://jira.jboss.org/browse/SHRINKDESC-26 Project: ShrinkWrap Descriptors Issue Type: Feature Request Reporter: Aslak Knutsen <env-entry> <env-entry-name>name</env-entry-name> <env-entry-type>java.lang.String</env-entry-type> <env-entry-value>value</env-entry-value> </env-entry> -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

3
3
0 / 0

[JBoss JIRA] (SHRINKWRAP-396) Automatic paths for descriptor import from project and packaging into archives

by Craig Ringer (JIRA)

Craig Ringer created SHRINKWRAP-396: --------------------------------------- Summary: Automatic paths for descriptor import from project and packaging into archives Key: SHRINKWRAP-396 URL: https://issues.jboss.org/browse/SHRINKWRAP-396 Project: ShrinkWrap Issue Type: Feature Request Components: ext-descriptors Environment: Linux wallace 3.0.0-14-generic-pae #23-Ubuntu SMP Mon Nov 21 22:07:10 UTC 2011 i686 i686 i386 GNU/Linux java version "1.7.0" Java(TM) SE Runtime Environment (build 1.7.0-b147) Java HotSpot(TM) Server VM (build 21.0-b17, mixed mode) JBoss AS 7.1.1.Final Arquillian 1.0.0.Final Reporter: Craig Ringer Using BeansDescriptor, PersistenceDescriptor, etc is currently a bit more verbose and error prone than it really needs to be. These descriptors have very well established locations in the source tree in standard Maven structured projects, and absolutely fixed locations within archives of a given type. The descriptors module should know those locations and be able to use them unless overridden. Current code for loading and using beans.xml and persistence.xml is currently pretty verbose and repeats paths that're fixed by strong convention and/or standards requirements: BeansDescriptor beansXml = Descriptors.importAs(BeansDescriptor.class) .from(new File("src/main/webapp/WEB-INF/beans.xml")); PersistenceDescriptor persistenceXml = Descriptors.importAs(PersistenceDescriptor.class) .from(new File("src/main/resources/META-INF/persistence.xml")); WebArchive war = ShrinkWrap.create(WebArchive.class, "demo.war") .addPackage(Demo.class.getPackage()) .addAsWebInfResource(new StringAsset(beansXml.exportAsString()), "beans.xml") .addAsResource(new StringAsset(persistenceXml.exportAsString()), "META-INF/persistence.xml"); The paths to beans.xml and persistence.xml are dependent on the archive type but otherwise absolutely fixed by convention. As such, it *should* be possible to write something like: BeansDescriptor beansXml = Descriptors.importAs(BeansDescriptor.class).fromDefaultLocation(); PersistenceDescriptor persistenceXml = Descriptors.importAs(PersistenceDescriptor.class).fromDefaultLocation(); WebArchive war = ShrinkWrap.create(WebArchive.class, "demo.war") .addPackage(Demo.class.getPackage()) .addDescriptor(beansXml) .addDescriptor(persistenceXml); In the above, `.fromDefaultLocation()' will pluck the descriptor from the standard spot in the Maven source tree, and the .addDescriptor(...)' method will pass the archive type to an -impl descriptor method that returns the appropriate archive path for that descriptor in that archive type, eg /WEB-INF/beans.xml for a BeansDescriptor in a WebArchive, /WEB-INF/classes/META-INF/persistence.xml for a PersistneceDescriptor in a WebArchive, /META-INF/persistence.xml for a PersistenceArchive in a JavaArchive, etc. Because the location of beans.xml in the source tree varies based on the pom.xml <packaging/> directive, it might be necessary to integrate with the maven resolver plugin to get <packaging/> info from the pom, producing something like: MavenDependencyResolver mvn = DependencyResolvers.use(MavenDependencyResolver.class) .configureFrom("pom.xml"); BeansDescriptor beansXml = Descriptors.importAs(BeansDescriptor.class).byPom(mvn); PersistenceDescriptor persistenceXml = Descriptors.importAs(PersistenceDescriptor.class).byPom(mvn); ... or ...: MavenDependencyResolver mvn = DependencyResolvers.use(MavenDependencyResolver.class) .configureFrom("pom.xml"); BeansDescriptor beansXml = mvn.importDescriptor(BeansDescriptor.class); PersistenceDescriptor persistenceXml = mvn.importDescriptor(PersistenceDescriptor.class); Opinions? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

2
3
0 / 0

[JBoss JIRA] (SHRINKWRAP-397) ShrinkWrap fails to resolve artifact co-ordinate with version implicit from loaded pom

by Craig Ringer (JIRA)

Craig Ringer created SHRINKWRAP-397: --------------------------------------- Summary: ShrinkWrap fails to resolve artifact co-ordinate with version implicit from loaded pom Key: SHRINKWRAP-397 URL: https://issues.jboss.org/browse/SHRINKWRAP-397 Project: ShrinkWrap Issue Type: Bug Components: ext-resolver Environment: JBoss AS 7.1.1.Final java version "1.7.0_01" Java(TM) SE Runtime Environment (build 1.7.0_01-b08) Java HotSpot(TM) 64-Bit Server VM (build 21.1-b02, mixed mode) Linux ayaki.localdomain 3.3.0-4.fc16.x86_64 #1 SMP Tue Mar 20 18:05:40 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Reporter: Craig Ringer ShrinkWrap's Maven Dependency Resolver doesn't successfully resolve artifacts that're specified with an implicit version in their co-ordinates, even if that version can be determined from a loaded pom.xml . This forces duplication of version listings between tests and the project pom, leading to greater maintenance burden and the increased probability of tests not reflecting the real code that gets run. This: MavenDependencyResolver resolver = DependencyResolvers.use(MavenDependencyResolver.class) .configureFrom("pom.xml"); WebArchive war = ShrinkWrap.create(WebArchive.class, "demo.war") .addPackage(Demo.class.getPackage()) .addAsLibraries(resolver.artifacts("some-group:some-artifact:1.0.0.Final").resolveAsFiles()); should, if some-group:some-artifact is defined in pom.xml via a direct dependency, dependencyManagement section, parent pom, or a <type>import</type> pom in dependencyManagement, then it should be able to figure out the version without it being specified, eg: WebArchive war = ShrinkWrap.create(WebArchive.class, "demo.war") .addPackage(Demo.class.getPackage()) .addAsLibraries(resolver.artifacts("some-group:some-artifact").resolveAsFiles()); ... or even better, the artifact should be resolved from a class reference by looking up the artifact, so you can write something like the imaginary: WebArchive war = ShrinkWrap.create(WebArchive.class, "demo.war") .addPackage(Demo.class.getPackage()) .addAsLibraries(resolver.artifactsFromClasses(org.apache.commons.lang3.ObjectUtils.class).resolveAsFiles()); as suggested in https://issues.jboss.org/browse/ARQ-412 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

3
8
0 / 0

[JBoss JIRA] (SHRINKDESC-112) Update .gitignore

by Andrew Rubinger (JIRA)

Andrew Rubinger created SHRINKDESC-112: ------------------------------------------ Summary: Update .gitignore Key: SHRINKDESC-112 URL: https://issues.jboss.org/browse/SHRINKDESC-112 Project: ShrinkWrap Descriptors Issue Type: Task Reporter: Andrew Rubinger Assignee: Andrew Rubinger Fix For: 2.0.0-alpha-3 The following entries require clean, as they're missing from .gitignore: +api-javaee/src/ +api-misc/src/ +impl-jboss/src/main/java/ +impl-misc/src/main/java/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
1
0 / 0

[JBoss JIRA] (SHRINKDESC-111) Support XSD files without xsd namespace.

by Jérémie Lagarde (JIRA)

Jérémie Lagarde created SHRINKDESC-111: ------------------------------------------ Summary: Support XSD files without xsd namespace. Key: SHRINKDESC-111 URL: https://issues.jboss.org/browse/SHRINKDESC-111 Project: ShrinkWrap Descriptors Issue Type: Feature Request Components: metadata-parser Environment: Allow the parser to support xsd file without xsd namesapce like http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd. Reporter: Jérémie Lagarde -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

2
3
0 / 0

[JBoss JIRA] (SHRINKDESC-110) Support Portlet 2.0

by Jérémie Lagarde (JIRA)

Jérémie Lagarde created SHRINKDESC-110: ------------------------------------------ Summary: Support Portlet 2.0 Key: SHRINKDESC-110 URL: https://issues.jboss.org/browse/SHRINKDESC-110 Project: ShrinkWrap Descriptors Issue Type: Feature Request Components: api-javaee Reporter: Jérémie Lagarde It would be interesting to have a descriptor for portlet.xml files. See JSR 286: Portlet Specification 2.0 : http://jcp.org/en/jsr/detail?id=286 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

2
7
0 / 0

[JBoss JIRA] (SHRINKDESC-109) Descriptors export to much of it's dependency chain

by Aslak Knutsen (JIRA)

Aslak Knutsen created SHRINKDESC-109: ---------------------------------------- Summary: Descriptors export to much of it's dependency chain Key: SHRINKDESC-109 URL: https://issues.jboss.org/browse/SHRINKDESC-109 Project: ShrinkWrap Descriptors Issue Type: Feature Request Components: api, api-javaee, api-jboss, impl-base, impl-javaee Affects Versions: 2.0.0-alpha-1 Reporter: Aslak Knutsen Assignee: Aslak Knutsen Fix For: 2.0.0-alpha-2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

2
3
0 / 0

[JBoss JIRA] Created: (SHRINKWRAP-336) Provide addAsServiceProvider overload that supports "serviceInterface" as String

by Aslak Knutsen (JIRA)

Provide addAsServiceProvider overload that supports "serviceInterface" as String -------------------------------------------------------------------------------- Key: SHRINKWRAP-336 URL: https://issues.jboss.org/browse/SHRINKWRAP-336 Project: ShrinkWrap Issue Type: Feature Request Components: api Affects Versions: 1.0.0-beta-6 Reporter: Aslak Knutsen In some cases you want to package ServiceProviderInterfaces to might not be available/loadable at package time. This only work if CDI API is on client path {code} .addAsServiceProvider(Extension.class, CDIExtension.class); {code} A possible overload could be: {code} .addAsServiceProvider("javax.enterprise.inject.spi.Extension", "my.cdi.CDIExtension"); {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

6
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues April 2012