[shrinkwrap-issues] [JBoss JIRA] (SHRINKWRAP-399) Descriptors 2.0 module BeansDescriptor API mixes String and Alternatives<BeansDescriptor>, is hard to use

[Craig Ringer (JIRA)]

Craig Ringer created SHRINKWRAP-399:
---------------------------------------

             Summary: Descriptors 2.0 module BeansDescriptor API mixes String and Alternatives<BeansDescriptor>, is hard to use
                 Key: SHRINKWRAP-399
                 URL: https://issues.jboss.org/browse/SHRINKWRAP-399
             Project: ShrinkWrap
          Issue Type: Feature Request
          Components: ext-descriptors
    Affects Versions: 1.0.0
         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


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 at 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.

FWIW, I'm not a big fan of ".clazz" either. What does that *mean*? How about ".alternative(...)" or ".addAlternative(...)" or ".alternativeClass(...)" ? The method ".clazz(String)" doesn't tell the reader much.

--
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