Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Message-ID: <40ADCB67.9090108@iseran.com>
Date: Fri, 21 May 2004 10:27:03 +0100
From: Steve Loughran <steve_l@iseran.com>
User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502)
MIME-Version: 1.0
To: Ant Developers List <dev@ant.apache.org>
Subject: Re: enumerating all classes in a package
References: <PLEALDNHOKIEMPNFNNDDMEOIFLAA.didge@foundrylogic.com>
In-Reply-To: <PLEALDNHOKIEMPNFNNDDMEOIFLAA.didge@foundrylogic.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org