Mailing-List: contact user-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Users List" <user@ant.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C4983A.FC7981B5"
Subject: classloading, ant, junit, more advanced question
Date: Sat, 11 Sep 2004 14:07:38 -0600
Message-ID: 
 <676171B29CCEA84FBE05EEA11935AE63046CADFA@cof110avexu1.global.avaya.com>
Thread-Topic: classloading, ant, junit, more advanced question
Thread-Index: AcSYOvxMWpqsfB+WQJydjWs9VkoB2w==
From: "Hiller, Dean D (Dean)" <dhiller@avaya.com>
To: <user@ant.apache.org>

------_=_NextPart_001_01C4983A.FC7981B5
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

One thing I get really nervous about is always having a junit.jar in
ant/lib and then one in the project itself so the project compiles.  I
know, I know, classloader stuff.  But I had a suggestion around some of
that, and I think I have seen similar comments.

=20

I only suggest this as I wrote an xml scripting framework that is more
dynamic than ant(I didn't have the backwards compatibility baggage
making my job much easier).  Trying to open source this through my
company, but that is another story.

=20

Here is how my dream ant would work

1.	junit would have an ant task and have some standard file
ant/resource.xml and other jars could have the same file
2.	junit is dropped into ant/lib or put in ant's classpath, or via
a taskdef loaded in.
3.	ant seeing this jar with a resource.xml automatically loads it
in a different classloader(it has to actually otherwise it may get the
resource.xml from a different jar on accident).  It then configures
itself and works.

=20

4.	The other option is someone does a taskdef with an attribute of
jar=3D"junit.jar" They don't need to even know the classnames of the =
tasks
in the jar.  That is all defined in the resource.xml. =20

=20

I have done this on a very similar scripting xml framework(I looked into
jelly, but jelly didn't offer asynchronous tasks).  This seems to work
fine and would seem to solve your problems with the worry about users
having a hard time.  It would be quite simple.  Drop your junit.jar into
ant/lib, or in the classpath, or define <taskdef jar=3D"junit.jar"/> in
the build file.  Either way, junit.jar would be loaded in a separate
classloader.

=20

You may be wondering, but wait a second, you put the junit.jar on the
classpath.  That means it is now already loaded in the parent loader.
Well yes, BUT what my framework does to get around that is reload the
same framework in another classloader that doesn't have a parent.  Then
I take each and every jar off the classpath and load each in it's own
classloader getting a reference to it's resource.xml file.  Basically,
no matter which of the three mechanisms are used

1.	junit.jar w/ant task inside it on classpath
2.	junit.jar w/ant task inside it in ant/lib
3.	junit.jar w/ant task insitde it defined in <taskdef
jar=3D"junit.jar"/>

It is loaded in a separate classloader and the task and junit library
are together.

=20

Hopefully, I can drive the open source of this scripting framework
through, and some could take a peak if they were curious. =20

Thanks,

dean

=20

=20

=20


------_=_NextPart_001_01C4983A.FC7981B5--