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
6 stars 12 forks source link

Updates needed supporting Versionless Features #280

Closed cbridgha closed 1 week ago

cbridgha commented 4 months ago

Liberty versionless features: https://github.com/OpenLiberty/open-liberty/issues/25704

The largest change for tools is a schema change in the server.xml that allows defining platforms in addition to specifying features without versions...

For example:

<featureManager>
   <feature>pages</feature>
   <platform>jakartaee-10.0</platform>
</featureManager>

This results in: The server installed the following features: [expressionLanguage-5.0, pages-3.1, servlet-6.0] versionless feature "pages" resolves to pages-3.1, which in turn depends on: expressionLanguage-5.0, servlet-6.0

There can be a platform version defined for both javaee/jakarta AND microProfile, and these determine the resolution of the versionless features.

In addition an ENV Variable(PREFERRED_PLATFORM_VERSIONS)and the combination of versioned features could also determine a platform version used... If any ambiguity still exists with all of these options, we throw an error, and the versionless features are not resolved.

versionless features are available in the Maven Central Repository, and we support

More detail in in the UFO

Features expected in our tools:

cherylking commented 4 months ago

@cbridgha Please add what the valid values for the <platform> element are, or where in the features.json we can find those values. We also should not allow multiple that specify different versions of the same platform I would think.

For incompatible features, we currently do not support flagging that for versioned features. We have issue #70 open for that and I think support for flagging incompatible versionless features should be included in that issue when it is addressed.

Another consideration will be what version of Liberty is the application/project using. If the version of Liberty is older than 24.0.0.8, then we should flag any versionless features as invalid and give a useful message saying they should use version 24.0.0.8 or later. The schema would take care of flagging the <platform> element as invalid. One potential problem though is we will update the default cached schema to match 24.0.0.8 which will allow both the platform element and versionless features, but if they specify an older version of Liberty...once it gets installed we would generate the schema and start flagging those as invalid. Hopefully most people just use the default latest Liberty version when doing development though.

One more question - are we expecting Liberty Tools to help flag versionless features that are indeterminate (because there is no platform element or ENV variable to specify what they want)? Is there some default behavior for that scenario?

cherylking commented 3 months ago

Had a meeting today to discuss with Alasdair, Chuck, Trevor, Andy and YK. @cbridgha Tagging you to verify what I am summarizing here.

A feature is ambiguous if it has no version and 1) there is no <platform> element with a valid value and 2) there is no common supported platform amongst all the versioned features.

Future enhancement - add a quick fix to flag convenience features and replace them with a list of versionless features and a <platform> element that matches the convenience feature. Chuck took a work item to add something to the featurelist.xml to help identify convenience features.

cbridgha commented 3 months ago

The featureList will show platforms of the public versioned features (That belong to 1 or many platform versions) via the <platform> element... example for ejb-3.2

<feature name="ejb-3.2">
    <symbolicName>com.ibm.websphere.appserver.ejb-3.2</symbolicName>
    <displayName>Enterprise JavaBeans 3.2</displayName>
    <description>This feature enables support for Enterprise JavaBeans written to the EJB 3.2 specification.</description>
    <category>JavaEE7Application</category>
    <enables>ejbHome-3.2</enables>
    <enables>ejbLite-3.2</enables>
    <enables>ejbPersistentTimer-3.2</enables>
    <enables>ejbRemote-3.2</enables>
    <enables>jdbc-4.1</enables>
    <enables>mdb-3.2</enables>
    <apiJar>dev/api/ibm/com.ibm.websphere.appserver.api.transaction_1.1.92.jar</apiJar>
    <apiJar>dev/api/spec/com.ibm.websphere.javaee.annotation.1.1_1.0.92.jar</apiJar>
    <apiJar>dev/api/spec/com.ibm.websphere.javaee.cdi.1.2_1.2.92.jar</apiJar>
    <apiJar>dev/api/spec/com.ibm.websphere.javaee.interceptor.1.2_1.0.92.jar</apiJar>
    <apiJar>dev/api/spec/com.ibm.websphere.javaee.transaction.1.2_2.0.92.jar</apiJar>
    <spiJar>dev/spi/ibm/com.ibm.websphere.appserver.spi.anno_1.1.92.jar</spiJar>
    <spiJar>dev/spi/ibm/com.ibm.websphere.appserver.spi.artifact_1.2.92.jar</spiJar>
    <spiJar>dev/spi/ibm/com.ibm.websphere.appserver.spi.containerServices_4.0.92.jar</spiJar>
    <spiJar>dev/spi/ibm/com.ibm.websphere.appserver.spi.javaeedd_1.8.92.jar</spiJar>
    <spiJar>dev/spi/ibm/com.ibm.websphere.appserver.spi.transaction_1.1.92.jar</spiJar>
    <configElement>classloading</configElement>
    <configElement>transaction</configElement>
    <platform>javaee-7.0</platform>
    <platform>javaee-8.0</platform>
    <include symbolicName="com.ibm.websphere.appserver.transaction-1.2"></include>
    <include symbolicName="com.ibm.websphere.appserver.ejbRemote-3.2" shortName="ejbRemote-3.2"></include>
    <include symbolicName="com.ibm.websphere.appserver.ejbPersistentTimer-3.2" shortName="ejbPersistentTimer-3.2"></include>
    <include symbolicName="com.ibm.websphere.appserver.ejbHome-3.2" shortName="ejbHome-3.2"></include>
    <include symbolicName="com.ibm.websphere.appserver.jdbc-4.1" shortName="jdbc-4.1" tolerates="4.2,4.3"></include>
    <include symbolicName="com.ibm.websphere.appserver.ejbLite-3.2" shortName="ejbLite-3.2"></include>
    <include symbolicName="com.ibm.websphere.appserver.mdb-3.2" shortName="mdb-3.2"></include>
  </feature>

We won't add the list of all"platform names" in an ENUM in the schema - because this list will evolve as new spec versions come out. Internally we do have a method that reads the repository, and collects up all the platform names traversing all feature metadata. - This could be done with your processing of the featureList as well....

In addition, a method for looking at the public "versioned" features common platforms could be written from the featureList data... This is an example of what we have in the FeatureRespository class:

/**
     * Returns the common intersection of platform names between the set of features passed
     *
     *
     * @param features
     * @return Set<String>
     */
    public Set<String> getCommonPlatformsForFeatureSet(Set<String> features) {
        Set<String> commonPlatforms = null;
        for (String featureName : features) {
            ProvisioningFeatureDefinition versionedFeature = getFeature(featureName);
            if (versionedFeature != null && !versionedFeature.isVersionless()) {
                Set featurePlatforms = new HashSet(versionedFeature.getPlatformNames());
                if (commonPlatforms == null)
                    commonPlatforms = featurePlatforms;
                else {
                    commonPlatforms.retainAll(featurePlatforms);
                }
            }
        }
        return commonPlatforms;
    }
cherylking commented 3 months ago

Completion for <platform> element value - use featurelist.xml to determine valid values either through explicit element (Chuck may add) or calculate based on the list of platforms for each specified feature. Should it show all available platforms or just those for the specified features?

Chuck and I decided we should show the full list for completion, in case they want a platform different than the current features. Then we would show a diagnostic for the features that are not compatible with that platform.

Hover for <platform> element value - is there a description to pull from featurelist.xml for each platform value?

I am thinking perhaps we can use the convenience feature description that has the same name as the <platform> element value.

cherylking commented 2 months ago

The features.json will contain entries like the following for features that belong to particular platforms:

 "wlpInformation": {
....
    "platforms": [
                "javaee-6.0",
                "javaee-7.0",
                "javaee-8.0"
                ],
...
 }
cherylking commented 2 months ago

Support was added with #299

Demo is scheduled for 9/5

Once I verify all of the following have been implemented, I will close this issue.