Here's the JIRA:
http://jira.codehaus.org/browse/SUREFIRE-699
Thanks,
Reinhard
Am 14.02.2011 13:49, schrieb Kristian Rosenvold:
A jira sounds nice. I will probably change this to apply only for
guice [3.0), just to avoid creating regressions.
In other words, don't worry about the patch.
http://jira.codehaus.org/browse/SUREFIRE
Kristian
Den 14.02.2011 12:42, skrev Reinhard Nägele:
Thanks, Kristian, for the hint. I commented out the line as you
suggested. This fixed the problem. Surefire still builds successfully
and all test run. I think it does not make sense anyways to have
TestNG (or JUnit) on the system classpath. Should I create a JIRA
ticket and attach a patch?
Reinhard
Am 14.02.2011 09:38, schrieb Kristian Rosenvold:
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]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
