Allow mixed java\scala projects to be tested

[cessationoftime]

This fix is specifically for maven, though it will likely help with other buildtools. The problem with testing a mixed java\scala project is that you end up with Robolectric setting up the classloader for Java and then RoboSpecs setting up a second classloader for Specs2 and Scala, and the classloaders end up conflicting. This change causes RoboSpecs and Robolectric to share classloaders. RoboSpecs now detects when it is using the RobolectricClassLoader rather than always creating a new classloader, if it ends up creating a new classloader it will also set RobolectricTestRunner's classloader to use the same one

These changes require Robolectric-1.0-RC5-SNAPSHOT. They also require Robolectric to accept my pull request, which they have not done quite yet.

I also added support for H2Map and SQLiteMap, so one may choose which database they want to test against. H2Map is part of Robolectric, but using SQLiteMap requires the robolectric-sqlite dependency.

Example: class mySpec extends RoboSpecs with RoboH2Map class mySpec extends RoboSpecs with RoboSQLiteMap

I have only tested this change with Maven and sbt 0.10.1. Changes to the RoboSpecs sbt configuration are likely needed to compile with sbt 0.7.x. I have migrated my master branch to sbt 0.10.1 if you want to get the updated configuration for sbt 0.10.x pull it instead. Though I have not fully set up the sbt-assembly plugin for sbt 0.10.x.

[jbrechtel]

Hi Chris, thanks for the pull request!

Sorry I haven't gotten back with you about this yet. I'll check it out and merge it in tonight.

[cessationoftime]

Ok, when you test it, keep in mind it requires the changes to robolectric found here: https://github.com/pivotal/robolectric/pull/134

[cessationoftime]

This appears to fail in maven, if scala tests are run first thing. But works if java tests start the run. I dont plan to fix it myself since my project's tests are now fully converted to scala.

[jbrechtel]

Wow this has taken me a really long time to get to. Sorry about that.

The acceptance test example is failing when I merge your master branch. I'm not sure when/where it's happening but it looks like you're trying to setDefaultLoader after it has already been set by Robolectric. I'm thinking the right thing to do would be to just never new up a RobolectricClassLoader and instead just always get the loader from RobolectricTestRunner.getDefaultLoader(). Then we can still share the same instance as Robolectric and avoid any temporal coupling.

How does that sound?

[cessationoftime]

I didn't think it had created the DefaultLoader at that point, but I bet that was the issue and it sounds like that would work. I've actually converted all of my java tests to scala, so it isnt a real issue for me any longer. But it may crop up again for someone else.

[jbrechtel]

Hmm...well it looks like RobolectricTestRunner.getDefaultLoader is private. I could send them a pull request making the switch. It's almost certainly better for them to have a public getter instead of a public setter (or a setter at all for that matter).

Since you don't need this anymore I'm going to just let this sit unless someone else wants it.