# How to separate gradle plugin dependencies and project dependencies

**URL:** <https://discuss.gradle.org/t/how-to-separate-gradle-plugin-dependencies-and-project-dependencies/15515>\
**Category:** Help/Discuss\
**Tags:** plugins\
**Created:** [March 30, 2016, 7:37am UTC](https://discuss.gradle.org/t/how-to-separate-gradle-plugin-dependencies-and-project-dependencies/15515 "2016-03-30T07:37:12Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![Lance\_Java](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/lance_java/32/787_2.png) [@Lance\_Java](https://discuss.gradle.org/u/Lance_Java)\
**Post date:** [March 30, 2016, 12:24pm UTC](https://discuss.gradle.org/t/how-to-separate-gradle-plugin-dependencies-and-project-dependencies/15515/2 "2016-03-30T12:24:29Z")

</div>

This has been discussed before [here](https://discuss.gradle.org/t/classpath-classloader-conflicts-with-other-plugins-in-the-buildscript/6613). There’s a design doc discussing the feature [here](https://github.com/gradle/gradle/blob/master/design-docs/publishing-and-sharing-plugins.md#isolation) but as yet there’s no best-practice solution that I’m aware of.

As a workaround, you could create your own `configuration` in the plugin and create a custom classloader from the jars in the `configuration`. This custom classloader could then load the conflicting class(es). If using this approach, be careful about the parent classloader so it doesn’t inherit from the buildscript classloader. Classloaders in gradle plugins discussed in @Schalk_Cronje’s [idiomatic plugin authoring](https://www.slideshare.net/mobile/ysb33r/idiomatic-gradle-plugin-writing)

---

_[View the full topic](https://discuss.gradle.org/t/how-to-separate-gradle-plugin-dependencies-and-project-dependencies/15515)._