Binary incompatibilities with 2.9.1?
vvilhonen
I'm using scalatest 1.6.1 with sbt 0.11.0 and scala 2.9.1. When trying
to execute a simple true should equal (true) spec I get a
ClassCastException right after stepping to scalatest from sbt. Stack
trace:
java.lang.ClassCastException: scala.collection.immutable.Set$EmptySet$
cannot be cast to scala.collection.generic.Addable
at org.scalatest.tools.Runner$.parseCompoundArgIntoSet(Runner.scala:
1037)
at org.scalatest.tools.ScalaTestFramework
$ScalaTestRunner.run(ScalaTestFramework.scala:87)
at sbt.TestRunner.delegateRun(TestFramework.scala:61)
at sbt.TestRunner.run(TestFramework.scala:55)
at sbt.TestRunner.runTest$1(TestFramework.scala:75)
at sbt.TestRunner.run(TestFramework.scala:84)
at sbt.TestFramework$$anonfun$6$$anonfun$apply$8$$anonfun$7$$anonfun
$apply$9.apply(TestFramework.scala:183)
at sbt.TestFramework$$anonfun$6$$anonfun$apply$8$$anonfun$7$$anonfun
$apply$9.apply(TestFramework.scala:183)
at sbt.TestFramework$.sbt$TestFramework$
$withContextLoader(TestFramework.scala:195)
at sbt.TestFramework$$anonfun$6$$anonfun$apply$8$$anonfun
$7.apply(TestFramework.scala:183)
at sbt.TestFramework$$anonfun$6$$anonfun$apply$8$$anonfun
$7.apply(TestFramework.scala:183)
at sbt.Tests$$anonfun$makeParallel$1$$anonfun$apply
$7.apply(Tests.scala:113)
at sbt.Tests$$anonfun$makeParallel$1$$anonfun$apply
$7.apply(Tests.scala:113)
at sbt.std.Transform$$anon$3$$anonfun$apply$2.apply(System.scala:47)
at sbt.std.Transform$$anon$3$$anonfun$apply$2.apply(System.scala:47)
at sbt.std.Transform$$anon$5.work(System.scala:67)
at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:
221)
at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:
221)
at sbt.ErrorHandling$.wideConvert(ErrorHandling.scala:13)
at sbt.Execute.work(Execute.scala:227)
at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:221)
at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:221)
at sbt.CompletionService$$anon$1$$anon$2.call(CompletionService.scala:
26)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:
441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
## the spec
package com.test
import org.scalatest._
import org.scalatest.matchers.ShouldMatchers
class ServerSpec extends FeatureSpec with ShouldMatchers {
feature("test") {
scenario("test") {
true should equal(true)
}
}
}
## sbt build.sbt
name := "test"
version := "0.1"
scalaVersion := "2.9.1"
libraryDependencies ++= {
val ufVersion = "0.5.1"
Seq(
"net.databinder" %% "unfiltered-filter" % ufVersion,
"net.databinder" %% "unfiltered-jetty" % ufVersion,
"net.databinder" %% "unfiltered-json" % ufVersion,
"net.databinder" %% "unfiltered-scalatest" % ufVersion,
"org.scalatest" %% "scalatest" % "1.6.1" % "test"
)
}
Bill Venners
That does look like it could be a binary incompatibility. I'm
surprised, though, that no one else has encountered it yet if so. The
way I deployed the 1.6.1 for 2.9.1, by the way, is by redeploying the
1.6.1 jars that I built under 2.9.0, because these are supposed to be
binary compatible. I'll forward this to typesafe/epfl and see if we
can figure it out.
Bill
> --
> You received this message because you are subscribed to the Google
> Groups "scalatest-users" group.
> To post to this group, send email to scalate...@googlegroups.com
> To unsubscribe from this group, send email to
> scalatest-use...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/scalatest-users?hl=en
> ScalaTest itself, and documentation, is available here:
> http://www.artima.com/scalatest
>
--
Bill Venners
Artima, Inc.
http://www.artima.com
vvilhonen
case isn't so uncommon, but it reproduced on my other machines (with
different OSes) as well.
- Vesa
Bill Venners
A typesafe guy said that Scala point releases are forward compatible,
not backward compatible, and suggested we buy their migration product.
I'd like to do a snapshot release built under 2.9.1 and have you try
that, to see if that solves the problem. I'll let you know once that's
out.
Bill
Bill Venners
I got a clarification from Mirco at Typesafe. Actually the binary
compatibility is supposed to work the way we thought it was. He also
is puzzled as to why you're getting this exception, and wonders if
you'd be willing to share your sbt project file. If so, can you post
it to this discussion on scala-internals?
http://groups.google.com/group/scala-internals/browse_thread/thread/58f23d90ad8a6862
Thanks.
Bill
vvilhonen
simple classpath issue where unfiltered-scalatest transitively gets
scalatest 1.3 in to the classpath. I'll let the unfiltered people know
about it. Thanks for your quick responses!
- Vesa
> compatibility is supposed to work the way we thought it was. He also
> is puzzled as to why you're getting this exception, and wonders if
> you'd be willing to share your sbt project file. If so, can you post
> it to this discussion on scala-internals?
>
> Thanks.
>
> Bill
>
>
>
>
>
>
>
>
>
> On Tue, Nov 1, 2011 at 10:17 AM, Bill Venners <b...@artima.com> wrote:
> > Hi Vesa,
>
> > A typesafe guy said that Scala point releases are forward compatible,
> > not backward compatible, and suggested we buy their migration product.
> > I'd like to do a snapshot release built under 2.9.1 and have you try
> > that, to see if that solves the problem. I'll let you know once that's
> > out.
>
> > Bill
>
Bill Venners
Great to hear.
Bill