Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flag incompatible features in server.xml #70

Open
cherylking opened this issue Jun 10, 2022 · 2 comments
Open

Flag incompatible features in server.xml #70

cherylking opened this issue Jun 10, 2022 · 2 comments
Labels
enhancement New feature or request high priority LemMinX Liberty extension to Eclipse Lemminx

Comments

@cherylking
Copy link
Member

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.

@cherylking cherylking added the enhancement New feature or request label Jun 10, 2022
@evie-lau evie-lau added the LemMinX Liberty extension to Eclipse Lemminx label Aug 24, 2022
@scottkurz
Copy link
Member

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request high priority LemMinX Liberty extension to Eclipse Lemminx
Projects
None yet
Development

No branches or pull requests

3 participants