Skip to first unread message
Robin Green
Sep 28, 2012, 4:54:24 AM9/28/12
to simple-b...@googlegroups.com
This sort of relates to the eclipse-sbt plugin, but I'm not sure whether the resolution will involve eclipse-sbt.
In my eclipse project classpath I've now got 3 different versions of the same dependency (specs2). I think this might be why I'm experiencing problems debugging inside that dependency (specifically, no breakpoints set inside there are being hit, but breakpoints set elsewhere are generally being hit OK). I've experienced similar problems before, too, without previously being able to identify the cause.
Note that I'm telling the eclipse-sbt plugin:
EclipseKeys.configurations := Set(Compile, Test, IntegrationTest)
so it's possible that sbt has resolved one version of specs2 for src/main, another version for src/test, and another version for src/it (integration tests). I don't know if that's the case, I'm just speculating here. I also don't believe that eclipse can distinguish between dependencies for different parts of the same project, so that's probably why they've all been combined.
I guess what I'd like to do is work out which version of the dependency is actually being used in the test run I'm debugging, and hide the others, at least so that Eclipse can't see them. This might not solve my debugging problem, but at least it'd eliminate this as a cause of the debugging problem, if it's not the cause.
In my eclipse project classpath I've now got 3 different versions of the same dependency (specs2). I think this might be why I'm experiencing problems debugging inside that dependency (specifically, no breakpoints set inside there are being hit, but breakpoints set elsewhere are generally being hit OK). I've experienced similar problems before, too, without previously being able to identify the cause.
Note that I'm telling the eclipse-sbt plugin:
EclipseKeys.configurations := Set(Compile, Test, IntegrationTest)
so it's possible that sbt has resolved one version of specs2 for src/main, another version for src/test, and another version for src/it (integration tests). I don't know if that's the case, I'm just speculating here. I also don't believe that eclipse can distinguish between dependencies for different parts of the same project, so that's probably why they've all been combined.
I guess what I'd like to do is work out which version of the dependency is actually being used in the test run I'm debugging, and hide the others, at least so that Eclipse can't see them. This might not solve my debugging problem, but at least it'd eliminate this as a cause of the debugging problem, if it's not the cause.
Robin Green
Sep 28, 2012, 5:55:46 AM9/28/12
to simple-b...@googlegroups.com
On Friday, 28 September 2012 09:54:24 UTC+1, Robin Green wrote:
I guess what I'd like to do is work out which version of the dependency is actually being used in the test run I'm debugging,
OK, so this part is easy in my case - in my tests I'm using a specs2 feature which is only available in the snapshot build. So I *must* be using the snapshot version!
and hide the others, at least so that Eclipse can't see them.
For now I've just removed them from the project classpath in Eclipse - but presumably they'll be re-added next time I re-run
> eclipse
in sbt.
Robin Green
Sep 28, 2012, 6:26:01 AM9/28/12
to simple-b...@googlegroups.com
OK, it turns out this wasn't the cause of my mysterious debugging problems. It's actually not "breakpoints don't work in this jar", either - some do get hit, some don't. (I'm using Eclipse in "Java debugging mode", so to speak, because the new Scala debugging mode isn't yet supported for debugging things running within sbt, as far as I know, because it doesn't support remote debugging.)
Reply all
Reply to author
Forward
0 new messages