February 2013 - shrinkwrap-issues

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

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-30?page=com.atlassian.jira.plug... ] Andrew Rubinger commented on SHRINKRES-30: ------------------------------------------ Create a test case for this using the 2.0.0-X API and ensure the global exclusions are working as expected. > ShrinkWrap should be able to exclude its own and Arquillian's -impl archives > ---------------------------------------------------------------------------- > > Key: SHRINKRES-30 > URL: https://issues.jboss.org/browse/SHRINKRES-30 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > 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 > Labels: arquillian, dependency, maven, resolver, shrinkwrap > > 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: > {code} > MavenDependencyResolver resolver = DependencyResolvers.use(MavenDependencyResolver.class) > .includeDependenciesFromPom("pom.xml"); > .excludeShrinkWrap().excludeArquillian(); // Imaginary for now > {code} > Currently one should be able to do something like: > {code} > 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"); > {code} > ... but in my quick tests these exclusions appeared to have no effect. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKRES-77) Align functionality from MavenResolutionFilter with Aether DependencyFilter

by Andrew Rubinger (JIRA)

[ https://issues.jboss.org/browse/SHRINKRES-77?page=com.atlassian.jira.plug... ] Andrew Rubinger commented on SHRINKRES-77: ------------------------------------------ Enhancement, does not require API change. Therefore does not block 2.0.0-beta. > Align functionality from MavenResolutionFilter with Aether DependencyFilter > --------------------------------------------------------------------------- > > Key: SHRINKRES-77 > URL: https://issues.jboss.org/browse/SHRINKRES-77 > Project: ShrinkWrap Resolvers > Issue Type: Feature Request > Components: api-maven > Affects Versions: 2.0.0-alpha-4 > Reporter: Karel Piwko > Assignee: Andrew Rubinger > Labels: api-change > > Aether is able to filter based on path to the parent of dependency resolution. This is handy in order to create a filter which could filter based on level-nesting of the dependency itself, which is useful for lazy loading dependencies. > We need to be able to pass List<DependencyNode> parents equivalent to the filter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-30) Create descriptor for server.xml (JBoss AS 5/6)

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-30?page=com.atlassian.jira.plu... ] Michal Matloka updated SHRINKDESC-30: ------------------------------------- Labels: new-descriptor (was: ) > Create descriptor for server.xml (JBoss AS 5/6) > ----------------------------------------------- > > Key: SHRINKDESC-30 > URL: https://issues.jboss.org/browse/SHRINKDESC-30 > Project: ShrinkWrap Descriptors > Issue Type: Feature Request > Affects Versions: 0.1.0 > Reporter: Karel Piwko > Labels: new-descriptor > > It could be handy to have ability to modify server.xml before a managed JBoss AS instance is started. > E.g. adding an SSL connector with trust store on port 8443. This will enable to move another configuration layer to Arquillian/ShrinkWrap project. > Consider having this descriptor for other containers as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-34) Create jboss-beans.xml Descriptor

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-34?page=com.atlassian.jira.plu... ] Michal Matloka updated SHRINKDESC-34: ------------------------------------- Labels: new-descriptor (was: ) > Create jboss-beans.xml Descriptor > --------------------------------- > > Key: SHRINKDESC-34 > URL: https://issues.jboss.org/browse/SHRINKDESC-34 > Project: ShrinkWrap Descriptors > Issue Type: Feature Request > Reporter: Andrew Rubinger > Labels: new-descriptor > > To be used for MC-based services, and likely eventually MSC as well. > Follows schema: > https://svn.jboss.org/repos/jbossas/projects/kernel/trunk/kernel/src/main... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-35) HornetQ Descriptors plugin

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-35?page=com.atlassian.jira.plu... ] Michal Matloka updated SHRINKDESC-35: ------------------------------------- Labels: hornetq new-descriptor (was: hornetq) > HornetQ Descriptors plugin > -------------------------- > > Key: SHRINKDESC-35 > URL: https://issues.jboss.org/browse/SHRINKDESC-35 > Project: ShrinkWrap Descriptors > Issue Type: Feature Request > Reporter: Carlo de Wolf > Labels: hornetq, new-descriptor > > Allow for the creation of *-hornetq-jms.xml via Descriptors. > http://hornetq.sourceforge.net/docs/hornetq-2.1.2.Final/user-manual/en/ht... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-98) Create a Descriptor for Jetty Environment configuration

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-98?page=com.atlassian.jira.plu... ] Michal Matloka updated SHRINKDESC-98: ------------------------------------- Labels: new-descriptor (was: ) > Create a Descriptor for Jetty Environment configuration > ------------------------------------------------------- > > Key: SHRINKDESC-98 > URL: https://issues.jboss.org/browse/SHRINKDESC-98 > Project: ShrinkWrap Descriptors > Issue Type: Feature Request > Reporter: Aslak Knutsen > Assignee: Ralf Battenfeld > Labels: new-descriptor > > jetty 7: http://www.eclipse.org/jetty/configure.dtd > jetty 6: http://jetty.mortbay.org/configure.dtd -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-126) JavaDoc incorrect for parameters

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-126?page=com.atlassian.jira.pl... ] Michal Matloka reassigned SHRINKDESC-126: ----------------------------------------- Assignee: Michal Matloka (was: Ralf Battenfeld) > JavaDoc incorrect for parameters > -------------------------------- > > Key: SHRINKDESC-126 > URL: https://issues.jboss.org/browse/SHRINKDESC-126 > Project: ShrinkWrap Descriptors > Issue Type: Bug > Components: metadata-parser > Affects Versions: 2.0.0-alpha-3 > Reporter: Jesper Pedersen > Assignee: Michal Matloka > Fix For: 2.0.0-alpha-5 > > > The generated .java files from the metadata-parser gives: > {noformat} > [javadoc] /xyz/build/embedded/src/main/java/org/jboss/jca/embedded/dsl/datasources11/impl/ConfigPropertyTypeImpl.java:58: warning - @param argument "configPropertyType" is not a parameter name. > {noformat} > for > {noformat} > /** > * Sets the body text for the element <code>config-propertyType</code> > * @param configPropertyType the value for the body text <code>config-propertyType</code> > * @return the current instance of <code>ConfigPropertyType<T></code> > */ > public ConfigPropertyType<T> text(String value) > { > childNode.text(value); > return this; > } > {noformat} > It should be 'value' instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-116) Descriptors 2.0 module BeansDescriptor API: common operations difficult, API confusing

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-116?page=com.atlassian.jira.pl... ] Michal Matloka reassigned SHRINKDESC-116: ----------------------------------------- Assignee: Michal Matloka (was: Ralf Battenfeld) > Descriptors 2.0 module BeansDescriptor API: common operations difficult, API confusing > -------------------------------------------------------------------------------------- > > Key: SHRINKDESC-116 > URL: https://issues.jboss.org/browse/SHRINKDESC-116 > Project: ShrinkWrap Descriptors > Issue Type: Feature Request > Environment: 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 > Assignee: Michal Matloka > Labels: alternative, arquillian, beans, beans.xml, descriptors, shrinkwrap > > The API for BeansDescriptor in the Descriptors 2.0 module (org.jboss.shrinkwrap.descriptors:shrinkwrap-descriptors-impl-javaee:jar:2.0.0-alpha-2) is confusing and hard to use for simple cases. It needs revision. > The distinction between BeansDescriptor.createAlternatives() and BeansDescriptor.getOrCreateAlternatives() isn't clear. Does the former unconditionally replace any existing alternatives entry? > There's no obvious .replace(oldBean, newBean) to swap alternatives. The descriptor needs simple methods for: > - Removing an alternative > - Replacing an alternative > - Adding an alternative > It almost appears that the descriptor module is trying to handle multiple <alternatives/> entries, if that's the purpose of BeansDescriptor.getAllAlternatives(). Weld doesn't permit multiple alternatives, as a test with multiple alternatives entries will show: > org.jboss.weld.exceptions.DefinitionException: WELD-001203 <alternatives> can only be specified once, but appears multiple times: vfs:/content/demo.jar/META-INF/beans.xml@6 > ... and as far as I can tell the beans.xml xsd backs that up: http://java.sun.com/xml/ns/javaee/beans_1_0.xsd > It doesn't make sense for the descriptors module to produce invalid descriptors; someone testing Weld code, JBoss descriptor loading, etc would use hand-crafted descriptors or descriptors produced using the XML APIs, not something like shrinkwrap descriptors. It really only needs to handle well-formed descriptors and should handle common tasks quickly and easily. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SHRINKDESC-113) Move DescriptorNamespace out of the Public API

by Michal Matloka (JIRA)

[ https://issues.jboss.org/browse/SHRINKDESC-113?page=com.atlassian.jira.pl... ] Michal Matloka updated SHRINKDESC-113: -------------------------------------- Assignee: Michal Matloka (was: Andrew Rubinger) > Move DescriptorNamespace out of the Public API > ---------------------------------------------- > > Key: SHRINKDESC-113 > URL: https://issues.jboss.org/browse/SHRINKDESC-113 > Project: ShrinkWrap Descriptors > Issue Type: Task > Reporter: Andrew Rubinger > Assignee: Michal Matloka > > This needs some discussion before being done. It'd break backwards-compatibility with the 1.x series. > DescriptorNamespace is mutable, which conflicts with the goals outlined in SHRINKDESC-21. We're not really testing its direct usage at the moment, and I wonder what reason end-users would have to be invoking its operations to muck around with the "namespace" of a domain object. Currently all descriptors are supporting its operations by extension: > {code}public interface WebAppDescriptor extends Descriptor, DescriptorNamespace<WebAppDescriptor>{code} > ...and the methods in question as defined by DescriptorNamespace are: > {code} > public T addDefaultNamespaces(); > public T addNamespace(String name, String value); > public List<String> getNamespaces(); > public T removeAllNamespaces();{code} > Note that Ralf's work in SHRINKDESC-21 also splits this into DescriptorNamespace and DescriptorMutableNamespace. > My feeling is that neither should be part of the API; maybe SPI or just internals. > Discuss if it's appropriate to remove this and break the backwards-compatibility with the 1.x series. In this case, I'm willing to entertain this exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

shrinkwrap-issues February 2013