Flag incompatible features in server.xml

[cherylking]

When a user adds a feature to the server.xml, dev mode will automatically install it. If auto feature generation is enabled, it will also detect incompatible features. The language server should use that information from the Maven/Gradle plugin to flag any incompatible features that have been configured. Determine if there is any other way the language server could determine incompatible features for flagging.

This is a future enhancement that is not part of the MVP. Slide 22 of UFO.

[scottkurz]

So one idea here would be to call the Liberty runtime install features function, like the install-feature goal does today presumably.

Is it worth considering as an alternative an idea more like: "Look at the (cached, maximal) featurelist XML" and build a graph of "enables" (and "enabled by") relationships. In particular look for which of the umbrella features: "jakartaee-10.0", "microProfile-5.0" enable a given feature. Give a visual indicator (on hover?) which aggregate a given API feature is enabled by and give a warning if there seem to be conflicts (e.g. an EE 9 feature and an EE 10 feature).

Just looking at this should raise several questions... is it good to have a "shorthand" of "this is an EE 9 feature" when the runtime doesn't quite say exactly that. (What if a given feature like batch-2.1 doesn't have an update in EE 11 so it's part of both?).

What about OL vs WL? Does trying to use a cached feature list introduce all the issues of the cached XSD discussion (e..g beta vs ga as discussed here: #259 (comment) ).

Perhaps there is no better way than calling the runtime...

If not, though, I do wonder if there is still value in trying to display a shorthand EE platform version indicator (e.g. "EE10") of some form. Maybe it'd need to go in the metadata to get gen'd into the XSD. OK, that's enough for this comment.

[scottkurz]

UDPATE: DXDI 2024-01-17

One key point to understand is that with the completion of the generateFeatures function, to the point that it can be enabled by default, there will be less need for this type of thing.

There is a thought that we could invoke the binary scanner to help flag incompatible feature combinations, in a way that would be cheaper than the invocation of the Liberty runtime which we call when doing the liberty-maven-plugin 'install-feature' goal. It seems though that such an effort would be best undertaken after the next (final) stage of the generateFeatures work is complete.

In the meantime, it seems like we could take two shorter-term actions

1. Look more at adding more of the enables/enabled-by information and work on a prototype. Some of the issues are discussed in the last comment: Flag incompatible features in server.xml #70 (comment) e.g. the use of the cached vs. gen'd feature list XML. Use the prototype to further advance the discussion . Note this is also captured as: Consider providing listing of features enabled by a given feature, along with feature description in completion proposal. #164
2. Pursue the idea of adding a platform version to the runtime feature metadata, which would be generated into the XSD.

[cherylking]

Pursue the idea of adding a platform version to the runtime feature metadata, which would be generated into the XSD.

I think we have this info available now in the features.json with the versionless feature support that was added in 4Q2024. Each feature lists the platforms they are part of. For example, the cdi-1.2 feature has the following in the features.json:

"platforms": [
                "javaee-7.0"
]

Since we have a list of platforms for each feature, we can determine if the set of features have incompatible platforms. For example, if one feature is part of javaee-7.0 and another is only part of javaee-8.0, then those two features would be incompatible.

If they have used versionless features mixed with versioned features, this gets a little trickier. But the point is we have more info now to determine this incompatibility.

[arunvenmany-ibm]

Currently in case of version less feature, we have the below logic implemented

check for versionless feature version identification

1. if versionless feature is specified and no versioned feature or platform is specified, throw error

2. if versionless feature is specified and no platform is specified and atleast one versioned feature is specified

   • if no common platform is found for all versioned features, throw error
   • if there are more than one common platform, throw error
   • if common platform is found, then
     • find all required and required tolerates features for versionless feature
     • find all platforms for above features
     • check common platforms is present in feature platforms
     • throw error if not found

3. if versionless feature is specified and platform(s) is specified

   • find all required and required tolerates features for versionless feature
   • find all platforms for above features
   • check common platforms is present in feature platforms
   • throw error if not found

I think we can replicate the same from step 2 for versioned features
ie, if there are multiple versioned features specified and no versionless feature is specified

• Find all common platforms for specified features
  • If there is no common platform , throw incompatible features error
  • If there are more than one common platform, DO NOTHING ( is this correct ?)

If they have used versionless features mixed with versioned features, I think our current validations will throw version resolution issue. If the version resolution is success, this means the features are compatible, right?

[cherylking]

Find all common platforms for specified features
If there is no common platform , throw incompatible features error

This won't work. They can have versioned microProfile features and versioned jakarta features...they won't share a platform but they can both be specified.

What I am envisioning is making sure there is a common microProfile platform if any mp features are specified, and make sure there is a common jakarta/javaee platform if jarkarta/javaee features are specified. Then I am not sure if there is a way to know whether a microProfile platform is incompatible with certain jakarata/javaee platforms? Need to dive deeper on this.