Unfiltered-scalatest fetches old version of scalatest to classpath and throws up exception when using with scala 2.9.x

[vvilhonen]

Here's an example project on how to reproduce the binary compatibility problem. Dependency should be declared as provided or something so it doesn't end up for the user of the library..

https://github.com/vvilhonen/binarybackward

[n8han]

You can always call intransitive() on the dependency specification for th same effect, however you are likely to run into further problems since it wasn't compiled against the correct version of scalatest.

Scalatest is not cross-published across major versions of Scala so it is a high-maintenance dependency for us to support. Unless someone wants to take responsibility for this module I'll have to remove it.

[dwestheide]

I'd hate to see this module removed, since I am actively using it for my projects. So, if no one else volunteers, I would take responsibility for this module and also take care of this issue.

By the way, I do not have these binary compatibility problems when using the module with Scala 2.9.0-1 and ScalaTest 1.6.1 for 2.9.0, so I assume the problem turned up with Scala 2.9.1.

[n8han]

There's a middle of the road option, which is what we're now doing for
the scalate module: external git dependency. These are easier to update
and easier to fork. The downside is that you lose maven and sbt 0.7
compatibility. And if you're making a library that depends on a "git
dependency", then it too will have to be distributed that way.

But it's a really compelling option for the kind of code that you want
to reuse across different applications, but which is difficult to
publish as a traditional library.

[dwestheide]

While I generally like the idea of external git dependencies, there is another downside to it: At least the sbt-idea plugin does not produce anything useful when an external git dependency is involved in the SBT build definition, i.e. the git dependency does not exist in the IDE. I don't know if support for these external dependencies is better in other IDEs, but personally I currently end up deploying such modules to a private Maven repository to work around this, which is pretty annoying.

I don't know if anyone else thinks this is a problem, but I thought I'd at least mention it.

[n8han]

Funny I just heard the same thing from the Dispatch list. I hope they
catch up soon with sbt, because I'm going to be using it more and more.
Binary compatibility is such a crippling problem for Scala libraries; we
can't afford to leave any tools on the shelf that will help mitigate it.

If you want to fix the build for the traditional maven-style artifact,
it's a matter of conditionally depending on different versions of
scalatest depending on the current scala version. We do this for specs,
as we must, since that is what we use to test unfiltered.

[dwestheide]

I totally agree with you. I am going to submit an issue to the sbt-idea project. Hopefully, we'll soon see better support for external dependencies in IntelliJ.

In the meantime, I am going to take responsibility for this module and fix the build for the traditional maven-style artifact. Thanks for the hint. I guess the most time-consuming part of this is to find the appropriate versions for each Scala version.

[n8han]

Thanks Daniel!