[wildfly-dev] Subsystems to advertise implicit and optional dependencies to galleon

[Jean-Frederic Mesnil]

comments inlined

> On 09/11/2018 18:32, Brian Stansberry wrote:
>> 
>> The passive optional dependencies would be advertised with 
>> RuntimeCapability.addAdditionalPassiveOptionalPackages(optional 
>> dependency package name).
>> 
>> So to summarize:
>> 
>> - RuntimeCapability.addAdditionalRequiredPackages for all required 
>> implicit modules
>> 
>> - RuntimeCapability.addAdditionalRequiredPackages to associate optional 
>> dependencies to a feature
>> 
>> - RuntimeCapability.addAdditionalOptionalPackages for all optional 
>> implicit dependencies that are not passive
>> 
>> - RuntimeCapability.addAdditionalPassiveOptionalPackages for all 
>> optional dependencies (implicit or not) that are passive
>> 
>> A good question Alexey raised is whether the capability is the right concept for encapsulating this information.

The fact you have to create artificial capabilities to provide this information makes me think Alexey is right.

>> The alternative is to record this data in the ResourceDefinition, which is the primary source of the data that's used in the feature spec generation.

That’s a good idea. 
This would solve the logging issues where the resource that registers the DUP (i.e. the /subsystem=logging resource) will indicate the packages that are required for it.

The question is does storing them in ResourceDefinition is enough for all cases or do we have to able to keep them attached to a RuntimeCapability.

>> I don't think ResourceDefinition has this problem.
> I have introduced artificial capabilities in ee, jaxrs and weld (subsystems that are targeted by the demo) to add additional packages. It seems that it would be common case. So it is actually smelly.

We should also ensure that we do not introduce artificial resource definition to provide these packages information but that is unlikely.
(That reminds me how we used to create artificial subresources to store complex configuration that was only used by the parent resource).

>> Is it something that subsystems owner would be ready to put in place to 
>> help galleon in this task? It would require a bit of analysis of the 
>> dependencies of your modules but the gain could be quite important.

If we want to get buy in from the subsystem developer, we need:
* tools to analyzee the dependencies (you already wrote them)
* good documentation to explain to a subsystem developer what a optional/required/passive/implicit package means (maybe linking to Galleon from the Javadoc is enough but I am not sure…)


Good stuff, Jean-Francois :)

Thanks,
jeff

--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/