# Classpath hell - SoapUI and Gradle API logging conflicts

**URL:** <https://discuss.gradle.org/t/classpath-hell-soapui-and-gradle-api-logging-conflicts/8830>\
**Category:** Help/Discuss\
**Created:** [April 12, 2015, 4:20pm UTC](https://discuss.gradle.org/t/classpath-hell-soapui-and-gradle-api-logging-conflicts/8830 "2015-04-12T16:20:40Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![sterling](https://sea1.discourse-cdn.com/gradle/user_avatar/discuss.gradle.org/sterling/32/5395_2.png) [@sterling](https://discuss.gradle.org/u/sterling)\
**Post date:** [April 17, 2015, 3:29pm UTC](https://discuss.gradle.org/t/classpath-hell-soapui-and-gradle-api-logging-conflicts/8830/4 "2015-04-17T15:29:56Z")

</div>

You’re basically running into the same sort of problem as this topic: [Dealing with plugin classpath conflicts](https://discuss.gradle.org/t/dealing-with-plugin-classpath-conflicts/9162) and [Classpath / classloader conflicts with other plugins in the buildscript](https://discuss.gradle.org/t/classpath-classloader-conflicts-with-other-plugins-in-the-buildscript/6613/4)

The issue here is the dependency comes through `gradleApi()` and there’s not a way to override it. We include a log4j-over-slf4j dependency that contains those same classes.

For your particular case, I think it might make sense to make your Soap related tasks JavaExec’s and fork a separate process rather than run that code within the Gradle process.

---

_[View the full topic](https://discuss.gradle.org/t/classpath-hell-soapui-and-gradle-api-logging-conflicts/8830)._