OpenLiberty
Reconsider conflict error messaging
Expected that adding a feature to server.xml that conflicts with previously generated features should result in BINARY_SCANNER_CONFLICT_MESSAGE1 (between configured and app), but it results in BINARY_SCANNER_CONFLICT_MESSAGE2 (between configured features) instead. This is most likely because the binary scanner sees the user specified features and previously generated features as one list (configured features). If this is the case, we may need to reconsider the wording for the error messages.
Update from discussion with team:
- Add new functionality to binary scanner that just checks for conflicts with passed in features. Plugin could pass whole list and then only user specified features to see where the conflict lies.
- Ideal, but will probably not be available for 1Q
- Would allow us to say, "there is a conflict between added features and previously generated features...if you want to keep the added feature, try optimizing the feature list..."
- Optimize feature generation after server.xml changes. This should in theory trigger the correct error message, however, it may be expensive with large applications to optimize on every server.xml change.
- Need to confirm optimize will trigger the error message we want
- Would be necessary to update code to only generate features if
<featureManager>section is modified - This change may be necessary for https://github.com/OpenLiberty/ci.maven/issues/1366, regardless of how we decide to handle the error messaging
- Add "generated-features.xml" to "configured features" error message to inform users that the conflict could be between their added feature and "generated features"
- Also change wording to say "a recent app change has caused conflict..." or "a recent configuration change has caused a conflict..."?
- Could add the line from (1) as a suggestion: "if you want to keep the added feature, try optimizing the feature list..."
Add new functionality to binary scanner that just checks for conflicts with passed in features. Plugin could pass whole list and then only user specified features to see where the conflict lies. Ideal, but will probably not be available for 1Q Would allow us to say, "there is a conflict between added features and previously generated features...if you want to keep the added feature, try optimizing the feature list..."
After some testing it seems this may already exist with current functionality of the binary scanner. That is, you can pass an empty string for the binaryInputs and it will check for conflicts between the feature list passed in (if any).
Calling binary-app-scanner-21.0.0.5-SNAPSHOT.jar with the following inputs...
binaryInputs: []
eeVersion: ee8
mpVersion: mp4
currentFeatures: [cdi-2.0, cdi-1.2]
locale: en_CA
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.357 s
[INFO] Finished at: 2022-01-25T12:35:06-05:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal io.openliberty.tools:liberty-maven-plugin:3.5.2-SNAPSHOT:generate-features (default-cli) on project demo-devmode-maven: A working set of features could not be generated due to
conflicts between configured features: [cdi-2.0, cdi-1.2]. Review and update your server configuration to
ensure it is not using conflicting features from different levels of MicroProfile, Java EE, or Jakarta EE. Refer to
the following set of suggested features for guidance: [].
@turkeylurkey added a helpful method getServerFeatures() that allows you to omit generatedFeatures.xml. We could use this method to determine the list of user specified features versus previously generated features.
https://github.com/OpenLiberty/ci.maven/blob/d82422a9ee4718018e01010060d67a520eba5f46/liberty-maven-plugin/src/main/java/io/openliberty/tools/maven/server/GenerateFeaturesMojo.java#L269-L281
The integration tests added for https://github.com/OpenLiberty/ci.maven/issues/1396 do not cover the scenario where there is a previously generated XML file and a new conflicting feature is added to server.xml. That is the scenario that originally caused this issue's error to occur. This has been resolved by the changes to resolve https://github.com/OpenLiberty/ci.maven/issues/1366. However, we should add an integration test for this scenario.
Also, is it possible to create a scenario where we add Java code that conflicts with previously generated features? Should we have another issue to address this?