Open cbridgha opened 1 month 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?
Had a meeting today to discuss with Alasdair, Chuck, Trevor, Andy and YK. @cbridgha Tagging you to verify what I am summarizing here.
<feature>
element value for versionless features - will come with updated features.json file.<platform>
element - will come with updated schema file.<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?<platform>
element - use description in schema element<platform>
element value - is there a description to pull from featurelist.xml for each platform value?<platform>
element value, flag values that are not part of the completion list.
-- For <feature>
element value, flag a versionless feature if version is ambiguous.
-- For <feature>
element value, flag a versionless feature if there is also a versioned feature for the same technology and vice versa.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.
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;
}
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.
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"
],
...
}
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.
<feature>
element value for versionless features - from features.json
file<platform>
element - from schema file<platform>
element value - use features.json
to determine valid values. Should show all available platforms.<platform>
element - use description from schema file<platform>
element value - use approved hard-coded descriptions with replacement string for version<platform>
element value, flag values that are not part of the completion list.<feature>
element value, flag a versionless feature if version is ambiguous (no compatible platform configured and no versioned feature with a supported platform configured)<feature>
element value, flag a versionless feature if there is also a versioned feature for the same technology and vice versa.
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:
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:
<platform>
name validation