Feature request: handling split package modules issues

Certain well-known, often-used jar files exhibit split package issues when both were put on the module path. One pair that I encountered is the conflict between

"javax.annotation:javax.annotation-api:1.3.2"

and

"com.google.code.findbugs:jsr305:3.0.2"

Fortunately, this conflict can be resolved by putting only one of them on the module path and then patch it with the content of the other. This can be achieved by applying snippets of Gradle codes for the compileJava, compileTestJava, test, run, startScripts, and distributions tasks, such as the following:

compileJava {
    doFirst {
        def jsr305 = classpath.filter{it.name.contains('jsr305')}.asPath
        classpath = classpath.filter{!it.name.contains('jsr305')}
        options.compilerArgs += [
                '--patch-module', "java.annotation=$jsr305"
        ]
    }
}

Since these snippets are scattered repetitively throughout the build.gradle file, and the modifications they trigger are quite in line with that the moduleplugin does, I wonder if it makes sense for the moduleplugin to provide a declarative way to handle the situation.

Here’s a simple test case that demonstrates the issue:

https://github.com/weiqigao/jsr305-split-package-issue

where the foo project is a non-modular Maven jar project that depends on both jars, and the bar project is a Gradle modular jar project that depends on the artifact of the foo project and therefore transitively depends on the conflicting two jars. The build.gradle in the bar project contains more snippets similar to the above but for the run, startScripts, and distributions tasks.

[paulbakker]

Thanks @mwkroening, that’s useful. @weiqigao I’m thinking this should be “global” config that applies to all tasks right?

[paulbakker]

Merged and released.