JavaxServletApi resolution actually downgrades the version

[kmoens]

The standard resolution of the JavaxServletApi rule is not correct IMHO.

Suppose I have a build.gradle as follows:

plugins {
    id 'java'
    id 'java-library'
    id 'org.gradlex.java-ecosystem-capabilities' version '1.1'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'javax.servlet:javax.servlet-api:3.0.1'
    implementation 'org.apache.tomcat:servlet-api:6.0.53'
}

This results in the following classpath:

compileClasspath - Compile classpath for source set 'main'.
+--- javax.servlet:javax.servlet-api:3.0.1 -> org.apache.tomcat:servlet-api:6.0.53
\--- org.apache.tomcat:servlet-api:6.0.53

As Tomcat 6.x is using Servlet API 2.5, we actually downgraded the Servlet API in this case.

This probably applies to other modules in the Java EE / Jakarta EE namespaces too.

[jjohannes]

Yes this is true. For such cases, the version of the Capability can be different than the version of the Component. Rules like the JavaxServletApi already encode this knowledge.

As the resolution strategy, you would need to use selectHighestVersion() – which operates on the Capability version – to take this into account. If you use that in your build, this should work.

Unfortunately, that's problematic as default, because it is buggy if you need to stack another strategy on top. For example, if there are still two matches with the same version: gradle/gradle#20348

But we can probably reconsider. As you can now turn off single default strategies, you can turn a default strategy off in cases where you run into that bug.

@kmoens I am open to discuss using selectHigherstVersion() as default. Which would mean replacing this custom strategy with it: https://github.com/gradlex-org/java-ecosystem-capabilities/blob/8d73586ea554173064a8ced0c34994700782e82e/src/main/java/org/gradlex/javaecosystem/capabilities/JavaEcosystemCapabilitiesPlugin.java#L238-L249 Maybe you would like to give it a try?

In general, the main motivation to have default resolutions in this plugin is so that folks adding it do not suddenly get a failing build. Maybe this is the wrong motivation. The defaults are never the right choices for everyone. Maybe the preferred way should be to turn them off. After all, the original idea was that this plugin only provides metadata that could also be located in repositories (strategies can not be put into metadata).
Would be interested in what others think. Should we consider removing default strategies altogether?

[kmoens]

Well, I fully agree with a default strategy. At our company we have about 30-40 projects which are all based on Gradle and we have a company-wide plugin which applies a number of defaults.

In that company-wide plugin we also tend to use a strategy to avoid breaking at all.

I've opted - in this specific case - to give priority to the Jakarta EE libraries over Tomcat libraries. So if both are present, we pick the Jakarta EE ones. This is not perfect either, but it gives us at least consistent results by default and we don't get downgrades.

[jjohannes]

In the 2.0 release, we will change the behavior to use Gradle's built-in selectHighestVersion().

This is based on the "Capability Version" rather than the "Module Version".

This should resolve this issue. (Test that is does, before closing the issue.)