Consider providing listing of features enabled by a given feature, along with feature description in completion proposal.

[scottkurz]

UPDATE

Originally I wrote this up as a feature to add to completion proposals (Ctrl+Space).

I've since tacked on the ability to see this info during a hover.

Noting WDT offers this view:

Some NOTES

• Could we either duplicate the info built into the OL runtime docs, or even build it in an automated fashion?

• Would someone then ask to be able to click two levels down, i.e. what features do those enabled features themselves enable?

• Would there be any value in having a clickable link to the anchor of the corresponding feature's "Features that this feature enables" section, e.g. https://openliberty.io/docs/latest/reference/feature/jsonb-2.0.html#_features_that_enable_this_feature ? (This would maybe bump up against the issue in LT Eclipse now getting an HTML rendering of the proposal description: It is better to have an empty line between description and code eclipse-lsp4e/lsp4e#317).

[cherylking]

I thought this info might be in the features.json that is downloaded/cached, but here is what I see for the pages-3.0 feature:

"links": [
                {
                    "label": "Features that this feature enables",
                    "linkLabelProperty": "name",
                    "query": [
                        "wlpInformation.provideFeature=io.openliberty.servlet.api-5.0&wlpInformation.appliesToFilterInfo.minVersion.value=22.0.0.12&type=com.ibm.websphere.Feature",
                        "wlpInformation.provideFeature=io.openliberty.jakarta.expressionLanguage-4.0&wlpInformation.appliesToFilterInfo.minVersion.value=22.0.0.12&type=com.ibm.websphere.Feature",
                        "wlpInformation.provideFeature=com.ibm.websphere.appserver.eeCompatible-9.0&wlpInformation.appliesToFilterInfo.minVersion.value=22.0.0.12&type=com.ibm.websphere.Feature"
                    ]
                },
                {
                    "label": "Features that enable this feature",
                    "linkLabelProperty": "name",
                    "query": [
                        "wlpInformation.requireFeature=io.openliberty.jakarta.pages-3.0&wlpInformation.appliesToFilterInfo.minVersion.value=22.0.0.12&type=com.ibm.websphere.Feature"
                    ]
                },

I'm not sure how those query values are supposed to be used.

[turkeylurkey]

It would be valuable to see the complete list of features enabled by all the features already specified. A consolidation of the values you may see by hovering over each feature individually. Presumably when A -> B -> C then the list of features for A would be B and C so you should not need to go more than one level.

How that would look in the UI I'm not sure. Perhaps you hover over to see the list or maybe you select a group of s and the hover info lists the features enabled by that group.

[scottkurz]

Thinking outside the box a bit.. if the description in the feature metadata were enhanced to say what platform version a feature was first introduced, would this provide 60 or 80% of the value here? E.g. if I hovered over jpa-2.2 and saw that this was first introduced in EE 8, I could myself more quickly avoid feature conflicts due to mismatched platform versions. This would require a runtime DI and discussion....and maybe already was decided against for all I know. Just an idea.

Of course there are more complicated cases like suppose there were a spec that didn't get updated in EE 10.. if I saw "first introduced in EE 9" I might wrongly conclude that this is incompatible w/ EE 10 features though it wouldn't be. ( IDK if this situation exists even.)

[cherylking]

Now that we cache and generate a feature list xml file, it contains all the data we need to display a list of enabled by and enables for features. I will prototype the display of that data for hover over a feature and add some images here to show what it looks like.

[cherylking]

Added "Enabled by:" and "Enables:" to the hover description. If there are no features to display for one of them, that one is omitted. Note that this is displaying what a feature directly enables, or is directly enabled by. No transitive features are displayed.

[scottkurz]

2024-01-24 DXDI UPDATE -

Agreed it made sense to use the default cached feature list XML as the first preference for loading enables/enabled-by feature info.

If the feature isn't present there we'll just the features.json info (without the enables/enabled-by info, like we do today), rather than generating features list XML (from an install that might not typically include all features).

This has the downside that we will be missing the latest features whenever new ones are released until the LCLS and then the Liberty Tools (IDE support) releases catch up. Practically this may only matter in the months right after a major MP/EE release.

But separately will follow-up to investigate the idea of calculating enables/enabled-by from the features.json info.
It looks like to get from the features.json to the simpler, more consumable format in the feature list XML, one needs to:

1. follow transitive dependencies
2. filter out internal and marker features.

Can we do this conversion in LCLS, and/or should we update what gets released into features.json? Following up in IBM-internal discussion for now.

@cherylking have I captured this correctly?