[jboss-jira] [JBoss JIRA] (WFCORE-4621) Create a 'wildflyee.api' module to serve the Jakarta EE APIs to external modules

[Yeray Borges Santana (Jira)]

     [ https://issues.redhat.com/browse/WFCORE-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yeray Borges Santana updated WFCORE-4621:
-----------------------------------------
    Summary: Create a 'wildflyee.api' module to serve the Jakarta EE APIs to external modules  (was: Create a service to install a dynamic 'wildflyee.api' module)


> Create a 'wildflyee.api' module to serve the Jakarta EE APIs to external modules
> --------------------------------------------------------------------------------
>
>                 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)