-
Enhancement
-
Resolution: Done
-
Major
-
None
-
None
If the presence of a resource implies the requirement for a module that is otherwise optional, the ManagementResourceRegistration and thus the read-feature-description output should be able to note that fact.
This needs a bit of thought:
1) What data should be provided? Galleon package name? JBoss Modules module name? My guess is the former, as that is what is useful to the sole consumer of read-feature-description. Plus a dev team providing this data is going to end up needing to understand Galleon packages anyway. But I've only given it the amount of thought needed to type this paragraph.
2) Is simple presence/absence of a resource sufficient to control this. Any attribute involvement? (That is if foo==true, then we need package bar.) My instinct here again is attribute values are not relevant. This is conceptually related to capabilities – an attribute is not allowed to provide a capability; only a resource can. A module provides the code necessary for a capability so there's no reason for a module dependency exist independent of a capability and therefore solely due to an attribute.
Following from my discussion in 2) perhaps this data should be obtained from a Capability rather than from a ManagementResourceRegistration. The r-f-d handler is already reading capability data so it's not significantly harder for it to create output from that vs from the MRR.