didge wrote:
There's nothing that I know of in the JDK to search a path consisting of urls by patterns and certainly there is no help in the ClassLoader and Package APIs for discovering classes. I thought that you might be able to hack on the funny RMI classloader, but since it sounds like it delegates to another classloader, it too is probably insulated from the actual file system where resources are located.
I think you are going to have to either: 1. Tell the JUnit runner explicity which test classes to execute, or 2. Provide the JUnit runner network access to the file systems, perhaps through http, ftp, nfs, or samba, so it can resolve and search urls itself, or 3. Copy all resource local to the JUnit runner, a la GUMP.
Personally, I like the first approach better because it allows you to have multiple, disributed JUnit runners work in parallel.
the current impl does let you list classes to run
classes [ "test.test1","test.test2" ]
i just wanted to replicate the **/*Test.class trick.
Maybe later i'll resort to one of the others.
Actually, the trick would be to decouple it; have something that builds up the list of classes to execute (say on a machine with access to the jar/raw files), then feed that list in to the subsidiaries. Hmm..
Imagine an ant task the uses a fileset to find all of the **/*Test.class files (ie the test classes) and uses a registry to find or ssh to launch distributed JUnit runners with which to distribute those test classes. The ant task would also have to provide each JUnit runner with a suitable classpath so that the JUnit runner would be able to access any other resources it needs to execute the test. Finally, the ant task collates the results into a final report and mails it off.
This isnt really ant so much as a deployment framework that runs standalone or under ant, whose aim in life is to get code to remote machines (securely) and run it. remote JUnit execution is something that it enables, which could be very cool indeed.
As an aside, this seems a bit of a failure of classloaders/introspection if you cannot ask questions about the system "what clases are under this package", "what packages are here", etc. It looks like .NET's System.Reflection does have a stronger notion of enumerating assemblies for modules, modules for types, etc.
-steve
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
