Replace gradleApi() dependency with newer version?

Old Forum
1

Hi I am working on a plugin where it would be extremely advantageous to have Guava 14, I could work around it, but id rather not have to. Unfortunately, the gradleApi() provides Guava 11, and it seems impossible to remove or replace guava 11 with guava 14.

I should also mention that this is true for any library which gradle packages. Plugins cannot be compiled with any version but the one gradle packages, however these libraries are not available at runtime. it would be nice if we could either have access to all the gradle libs at runtime, or atleast kept them out of the compile classpath so we can use newer versions.

2

I have a similar issue with a less plugin that I’m trying to build. It needs rhino 1.7R4, but gradles rhino 1.7R3 gets used instead. This seems a fundamental issue

3

The best solution I can come up with… is to ammend the GradleAPI() method so that it does the following. 1. adds the gradle install directory and lib directories as FlatFile repositories. 2. constructs a module with the GradleAPI as the main artifact and the other artifacts as transitive dependencies.

This way us users can use the standard dependency filtering systems and configure it all however we want.

Unfortunately… the placing of the gradleApi() method makes me assume that its called on the DependencuHandler… which may not have a project instance on which to create a repository… I think it would be best if they simply had a GradlePlugin plugin, which would add everything as I mentioned above. of course thats quite a major APi breakage, and its unlikely to happen.

4

Hi,

We are working on improving the lives of plugin developers right now. We are working on a new mechanism that allows plugins to be isolated from both Gradle and other plugins, which will allow multiple versions of classes at runtime. As part of this, there will be better build time tooling for plugin authors.

The https://github.com/gradle/gradle/blob/master/design-docs/publishing-and-sharing-plugins.md design spec captures some of what we are implementing and planning. This is an area still under design though, so you can expect that spec to expand in the very near future.