----- Original Message -----
From: "Stefan Bodewig" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, February 20, 2002 09:07
Subject: Re: We need to stop the lies


> Cool subject line 8-)
>
> On Wed, 20 Feb 2002, Jose Alberto Fernandez <[EMAIL PROTECTED]>
> wrote:
>
> > In <style> it says that you can use any processor you like by
> > specifying it in method and pitting it in the <classpath>
> > element. IT DOES NOT WORK UNLESS IT IS IN THE CLASSPATH AND YOU DO
> > NOT USE optional.jar.
>
> it does not work unless it is in the CLASSPATH *or* you remove
> optional.jar from ANT_HOME/lib, no?
>
> I'd rather add a FAQ.

How about adding a page to the docs 'all about ant and classpaths' to
explain

-how we autoload stuff in the lib dir
-why JRE ext directories are trouble
-why you cant add stuff later on and have parent stuff find it

> On second thought, now that the distribution contains optional.jar and
> doesn't need to be downloaded separately: What do people think of
> breaking optional.jar into several pieces cut along the dependencies,
> optional-junit.jar, optional-trax.jar and so on.  That way we can tell
> people that xalan.jar and optional-trax.jar must be in the same
> classpath, either both in CLASSPATH|ANT_HOME/lib or none of them but
> both in the nested <classpath> element of <style>.

I seem some value in this; but we should start by dropping 'optional' as
they are less optional now; give them names like ant-tasks-trax
ant-tasks-junit.

We'd need to sort out which tasks come in which jar, and be consistent. What
if we suddenly discover that some task now needs an extra jar (like
httpclient)? and how about something (mimemail) that needs j2ee or mail and
activation

ant-tasks-j2ee-or-activation-and-mail.jar?




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to