The port from Maven2 to Maven 3 APIs breaks any existing plugins that relied upon the repackaged code. We’ve seen this problem reported by a user. Plugins that only want to target 2.5 plus can, presumably, start using the Maven APIs in their original packages, but things aren’t so easy for a plugin that want to support 1.x and all versions of 2.x.
The solution that I’m currently exploring is for my plugin to include its own repackaged copy of the Maven APIs. While I’m pretty sure this will work, it seems like a step backwards for every plugin that depends on the previously repackaged Maven APIs to have to start doing this.
Could the repackaged APIs please be reinstated so that 2.5 is backwards compatible with 2.4?
The repackaged Maven3 jars were never considered part of the API of Gradle. Only those classes that are listed in the Gradle API documentation are considered to be part of the Gradle API.
The use of Maven3 for publishing was an implementation details, and it’s unfortunate that you needed to depend on these repackaged classes in your plugin. So this change does not violate our backward compatibility ‘contract’. We need to be able to change our internal dependencies as we continue to evolve Gradle.
One difficultly here is that the Gradle implementation classes are not effectively sandboxed from a Plugin, so it’s very easy to depend on internal classes, and difficult to provide alternatives where you wish to use a version different to the one used by Gradle. This situation is not great, and is something we plan to address, together with better support for plugin testing and support for plugin variants to support multiple versions of Gradle.
In the meantime, I suggest that you follow through with your plan to include your own copy of the repackaged classes in your plugin.
Given that I now know that you only consider classes in the API documentation to be public, can you please explain the purpose of the org.gradle.internal.* packages? Given its existence, I had assumed that anything not beneath org.gradle.internal was fair game from an API perspective.
The idea is that eventually all classes that are not part of the public API will be clearly identified with a package named .internal.. We’re pretty good about doing this for new classes, but for now there are plenty of classes that have not been packaged this way.
Clearly, we should have chosen a name containing .internal. when repackaging the Maven 3 classes.