[jboss-jira] [JBoss JIRA] (WFCORE-4621) Create a service to install a dynamic 'wildflyee.api' module

[Brian Stansberry (Jira)]

    [ https://issues.redhat.com/browse/WFCORE-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13986926#comment-13986926 ] 

Brian Stansberry commented on WFCORE-4621:
------------------------------------------

[~yersan] Per [1] passive+ pulls in optional dependencies but if there is some subtlety due to how packages are created for JBoss Modules modules, then that is fine, a static module can work. TBH since filing this I've sometimes felt what Galleon was doing wasn't matching what I expected for passive+ (i.e. it provisioned less than I expected, which was good) so probably what you describe is why that was the case.

As long as what you suggest works it is fine. And yes if a user slims the server but their app depends on an API they slimmed away, that is an error on their part.


[1] https://docs.wildfly.org/galleon/#_feature_pack_original_effective_package_set

> Create a service to install a dynamic 'wildflyee.api' module
> ------------------------------------------------------------
>
>                 Key: WFCORE-4621
>                 URL: https://issues.redhat.com/browse/WFCORE-4621
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Server
>            Reporter: Brian Stansberry
>            Assignee: Yeray Borges Santana
>            Priority: Minor
>
> Follow up on WFCORE-4612 by removing the list of detailed optional dependencies added there and instead have a service that installs a dynamic 'wildflyee.api' module that optional depends on all those. Then ExternalModuleDependencySpecService would add a dependency on that 'wildflyee.api' module.
> Then the next step is the javaee.api module in full WildFly would become an alias to wildflyee.api.
> The benefit to this is the content set for this 'ee.api' convenience module 
> a) gets set in one place (vs the two places that WFCORE-4612 introduces)
> b) is defined in core, which makes some sense as core utilizes the module for the ExternalModuleDependencySpecService use case.
> c) External uses of 'javaee.api' can benefit from the WFCORE-4612 improvement; i.e. if they have slimmed the server such that some APIs are not present, javaee.api can still be used. They just can't be using any APIs that they slimmed away. 
> A downside is maintaining an 'ee.api' modules is not a great fit for core.
> The reason to use a dynamic module is a static module would be visible to Galleon, and with the standard passive+[1] provisioning scheme we use that would lead to Galleon provisioning the packages for all the EE APIs, regardless of whether the server config required them.
> [1] https://docs.wildfly.org/galleon/#_effective_package_set
> This is somewhat me brainstorming, so needs harder thought.



--
This message was sent by Atlassian Jira
(v7.13.8#713008)