One DSL/Extension for customizing conflict resolution / change plugin IDs

[jjohannes]

Proposal for an integrated DSL. This is only as a base for discussion. Not everything needs to be ready for 2.0, but names of plugins and extension needs to be decided before 2.0 as these are breaking changes.

Idea, have only two plugins:

• org.gradlex.jvm-ecosystem-conflict-detection – only adds the capability rules
• org.gradlex.jvm-ecosystem-conflict-resolution – provides DSL for convenient dependency conflict management in Java projects

How this may look like:

jvmDependencyConflicts {
    conflictResolution {
        selectLenient(JAVAX_ACTIVATION_API, "com.sun.activation:jakarta.activation")
        selectLenient(JAVAX_ANNOTATION_API, "jakarta.annotation:jakarta.annotation-api")
        selectLenient(JAVAX_SERVLET_API, "jakarta.servlet:jakarta.servlet-api")
        select("xml-resolver:xml-resolver", "xml-resolver:xml-resolver")

        selectHighestVersion("commons-codec:commons-codec")
        selectHighestVersion("xalan:xalan")
        selectHighestVersion("wsdl4j:wsdl4j")
        selectHighestVersion("javax.transaction:javax.transaction-api")
    }

    logging {
        enforceSlf4JSimple()
    }

    patch {
        // 'json-simple' wrongly depends on 'junit:junit'
        module("com.googlecode.json-simple:json-simple") { removeDependency("junit:junit") }
        // 'org.apache.batik.pdf' partially contains 'commons.io'
        module("org.eclipse.birt.runtime:org.eclipse.birt.runtime") { removeDependency("org.eclipse.birt.runtime.3_7_1:org.apache.batik.pdf") }
        // Brings two overlapping pull parsers: 'xmlpull:xmlpull' and 'xpp3:xpp3_min'
        module("com.thoughtworks.xstream:xstream") { removeDependency("xpp3:xpp3_min") }
        // Concrete logger implementations should never be a published dependency
        module("org.liquibase:liquibase-core") { removeDependency("ch.qos.logback:logback-classic") }

        module("jakarta.transaction:jakarta.transaction-api") { addCapability("javax.transaction:javax.transaction-api") }
        module("org.apache.geronimo.specs:geronimo-jta_1.1_spec") { addCapability("javax.transaction:javax.transaction-api") }
        module("org.eclipse.birt.runtime.3_7_1:org.apache.commons.codec") { addCapability("commons-codec:commons-codec") }
        module("org.eclipse.birt.runtime:javax.xml.stream") { addCapability(STAX_API.capability) }
        module("org.eclipse.birt.runtime.3_7_1:org.apache.xml.serializer")  { addCapability("xalan:xalan") }
        module("org.eclipse.birt.runtime.3_7_1:javax.wsdl")  { addCapability("wsdl4j:wsdl4j") }
        module("org.eclipse.birt.runtime.3_7_1:org.apache.xml.resolver") { addCapability("xml-resolver:xml-resolver") }
        module("org.apache.geronimo.specs:geronimo-annotation_1.0_spec") { addCapability(JAVAX_ANNOTATION_API.capability) }

        // This could be a solution for https://github.com/gradlex-org/java-ecosystem-capabilities/issues/74
        module("org.apache.tomcat:tomcat-annotations-api") { removeCapability(JAVAX_ANNOTATION_API) }
    }
}

[elect86]

Would be possible to have the DSL profit from @CachedRule?

[jjohannes]

Merging this PR to continue the work towards the 2.0 release. All names for the plugins and in the DSL may still be subject to change before the release.

[jjohannes]

@elect86 all rules that you can add via the DSL are tagged with @CacheableRule.