Improve the xxCompatible feature handling

[tevans78]

The special case code in FeatureManager for handling conflicts between EE Compatible features should be improved. https://github.com/OpenLiberty/open-liberty/blob/dbbb2e0c9ea42f43b580f2758ca7d38f0b88ed71/dev/com.ibm.ws.kernel.feature.core/src/com/ibm/ws/kernel/feature/internal/FeatureManager.java#L1726

• It should be more generic and less special case
• It should be easily extendable to other Programming Models such as MicroProfile (https://github.com/OpenLiberty/open-liberty/issues/14219)
• It would be nice if we didn't need additional private features. A new feature header would be better.

[tjwatson]

• It would be nice if we didn't need additional private features. A new feature header would be better.

I'm not sure what you had in mind here. The private eeCompatible feature was introduced because features were renamed and the private eeCompatible feature was the solution to cause the conflict across the renamed features. I assumed MicroProfile is in the same boat. If so a private feature like eeCompatible is necessary.

Proposal to solve this generally.

• Add a new meta-data to features like eeCompatible that indicates it is a programming model "compatibility" type feature.
• The new meta-data should give the compatibility check name (e.g. Java EE, Jakarta EE, Micro Profile) and version (e.g. 6, 7, 8, 9)

With this additional information we can generally treat any feature like we do the eeCompatible features. One suggested header would be:

WLP-CompatibleName: <name> ; version=<version>

[tjwatson]

While generalizing the solution we also need to consider the eeCompatible specific code in #13936

Perhaps we no longer need this, but if we do it makes it difficult to depend on feature meta-data to figure out if the required feature is one of these "compatible" features because we don't have the required feature meta-data at this point.

[tevans78]

I thought you were suggesting adding the WLP-CompatibleName header to the "parent" features instead of adding the dependency on the slightly artificial xxCompatible private features. I realise that this would probably be more effort and may not be any simpler.

[tjwatson]

We need the private compatible feature to force the conflict if we are going to do the renames of features. If we are not doing renames of features then the original singleton names would cause the conflict, reducing the need for the compatible features. That would get us back to the behavior of all previous versions of Micro Profile.