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

[Yeray Borges Santana (Jira)]

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

Yeray Borges Santana commented on WFCORE-4621:
----------------------------------------------

Hi [~brian.stansberry],

My understanding is a static JBoss Modules module, instead of a dynamic one, with all its dependencies as optional, could work fine even if we are provisioning with {{passive+}} strategy. Galleon creates packages for the JBoss Modules to provision using the module.xml file, and when the dependencies are optional, the package created does not include them. That means a server with any kind of provisioning strategy won't provision the optional dependencies if they are not already included by any other package that could require them. 

Do you agree or am I missing something? 

If the above is correct, the approach could be then to create a static module.xml for a new module named {{wildflyee.api}}. This new module will have all its dependencies declared as {{optional}}. Replace the uses of the {{javaee.api}} module dependency in {{ExternalModuleSpecService}} by {{wildflyee.api}}. Make {{javaee.api}} in WildFly full become an alias of {{wildflyee.api}}. I understand we could have Jakarta EE APIs that could depend on other Jakarta EE APIs, but I understand it is assumable by the user using a slimmed server that does not contain all the Jakarta EE dependencies. Do you see any downside with this approach?

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