External projects cause plugin conflicts #329

jsuereth opened this Issue Jan 11, 2012 · 9 comments


None yet

7 participants


If I have more than one source dependency on an external project, and both projects make use of an SBT plugin, then the plugin versions are not shared and the classloader magix become as black as the dark heart of MORDOR (notice that resembles MURDER).

Here's a simple build which demonstrates the issue:

object SbtPluginProjects extends Build with rewire.DependencyAnalysis {
  val root = Project("sbt-plugins", file(".")) aggregate(appengine, assembly)

  lazy val appengine = RootProject(uri("git://github.com/sbt/sbt-appengine.git"))
  lazy val assembly = RootProject(uri("git://github.com/sbt/sbt-assembly.git"))

If you know of a workaround, please list it here!


I've ran into the same issue. I think the symptom is seeing, what appears to be an attribute id name collision between a plugin and its own keys.


To clarify, normally if you got the same AttributeKeys but with the same type it's ok but here it's a problem because the same type comes from two class loaders?

The question then is if this is a problem of too much or too little separation when composing projects like this.

mccv commented Feb 3, 2012

This is blocking us from converting to sbt 0.11. We went through tremendous pain to get a hacky version of ProjectReferences working in 0.7.x, and one of the big draws in starting the sbt 0.11 upgrade process was the promise of it coming along "for free". If there's even a rough strategy laid out for how to fix it I'd be interested.

harrah commented Feb 12, 2012

I have a fix that a) loads all plugins from the same class loader b) overrides the plugin versions in source dependencies to be that of the dependent. This should ensure only one version of a plugin is ever resolved and loaded. However, there appears to be a problem with Ivy's override feature causing "impossible to get artifacts when data is not loaded" that I need to figure out before pushing the fix and then the milestone containing the fix.



@harrah harrah added a commit that referenced this issue Feb 15, 2012
@harrah harrah resolve plugin dependency version conflicts according to build order,…
… first part of fix for #329
@harrah harrah closed this in bda151c Feb 15, 2012
omervk commented May 17, 2012

If this was fixed three months ago, how is it that it's still there in the latest version (0.11.3)?

ijuma commented May 17, 2012

It was fixed for SBT 0.12 and higher.

omervk commented May 17, 2012

When do you expect to release it as a stable version? This is an issue that is blocking for us.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment