Buildscript dependency soup?

Peeps,

I’m having second thoughts about using some Gradle plugins because they (seem to) share dependencies.

For instance the following two I find suspect:


These plugins offer useful functionality but each pull in a great many jars, e.g. Spring, which can result in version conflicts easily.

I think a Gradle plugin developer should be able to use anything, and whoever uses a plugin doesn’t need to know about that.

Am I seeing ghosts? Should plugins not run in their own “space” similar to how OSGI bundles work? Or is this already taken care of somehow?

regards,
Tom

Im surprised this isn’t getting a response as I think it’s an important issue

Hi,

You’re correct, plugins aren’t isolated from each other. We’ve been moving towards this for some time, but it is unlikely to happen soon (there’s lots to do) and is going to be disruptive.

The way around this now is to use script plugins to isolate plugins. Each script can have its own buildscript {} block and has its own classloader. If you have conflicting plugins, you can use this as a boundary. As with any classloader graph system, this may require some fiddling to get things to cooperate if the dependency graphs are complex.