6:14 a.m.
Hi Jean-Francois,
There is a lot to unpack in this mail but I’ve a few questions below to make sure I
understand the problem and your solution.
On 8 Oct 2025, at 11:51, jdenise--- via wildfly-dev <wildfly-dev(a)lists.jboss.org>
wrote:
Inheritance makes parent criteria on which a child depend to be also exposed by the child
(as inherited but that is an implementation detail). So, the criteria exposed by each
feature-pack becomes, after inheritance:
* WildFly core feature-pack: deployment
* WildFly ee feature-pack: deployment, jakarta-ee, jakarta-ee10
* WildFly feature-pack: microprofile, microprofile-7.1, deployment, jakarta-ee
^^ should also inherit (and expose) jakarta-ee10, right?
* WildFly preview feature-pack: deployment, jakarta-ee, jakarta-ee11, microprofile,
microprofile-7.1
Flexible dependency and provisioning
Now that we have our feature-pack exposing criteria, we can define feature-packs that
depend on the feature-packs of the WildFly family:
*
The WildFly datasources feature-pack (that adds datasources and JDBC drivers) requires
`jakarta-ee` from the `wildfly` family.
*
The WildFly cloud feature-pack (that configure a complete wildly for the cloud) requires
`jakarta-ee` and `microprofile` from the `wildfly` family.
*
The WildFly transformer feature-pack requires `deployment` from the `wildfly` family.
With that in place, we can now mix the feature-packs. At provisioning time resolution of
family and criteria allows to identify the actual dependencies in use and to bind to:
*
(WildFly || WildFly EE || WildFly Preview) + WildFly datasources feature-pack
*
(WildFly || WildFly Preview) + WildFly cloud feature-pack
*
(WildFly || WildFly EE || WildFly Core || WildFly Preview) + WildFly transformer
feature-pack
The notation is not clear. || actually means XOR as only one of the elements can bring the
criteria required by dependents feature packs. Is that correct?
Advanced example with hypothetical support for Jakarta EE 11
For version X of WildFly, Jakarta EE 11 should become the default implementation. A new
feature-pack for Jakarta EE 10 could be defined allowing to keep using WildFly with
Jakarta EE 10 for some time. WildFly Preview would start to support Jakarta EE 12 (I am
not modifying the microprofile version there although I suspect that it would change).
New criteria that appear (and none would been removed, but we can expect some criteria to
be removed for new WildFly releases):
*
`jakarta-ee11`: A specific implementation of the Jakarta EE version 11
*
`jakarta-ee12`: A specific implementation of the Jakarta EE version 12
The new set of feature-packs and mapping of criteria:
* WildFly core feature-pack: deployment
* WildFly ee feature-pack: deployment, jakarta-ee, jakarta-ee11
* WildFly ee 10 feature-pack: deployment, jakarta-ee, jakarta-ee10
* WildFly feature-pack: microprofile, microprofile-7.1
* WildFly preview feature-pack: deployment, jakarta-ee, jakarta-ee12, microprofile,
microprofile-7.1
We can see that both WildFly ee feature-pack and WildFly ee 10 feature-pack share the
jakarta-ee criterion that is all that WildFly needs. So, one of the two feature-packs can
be provisioned with WildFly feature-pack (same applies to other feature-packs).
Let’s say I’m using WildFly feature pack (with MicroProfile 7.1 & EE 10), what can I
provision when I want to stick with EE 10 when WildFly moves to EE 11?
I will continue to depend on WildFly feature pack (for MP 7.1 capabilities) and will
explicitly provision the new WildFly EE10 feature pack.
Is that correct?
Cheers,
Jeff
--
Jeff Mesnil
Software Engineer
Red Hat JBoss EAP
http://jmesnil.net/
IBM
Unless otherwise stated above:
Compagnie IBM France
Siège Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex
RCS Nanterre 552 118 465
Forme Sociale : S.A.S.
Capital Social : 664 614 175,50 €
SIRET : 552 118 465 03644 - Code NAF 6203Z