search

OpenLiberty / liberty-language-server

The Liberty Config Language Server provides language server features for Liberty server configuration files through any of the supported client IDEs.
Eclipse Public License 2.0
5 stars 10 forks source link

Flag incompatible features in server.xml #70

Open cherylking opened 2 years ago

cherylking commented 2 years ago

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 commented 6 months ago

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: https://github.com/OpenLiberty/liberty-language-server/issues/259#issuecomment-1889551015 ).

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 commented 6 months ago

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: https://github.com/OpenLiberty/liberty-language-server/issues/70#issuecomment-1889953352 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: https://github.com/OpenLiberty/liberty-language-server/issues/164
  2. Pursue the idea of adding a platform version to the runtime feature metadata, which would be generated into the XSD.