]
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.