What is the best way to organize classloading of a plugin (developed as a standalone package)?

Old Forum Archive
1

Current version of Kotlin language ( http://kotlin.jetbrains.org/ ) plugin has a compatibility issue with License plugin http://devnet.jetbrains.com/thread/444525 - different versions of Google Guava libraries.

As this topic http://forums.gradle.org/gradle/topics/gradle_runtime_classpath says, all uses’s plugins and buildscript share one classloader. Peter suggested to use parent-last classloader. This sounds fine. Is it still the best approach? Has anything changed in plugin classloading during last year?

If it is still the best solution, could anyone point me to Gradle API that allows to resolve dependencies in runtime, from the plugin code. Ideally, I would like to give a maven coordinates (group-artifact-version) and get a collection of files on the disc, so I could properly load them to custom classloader.

2

As a plugin developer, you don’t have much control over this. If a build script declares multiple plugin dependencies, and there are conflicts between their transitive dependencies, the usual conflict resolution will kick in, and it can be configured in the usual ways. Isn’t there a version of Guava that works both for Kotlin and License plugin? And isn’t it the higher of the two declared versions?

3

This seems to be not good enough approach.

  1. Transitive dependencies version conflicts are not easy to trace. It takes time to understand what conflicts with what and if the resolution exists.

  2. Even if common resolution exists, user is required to add extra magic spells to build script section just to use two plugins together. The resolution strategy code may get very complicated and fragile.

  3. Not every project is updated quickly to latest Gradle. Some still use older versions, where dependency conflict resolution strategies are not available

As a plugin author, I would like to make users’ lifes as simple as possible - it should just work.

Could you point me to Gradle dependency resolution api (if any)? So I could resolve my plugin’s dependencies and build up my tiny little classloader with them :slight_smile:

4

Also, not every project is updated quickly to latest Gradle. Some still use older versions, where dependency conflict resolution strategies are not available