Great! Sorry for thinking your patch was the culprit then ;)
The biggest issue seems to be that you can't allow a test class to get loaded up into the class loader unless the provider (ie testng) classes are also loaded up first...This is because the test class may actually instantiate properly, but without the annotation definitions in the testng.jar none of the annotations will be found. (Ie you can't call Method.getAnnotation(Test.class) and have it not be null) I am glad you are depending on it now as well :) I have a few other changes that I've started to lose track of since last uploading those patches. It's also been a couple months (little over I think) now since the problem first came about, so it's easy to see why the community might be grumpy. I know I'm able to fix and deploy tapestry bug fixes via the new whizbang maven2 snapshot repos now. For the testng developers, where if bugs are found they are almost immediately responded to with same/next day fixes I'm starting to look like the black sheep leaving all of our maven2 users broken for months on end... On 9/3/06, Fabrizio Giustina <[EMAIL PROTECTED]> wrote:
Hi Jesse, first of all thanks for your patches for the surefire TestNG provider and for your help here... I recently moved to TestNG for a couple of projects and I will definitively try to make surefire support more robust. I committed a few long standing patches, but the commit for http://jira.codehaus.org/browse/SUREFIRE-53 it's probably not the culprit for the problems you see (that patch just assure that the original classloader gets reset after running surefire). So that should depend on a previous change by Kenney: http://svn.apache.org/viewvc/maven/surefire/trunk/surefire-booter/src/main/java/org/apache/maven/surefire/booter/SurefireBooter.java?r1=427040&r2=438999&diff_format=h This was the comment: "Set parent classloader to null for the testsClassLoader. If this is not done, the System classloader is added, in this case an AppClassloader containing everything in the root classpath. For instance, in maven, everything in core/ is available.This can cause clashes with the plexus-utils used in maven itself." So looks like there was a different reason for doing that... but we could rethink at it if it brokes more than what it fixes. I just realized that this actually broke my projects using TestNG, although the tests in the surefire testng provider work fine. I'll try to reproduce this behaviour in a test, then we will try to understand how to definitively fix it: any help will be appreciated, and I promise that patches will not stay waiting in Jira for long anymore... fabrizio On 9/2/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > Applying the patch mentioned has made running annotation based testng tests > b0rken. Ie before it was loading classes using a context of system class > loader. I've fixed this locally by calling createClassLoader(classpathurls, > childdelegation, true) (which uses system class loader by default) instead > of createClassLoader(classpathurls, null, childdelegation, true). > > The recent application of old patches is definitely appreciated, but things > like this make me nervous for the future. There ~has~ to be a reasonable way > to run unit tests against surefire that assert things aren't broken...The > logic of classloader dependencies is too fragile to not have tests... > > Sorry, I shouldn't be telling you guys what to do.. > > -- > Jesse Kuhnert > Tapestry/Dojo/(and a dash of TestNG), team member/developer > > Open source based consulting work centered around > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
