[
https://issues.jboss.org/browse/CDI-150?page=com.atlassian.jira.plugin.sy...
]
Pete Muir updated CDI-150:
--------------------------
Fix Version/s: TBD
(was: 1.1 (Proposed))
Affects Version/s: 1.0
I'm slipping this to TBD as for CDI 1.1 we are still following the
"modularity" outlined by Java EE, which is dependent on Manifest's Classpath
and EAR structures.
Offer the ability to explicitly assemble an application from
component bean archives
------------------------------------------------------------------------------------
Key: CDI-150
URL:
https://issues.jboss.org/browse/CDI-150
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Packaging and Deployment
Affects Versions: 1.0
Reporter: Geoffrey De Smet
Fix For: TBD
See the problem described in this comment on CDI-87:
https://issues.jboss.org/browse/CDI-87?focusedCommentId=12626218
Solution proposal 1:
Every beans.xml gets an id:
{code}
<beans id="org.jboss.seam.solder">
...
</beans>
{code}
Then it's possible to depend on other beans.xml files:
{code}
<beans id="org.jboss.seam.security">
<dependency refid="org.jboss.seam.solder"/>
...
</beans>
{code}
So when guvnor depends on security, it can automatically, transitively inherit solder
(without depending on it directly):
{code}
<beans id="org.drools.guvnor">
<dependency refid="org.jboss.seam.security"/>
...
</beans>
{code}
So when guvnor upgrades to the next version of seam-security, it doesn't need to
worry if seam-security still uses seam-solder and whether or not it requires any new bean
sets (such as seam-international starting from seam-security 1.2).
--
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