I explicitly exclude TestNG's Guice 2.0 dependency and it uses 3.0 RC2 very happily, which is what you're doing anyway by moving the 2.0 jars to the end of the classpath. I'm also using TestNG's Guice support now it binds all of the modules at once, it's pretty flexible.
Danny ________________________________________ From: Kristian Rosenvold [[email protected]] Sent: Monday, 14 February 2011 7:38 PM To: Maven Users List Subject: Re: Problems with Surefire, TestNG, and Guice 3 The logic that forces testng and its resolved dependencies onto the system classpath of the forked process can be switched off by commenting out the statement in line 1025 of AbstractSurefireMojo.java: public void addProviderArtifactToBootClasspath( Classpath bootclasspath ) throws ArtifactResolutionException, ArtifactNotFoundException { // dependencyResolver.addResolvedArtifactToClasspath( bootclasspath, testNgArtifact ); } If you do this, surefire will stop adding testng to the system classpath of the forked process and you (might?) be able get this to work. Please test this ;) If that is the case, the only remaining problem is to find out *why* TestNG was forced onto the system classpath of surefire initially. This would usually be something about testng or some dependency escaping the confinement of the isolated classloader in surefire. Most of this code is >5 years old and I really doubt if anyone remembers why ;) But we might get lucky, anyone know ? Kristian Den 14.02.2011 08:43, skrev Reinhard Nägele: > Hello, > > We have a project that uses Guice 3 and TestNG for unit tests. TestNG > now has support for Guice (which we don't use). The problem is that > TestNG uses Guice 2. Surefire puts TestNG and its dependencies > (including Guice 2) first in the classpath. This makes our tests fail > because we use Guice 3 features and JSR 330 annotations. > > Interestingly, one workaround – besides using an older TestNG version > that does not have Guice support – is to run Surefire with > forkMode=never. This puts TestNG at the end of the test classpath so > that the project's Guice 3 dependency wins. While this is nice in our > current situation, it is inconsistent. I don't think different > forkModes should yield different test classpaths. > > Any ideas how this could be fixed? I think something needs to be done > on both sides, Surefire and TestNG. > > Here's the corresponding discussion on TestNG's Google group: > > http://groups.google.com/group/testng-users/browse_thread/thread/db58d13ca498bb92 > > > Thanks, > Reinhard > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] This email and any attachments may contain confidential and proprietary information of Blackboard that is for the sole use of the intended recipient. If you are not the intended recipient, disclosure, copying, re-distribution or other use of any of this information is strictly prohibited. Please immediately notify the sender and delete this transmission if you received this email in error. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
