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.