ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: The good ol' JUnit problem
Date Tue, 08 Nov 2005 10:11:17 GMT
Jon Skeet wrote:
>>This is a similar issue with the xalan classes in the 1.4 jdk. 
>>they're exposed directly by sun (and other jvm's) as org.apache.*. 
>>basically they just imported xalan and possibly other apache 
>>classes into the jvm.  this gives your entire application 
>>(jvm) one chance to override the version used by using the 
>>extensions folder.  not very good when you have multiple web 
>>applications that each need a specific version of xalan or 
>>what not.  i believe sun has fixed this issue in
>>1.5 jdk's with a method similar to what i did to get optional 
>>ant tasks work w/o modifying the target environment.
> <snip>
> Thanks - I'll bear it in mind as an option. I think for the moment it'll
> be easier just to copy junit into place and accept that the very first
> build on a clean system won't work (or will need to bootstrap itself
> somehow).
>>it's nice that ant provides tasks for things they can't or 
>>won't bundle with their distribution, but i would really like 
>>to see ant distributed at least with the same tasks able to 
>>be defined externally.  i'd be more than willing to help with 
>>this.  what i would envision is ant providing in addition to 
>>it's ant/lib folder, a ant/lib/external folder or perhaps an 
>>ant/external/lib folder that contains the same tasks in an 
>> name space.  this external lib folder 
>>would not be loaded by the default ant classloader, but would 
>>be available for users to include libs as
>>needed.    i don't like much the <scp> .vs. <m_scp> issue, and it
>>would be very nice if both taskdefs could define a <scp> or 
>><junit> task w/o any collision.  i'm not sure how that would work.
> I think if Ant provided a property for its "home" location (it doesn't
> now, does it? I suppose ${env.ANT_HOME} works, but it's hardly neat),
> that's all that would be required. Have the jar files somewhere they're
> not loaded by default, and we could easily taskdef using a classpath
> which included the right libraries.


> Perhaps there should be multiple distributions, even - one "bundled" one
> and one without any of the optional tasks. Obviously it's easy enough to
> modify a distribution so that it doesn't have things, but for ease of
> upgrade, being able to take a "stock" distribution is important.

fetch.xml in the cvs head bootstraps in maven2's library tasks and uses 
that to retrieve other things.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message