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
external.org.apache 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.
${ant.home}/lib
${user.home}/.ant/lib
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.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
