Internal junit dependency causes issues in OSGI container

[GoogleCodeExporter]

We are using spock in OSGI for integration tests, but there is apparently some 
dependencies on internal junit classes.  Namely:
import org.junit.internal.runners.model.MultipleFailureException

http://www.google.com/codesearch#kd_PCnP8UZc/trunk/spock-core/src/main/groovy/sp
ock/util/EmbeddedSpecCompiler.groovy&q=internal%20package:http://spock%5C.google
code%5C.com

We have sorta worked around the issue by embedding junit within the spock 
bundle and reexporting it but this creates other problems where if another 
bundle exports junit first then its used and internal class cannot be accessed. 

As an additional enhancement it would be great if spock jar included the osgi 
manifest so that it would not need to be repackaged. 

Here is the maven pom file used to wrap spock jar in an osgi bundle.
https://gist.github.com/1044946

Original issue reported on code.google.com by kurtharr...@gmail.com on 24 Jun 2011 at 3:02

[GoogleCodeExporter]

We can certainly add an OSGi manifest. Giving up on using 'internal' JUnit 
classes is unlikely to happen though. Some of these classes are important for 
good integration with JUnit and shouldn't be internal in the first place. Which 
OSGi manifest do you use for JUnit? Can you tweak it?

Original comment by pnied...@gmail.com on 27 Jun 2011 at 7:25

[GoogleCodeExporter]

Thanks, I figured I would post an issue about this on junit to see if they 
agreed that this class should be public and apparently this change has already 
been merged into the master branch back in January.  
https://github.com/KentBeck/junit/commit/4610330ca7fca16df7da1b7d09ea065d071cf9b
8

We are using the junit core bundle from the apache sling project 
http://sling.apache.org/site/downloads.cgi which exports junit in addition to a 
few other classes.  By default OSGI does not export packages contain the 
internal or impl, so spock will not work with any prepackaged bundles one might 
find on springsource or servicemix either.  Rather than repackaging junit to 
make it compatible with spock a better solution to me seems to just embed junit 
into the spock bundle and reexport it until junit 4.9 is available.

Original comment by kurtharr...@gmail.com on 28 Jun 2011 at 4:04

[GoogleCodeExporter]

Thing is, we want to support multiple JUnit version (currently 4.7 and higher) 
and therefore can't switch to the moved class yet.

Original comment by pnied...@gmail.com on 26 Feb 2012 at 2:20

[GoogleCodeExporter]

Is this still an issue for you?

Original comment by pnied...@gmail.com on 4 Oct 2012 at 7:06

[GoogleCodeExporter]

I switched jobs and am no longer working with OSGI so short answer is no.  I 
believe we worked around it by repackaging the OSGI bundle so I don't think it 
will be an issue for them unless they need to upgrade and it seemed as if this 
class was moved in 4.9 so if they upgrade it should probably be non-issue. If 
they did move this the class in 4.9 then that might make it difficult to 
support 4.7 and higher if 4.9 has a breaking change, maybe they moved it back I 
haven't looked so you might want to double check spock actually supports 4.9+ 
if they moved this class.  But in summary, no longer an issue for me as I have 
no plans to work with OSGI again if I can avoid it :) 

Original comment by kurtharr...@gmail.com on 8 Oct 2012 at 4:45

[GoogleCodeExporter]

Please add an OSGi manifest, thanks.

Original comment by sebastia...@gmail.com on 16 Feb 2014 at 12:22