Danny, could you explain what exactly you did? I tried that too but was
not successful. Guice 2 does not show up in the dependency tree anyways,
but Surefire still adds it.
Thanks,
Reinhard
Am 14.02.2011 10:51, schrieb Danny Thomas:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
