E.g.:

a) If there's a mismatch of Guava versions, please fail instead of selecting something b) Please don't add capabilities for cglib, because, well, it adds conflict

Looks like it might be configured in a Gradle extension, or there might be a "plugin per ecosystem" like id("de.jjohannes.gradle:java-ecosystem-capabilities.cglib"), id("de.jjohannes.gradle:java-ecosystem-capabilities.guava"), ...

Hi, thanks for the awesome initiative with this plugin!

I believe org.apache.tomcat:tomcat-annotations-api could be added to JakartaAnnotationApiRule.

Also com.sun.activation:javax.activation in JakartaActivationApiRule.

Also com.sun.mail:javax.mail to JakartaMailApiRule.

Also, I'm not sure how these rules are supposed to work, but why doesn't JakartaActivationApiRule contain javax.activation:activation in it (or is that implicitly coming from the capability's group and name)?

Similar to https://github.com/ljacomet/logging-capabilities/issues/18 (which I merely copy/pasted here)

Currently, the plugin declares component metadata rules in the project, making it impossible to declare other rules in the settings.

I think the plugin should be split to have the component metadata rules in a settings plugin (actually, a plugin that could be applied either to a project or the settings, so projets that prefer project-level component metadata rules or have other plugins doing the same –or just because they want to leverage version catalogs and that cannot be done for settings plugins :chicken::egg:– can continue using them).

Or maybe the plugin could detect if it's also been applied to the settings (not sure if it's possible though) so it can conditionally add the rules to the project?

Or maybe the plugin could detect when it's applied to the settings and automatically inject the capabilities resolution rules into all projects, so it could be applied to either (but not both), and wouldn't need to be split?

Or just make it applicable to either settings (without registering the capabilities resolution rules) and projects, and declare component metadata rules in both cases? but that would make it incompatible with rulesMode FAIL_ON_PROJECT_RULES, and would warn for any other rulesMode.

Looks like https://github.com/jjohannes/missing-metadata-guava is related, and the name of java-ecosystem-capabilities sounds good for an umbrella project.

See list here: https://github.com/eclipse/transformer/blob/main/org.eclipse.transformer.jakarta/src/main/resources/org/eclipse/transformer/jakarta/jakarta-versions.properties

BOMs:

• javax:javaee-api
• jakarta.platform:jakartaee-bom

Awesome that this section is here!!!

In the code snippet all occurrences of version are spelt verson

configurations {
    apiElements {
        outgoing {
            capability("${project.group}:${project.name}:${project.verson}") // keep default capability 'org.ow2.asm:asm'
            capability("asm:asm:${project.verson}")                          // add 'asm:asm'
        }
    }
    runtimeElements {
        outgoing {
            capability("${project.group}:${project.name}:${project.verson}") // keep default capability 'org.ow2.asm:asm'
            capability("asm:asm:${project.verson}")                          // add 'asm:asm'
        }
    }
}```

Which is the new version of com.sun.mail:jakarta.mail... however there's a twist as with everything Jakarta related... :smile: This one package was split it two as far as I understand - jakarta.mail:jakarta.mail-api and org.eclipse.angus:jakarta.mail... so I'm not sure how java-ecosystem-capabilities would handle this.

The org.apache.commons:commons-io:1.3.2 release was the only one with this group. Everything else is published with group commons-io. For that reason that group should be used for the capability.

For that one I'm not really sure whether the behavior is the desired one. The org.eclipse.jetty.toolchain:jetty-jakarta-servlet-api dependency seems to be a bundle that contains both the javax.servlet:servlet-api, jakarta.servlet:jakarta.servlet-api, additional module-info.java and xml files.

There are org.bouncycastle:bcprov-jdk15on and org.bouncycastle:bcprov-jdk18on which are conflicting.

Same for bcmail, bcutil, bcpkix and maybe others.

From custom Nebula rule:

  "substitute": [
    {
      "module": "javax.servlet:jsp-api",
      "with": "javax.servlet.jsp:javax.servlet.jsp-api:2.+",
      "reason": "jsp-api has been replaced with javax.servlet.jsp-api",
      "author": "[email protected]",
      "date": "2022-04-01"
    },
    {
      "module": "javax.servlet.jsp:jsp-api",
      "with": "javax.servlet.jsp:javax.servlet.jsp-api:2.+",
      "reason": "jsp-api has been replaced with javax.servlet.jsp-api",
      "author": "[email protected]",
      "date": "2022-04-01"
    },
    {
      "module": "javax.servlet.jsp.jstl:jstl-api",
      "with": "javax.servlet.jsp.jstl:javax.servlet.jsp.jstl-api:1.+",
      "reason": "jstl-api has been replaced with javax.servlet.jsp.jstl-api",
      "author": "[email protected]",
      "date": "2022-04-01"
    }
  ]```

Custom Nebula substitution rule:

  "substitute": [
    {
      "module": "org.apache.geronimo.specs:geronimo-javamail_1.4_spec",
      "with": "javax.mail:javax.mail-api:1.4.+",
      "reason": "use formal mail api",
      "author": "[email protected]",
      "date": "2022-04-01"
    },
    {
      "module": "javax.mail:mail",
      "with": "javax.mail:javax.mail-api:1.4.+",
      "reason": "use formal mail api",
      "author": "[email protected]",
      "date": "2022-04-01"
    }
  ]

Expand on https://github.com/gradlex-org/java-ecosystem-capabilities#contribute

E.g.:

• How should a rule class look like (e.g. conventions for constants in class)?
• Where to add code to register the rule?
• How to test and extend the test sample?