[wildfly-dev] Re: WildFly feature-packs, family, and criteria

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&gt; 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