Hi Jeff, thank-you for your questions! Reply inlined. On Wed, Oct 8, 2025 at 1:14 PM Jean-Frederic Mesnil <jmesnil(a)ibm.com&gt; wrote: Actually not. WildFly FP doesn't depend on the jakarta-ee10 criteria (at least in my example), it depends on the jakarta-ee criteria. A feature-pack can choose what are the criteria it needs from its dependencies. This would look like in the wildfly-feature-pack-build.xml (file to build feature packs). The syntax of the allows family is <family>+criterion[+criterion]: <dependency group-id="org.wildfly" artifact-id="wildfly-ee-galleon-pack" *allowedFamily="wildfly+jakarta-ee+deployment"*> Some other feature-packs that would be bound to EE 10 specific version would choose to depend on jakarta-ee10 criteria. Yes correct, that is an XOR. Yes that is correct in your provisioning.xml (or WIldFly Maven Plugin configuration) you would have (image WF 39.0.0.Final): <feature-pack location="org.wildfly:wildfly-ee-10-feature-pack:39.0.0.Final"/> <feature-pack location="org.wildfly:wildfly-galleon-pack:39.0.0.Final"/>

On Wed, Oct 8, 2025 at 3:27 PM Jean-Frederic Mesnil <jmesnil(a)ibm.com&gt; wrote: Yes, if that was not the case, the dependency used at build time would leak into the child's exposed criteria. I like it. Good suggestion! I am not at all proposing real criteria nor feature-pack names (although I hope they make sense). If WildFly project decides to use this approach, an interesting work will be needed to identify criteria and new feature-pack names.

Hi Yeray, thank-you for your questions. I inlined my reply. On Thu, Oct 9, 2025 at 12:25 PM Yeray Borges Santana <yborgess(a)redhat.com&gt; wrote: I used WildFly core feature-pack not for the EE 10 vs EE 11 use-case, but for the general case of depending on some criteria that could apply to all feature-packs (even an extreme case like the WildFly core feature-pack). The "deployment" criteria is an abstraction to identify a particular feature of any WildFly server and a good one to illustrate the idea. How WildFly core feature-pack content is going to be integrated in the future is outside of this proposal, you are correct. I am not proposing at all that we re-introduce the WildFly core feature-pack in the dependency tree. I am not sure that WildFly core use case goes beyond the "transformer" example. Having alternate feature-packs for core (as we have for WildFly EE10 vs EE11 and Wildfly vs WildFly Preview) doesn't seem a realistic use-case. But actually I could see a usage (raw thinking): Imagine we have 2 modules, one for EE10 and one for EE11 in Wildfly-core. WildFly copies them to build each of its wildfly ee feature-packs. Perhaps we could have 2 wildfly core feature-packs to run the core testsuite with ee10 API or EE 11 API. Those 2 feature-packs could be in the wildfly family, with each a specific criteria (not jakarta-eeX because they are not compliant with the spec but something that captures that "subset-ee10", "subset-ee11" and both have the criteria "deployment" and "subset-ee"). Then, the wildfly-core-testsuite-unstable-api-annotation-feature-pack (a feature-pack developed in the testsuite) that depends today on the core feature-pack, could express that it requires a member of wildfly:subset-ee. Doing so the wildfly-core-testsuite-unstable-api-annotation-feature-pack could be provisioned with the ee10 or ee11 core feature-pack. This makes me think that WildFly (that also has some test feature-packs) could follow the same pattern.

During today's WildFly community call we discussed the topic, here are the slides <https://docs.google.com/presentation/d/1Adb5HRDRxFHvm8P3rfz53gwavO6PRTQBX... . I demonstrated using WildFly Glow with local changes. One action item has been to provide some details on the notion of WildFly variant. Here is a description <https://docs.google.com/document/d/12SsS6eheFTJXqO8crlENACw0cQaXLuORmM81C... (Google doc that you can comment) on how that is working (WildFly Glow metadata and command line options). Thank-you. JF *From: *Brian Stansberry <bstansbe(a)redhat.com&gt; *Date: *Thursday, 9 October 2025 at 16:48 *To: *Jean Francois Denise <jdenise(a)redhat.com&gt; *Cc: *Yeray Borges Santana <yborgess(a)redhat.com&gt;, Brian Stansberry via wildfly-dev <wildfly-dev(a)lists.jboss.org&gt; *Subject: *Re: [wildfly-dev] Re: WildFly feature-packs, family, and criteria Sent from Outlook for Mac On Thu, Oct 9, 2025 at 6:37 AM Jean Francois Denise via wildfly-dev < wildfly-dev(a)lists.jboss.org&gt; wrote: Hi Yeray, thank-you for your questions. I inlined my reply. On Thu, Oct 9, 2025 at 12:25 PM Yeray Borges Santana <yborgess(a)redhat.com&gt; wrote: On Wed, Oct 8, 2025 at 10:52 AM jdenise--- via wildfly-dev < wildfly-dev(a)lists.jboss.org&gt; wrote: WildFly feature-packs, family, and criteria Summary Introduce the notion of family and criterion to remove the static dependencies that exist between feature-packs. Problem Today, when developing feature-packs that depend on WildFly feature-packs, we are bound to use exact instances (mainly identified by Maven Coordinates) of feature-packs. At provisioning time, the same dependencies must be present in the provisioning configuration (with possible different versions). This is not flexible, the same feature-pack can’t depend on a set of feature-packs that would offer the same functionalities. You need to define multiple feature-packs (even if they are identical) just to handle the dependencies. That doesn’t scale. In particular in a context where we would like to see WildFly support multiple versions of a specification (e.g.: Jakarta EE 10 and Jakarta EE 11). We should be able to say that we want WildFly with EE10 in one provisioning configuration and WildFly with EE11 in another provisioning configuration. WIldFly feature-pack should be the same and not bound to a specific dependency. This applies also to other feature-packs (datasources, cloud, …) that should work, if applicable, with any combinations. Another example that highlights the problem is defining a feature-pack that would apply indifferently to WildFly core feature-pack (used in test suite), WIldFly EE, WildFly and WildFly Preview. The “Deployment transformer" use case (a feature-pack that would provision what is needed to transform in a custom way some deployments). This feature-pack doesn’t care about the specific feature-pack it is provisioned with. It just needs that the WildFly deployment server feature be present. Family and Criteria This notion of server feature is key. A feature-pack should express the set of server features it is implementing. Other feature-packs should be able to express that they depend on a feature-pack that provides a set of server features (criteria). Let’s group all the feature-packs that WildFly defines in the “wildly” family. Each feature-pack becomes a member of this family. The members of a family are exposing criteria (the server features) that can be unique to a member or shared by multiple members. In addition, members can inherit from other members, so some criteria can be implemented locally or inherited. WildFly family criteria An example of criteria (that should be enough to help understand this new feature) we can find today in the wildly family (non-exhaustive): * `deployment`: ability to deploy an application * `jakarta-ee`: An implementation of the Jakarta EE spec * `jakarta-ee10`: A specific implementation of the Jakarta EE version 10 * `microprofile`: An implementation of the MicroProfile spec * `microprofile-7.1`: A specific implementation of the MicroProfile spec version 7.1. * `jakarta-ee11`: A specific implementation of the Jakarta EE version 11 Let’s dispatch the criteria in each WildFly feature-pack: * WildFly core feature-pack: deployment The WildFly Core feature-pack currently also contains jakarta ee 10 APIs: https://github.com/wildfly/wildfly-core/blob/7e0f65ca8604c27874d7b5d8a4c9... I think that, when we will have 2 featurepacks, we will have to deal with it (perhaps wildfly-core will be migrated to 11, and the WildFly EE feature-pack will override with EE 10 artifacts). That seems to me an implementation detail on how the WildFly EE feature-pack is implemented. So, I'm not sure what you wanted to mean here with "deployment" criteria, to me, any uses of this feature pack via standard feature pack inheritance would bring the jakarta ee apis. So I guess the plan here is to also split the WildFly Core Feature pack into specialized criteria. I used WildFly core feature-pack not for the EE 10 vs EE 11 use-case, but for the general case of depending on some criteria that could apply to all feature-packs (even an extreme case like the WildFly core feature-pack). The "deployment" criteria is an abstraction to identify a particular feature of any WildFly server and a good one to illustrate the idea. However, as far as I understand, we have never depended on the WildFly Core Feature pack as a dependency; instead, what we have been doing is picking up the relevant modules exposed by WildFly Core as pieces to compose the other feature packs, for example, here we are composing the preview feature pack from pieces taken from the WildFly Core Feature: https://github.com/wildfly/wildfly/blob/79731e843d4d96e1f7aac33d3bcd18be0... Which, indeed, has its own issues for a server built from a manifest, since the feature pack that incorporates those resources needs to be rebuilt at compiling time in order to incorporate any resource from a dependency updated in the manifest. I also wonder if this new concept of family and inheritance would also be affected by this. If the plan is to continue doing the same, I mean composing by pieces, maybe the WildFly Core feature pack can be completely out of the equation, and assume that the other feature packs will use the pieces to compose whatever they need. However, we would also want to fix the problem when a manifest updates the dependencies. This is a different topic, though, but something we should keep in mind with the new way of composing feature packs. I guess we would need Galleon tasks to unzip the resources at provisioning time, but nto sure about it, anyway, off-topic. How WildFly core feature-pack content is going to be integrated in the future is outside of this proposal, you are correct. I am not proposing at all that we re-introduce the WildFly core feature-pack in the dependency tree. +1 The wildfly-core feature pack only exists to serve as a test fixture for the WildFly Core testsuite. We should not change that. It's useful to talk about it in this kind of discussion because it's an example of a theoretical FP that only provides the 'deployment' criteria. If we get to actual implementation and we find we have to include it in a family or something, i.e. something that makes it more visible to end users, then we need to be careful to not somehow imply an expansion of its supported use case. For example, perhaps we could simply change the core build so it no longer deploys the FP or core's build and dist, making them only useful for testsuite execution. The maven modules themselves could perhaps go to the testsuite/ tree. What would be the plans for the WildFly Core feature pack so it can be used in this approach? Do we still plan to use it as a box where we can get specific resources to compose other feature packs, or do we want to switch it and use standard galleon inheritance instead? I am not sure that WildFly core use case goes beyond the "transformer" example. Having alternate feature-packs for core (as we have for WildFly EE10 vs EE11 and Wildfly vs WildFly Preview) doesn't seem a realistic use-case. But actually I could see a usage (raw thinking): Imagine we have 2 modules, one for EE10 and one for EE11 in Wildfly-core. WildFly copies them to build each of its wildfly ee feature-packs. Perhaps we could have 2 wildfly core feature-packs to run the core testsuite with ee10 API or EE 11 API. Those 2 feature-packs could be in the wildfly family, with each a specific criteria (not jakarta-eeX because they are not compliant with the spec but something that captures that "subset-ee10", "subset-ee11" and both have the criteria "deployment" and "subset-ee"). Then, the wildfly-core-testsuite-unstable-api-annotation-feature-pack (a feature-pack developed in the testsuite) that depends today on the core feature-pack, could express that it requires a member of wildfly:subset-ee. Doing so the wildfly-core-testsuite-unstable-api-annotation-feature-pack could be provisioned with the ee10 or ee11 core feature-pack. This makes me think that WildFly (that also has some test feature-packs) could follow the same pattern. These are interesting use cases. I think the key thing is to make sure that whatever definitions we come up with for these "internal testing only scenarios" don't escape out into "the wild" and become something end users deal with / misuse. Note: When I am talking about standard Galleon inheritance, I'm talking about how, for example, the WildFly Feature packs inherit from the WildFly EE feature pack: https://github.com/wildfly/wildfly/blob/46bb1090d7b18777eacbf5a01192c9acb... * WildFly ee feature-pack: deployment, jakarta-ee, jakarta-ee10 * WildFly feature-pack: microprofile, microprofile-7.1 * WildFly preview feature-pack: deployment, jakarta-ee, jakarta-ee11, microprofile, microprofile-7.1 Now let's handle the inheritance that exists today between some feature-packs. WildFly feature-pack depends on WildFly ee feature-pack. From the list of examples criteria, it depends on this feature-pack to use: `jakarta-ee` and ` deployment`. So, the dependency on WildFly ee should be limited to such criteria. 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* * 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 NOTE: One benefit is that we can, at provisioning time, check that at most one member is bringing a given criterion. If we have 2 members that implement locally (not via inheritance) a criterion, it means that we have a duplicate and a member needs to be removed (e.g.: explicit provisioning of WildFly core + WildFly EE or WildFly Preview + WildFly EE should be detected and aborted, today an unexpected state is created, hard to debug). 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). NOTE: WildFly feature-pack would possibly need other criteria to limit to a minimum version of Jakarta EE specification (e.g.: minimum EE 10). Such criterion could be implemented by the two WildFly EE feature-packs and become an expected criterion for the dependency. Conclusion Provisioning time would become flexible with less feature-packs defined. It would allow to leverage feature-pack functionalities in different context. In this first step we can see criteria as “labels”, trusting the feature-pack developer that the criteria are actually full-filled. In the future this could be constrained by introducing formal feature-pack spec (or exposed API) that would capture what a criterion should contain (Galleon layers, Galleon packages, Galleon features). This feature would be backward compatible at provisioning time. The family/criteria notion would be handled internally and not exposed. It would impact Galleon, WildFly Galleon Plugins and all the other feature-packs that depend on WildFly. That is food for thought for now, in a near future I plan to create JIRAs and a WildFly proposal for it. Feedback welcome. Thank-you. JF Denise _______________________________________________ wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org Privacy Statement: https://www.redhat.com/en/about/privacy-policy List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... _______________________________________________ wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org Privacy Statement: https://www.redhat.com/en/about/privacy-policy List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... -- Brian Stansberry Architect, JBoss EAP WildFly Project Lead He/Him/His