Gradle api dependency for plugin development

Old Forum Archive
1

In order to develop a plugin for gradle I would like to have a repository deployed version of the gradle api which contains the plugin and task base classes. Is there a way to support a pom dependency like this?

<dependency>
        <groupId>org.gradle</groupId>
        <artifactId>gradle-core</artifactId>
        <version>1.0-milestone-6</version>
    </dependency>
2

Hi Dirk,

Why do you want to do this?

3

@Luke

Because I have other systems additionally to gradle that also need to access the dependency information and the common way is currently the pom.xml.

And generally spoken, why shouldn’t I have access to the gradle api by means of normal dependency management? For me it breaks the design if the grade stuff resides only in a installed gradle system. Of course the build.gradle stuff works. But other systems would reference the libaries statically via the local filesystem which is really out dated for me.

Gradle should not come into my way but it does in a way. Do you understand the issue?

4

Because I have other systems additionally to gradle that also need to access the dependency information and the common way is currently the pom.xml.

What other systems are consuming the jars you are building against the Gradle API?

And generally spoken, why shouldn’t I have access to the gradle api by means of normal dependency management?

Because we don’t support loading arbitrary versions of the API into the runtime, so you would end up with version conflicts if the plugin is used in a different version of Gradle than it was built with.

For me it breaks the design if the grade stuff resides only in a installed gradle system.

Gradle is currently designed to provide the api/impl to clients, not to have them pull it in. This works for the common use case of building Gradle plugins.

I’d like to know more about what you are doing here as it sounds like a use case we haven’t considered. Using the ‘gradleApi()’ notation may not be what you want to do.

5

Right, the gradleApi() does not help in that case.

It helps building the plugin but no more. Before I have to write the plugin. Imagine we have some fancy Eclipse Plugin that supplies a ClasspathContainer which automatically operates on base of the projects pom.xml. This is a fine thing as you manage dependencies only once - no matter if for the build (based on gradle) or for the eclipse classpath which is needed to write the plugin. If I don’t use this approach is looks like this:

1 . Managing Eclipse Classpath

Here I need to statically reference the gradle jars from the gradle installation. This breaks with all other projects we have that are just managed by the pom.xml (we use it only for dependencies). The location of the gradle installation is not the same on all machines so the lib references of the eclipse project will break. A solution would be to make copies of the library, put them in the eclipse project and commit that to the code repository which brings us back to a state that we want to avoid with help of dependency management. This worked fine with the combination maven-ant-tasks and ant.

2 . Building with Gradle

Here I can inject the gradle libraries just by the magic gradleApi() function but exactly that magic which provides jars from the installation breaks the clean approach of managed dependencies - no matter if it is thought for a plugin, a build script or an artifact to be built.

I am very much interrested to replace ANT by gradle and I really want avoid MAVEN which is just another XML hell with no flexibility.

So the idea is that gradle’s base classes for tasks and plugins should be accessible by normal dependencies (groupId, artifactId, version).

Probably I do not understand every possibility yet but I searched a long time for reposistories that hold gradle jars. I found nothing.

If could not exactly describe my needs than ask again. I will then go more into detail.

6

To me, having the Gradle API in a public repository is a natural requirement. It’s a perfect example for a “provided” dependency in Maven speak - you pull it in at compile time but not at runtime. Decoupling the API to build against from the API in use is certainly valuable, and I don’t see it causing any new problems.

7

Thanks for these short but definitly clear statement which perfectly is what I wanted to say

8

Any chance that this is going to happen? It may sound a bit unimportant, but a clear dependency management is a real boon to any project. Having it for the gradle dependencies would be really great.

9

We have no concrete plans to do this at this time. We do intend to do something in this area as far as it makes sense in the future.

It’s difficult assign a high priority to this without concrete use cases. I don’t doubt that there are concrete use cases, it’s just that none have been identified that would make this a high priority.

10

@Luke

How can I convince you that this IS an important issue and that our use case is in fact the use case you are “waiting” for? Anybody who wants to write gradle plugins in a development environment which uses a form dependency management other than having all dependencies dumped into a bucket definitively has the need for it.

What about Peter Niederwieser’s opinion which was up to the point? We’re talking about a simple xml formatted file that declares the dependencies of the your java libraries and the task of uploading the respective libaries to a maven repository. What’s so complicated about that?

Your statement that “gradle won’t get in my way” felt really inviting to me. Now I must confess that I’m really disappointed that I have to realize that it very much gets in my way…

11

This will get addressed, just probably not before 1.0. It’s not fair to judge Gradle’s openness by a single issue for which there is a workaround (use the corresponding Gradle version to build the plugin).

12

It was just an expression of frustration and not a judgement. We are looking forward to the solution and hope you see the importance of this issue.

We pay much respect for what you have achieved so far. Thanks a lot for your good work.

13

@Peter

So, about a year has passed since then. Is there a chanse that we will be able to refer to Gradle API as a Maven dependency?

14

I wrote a Gradle plugin in Maven before finding this thread.

To do that I downloaded the jars into my source tree and added them to my Gradle Plugin’s pom.xml as system dependencies.

They could probably be downloaded to somewhere else with sneaky AntRun

It would probably burst into flames if I tried to use it as a transient dependency

https://github.com/g-pechorin/samon/blob/master/grask/pom.xml