ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: [DISC] details of task library concept
Date Wed, 23 May 2001 11:37:54 GMT
> From: Peter Donald []
> At 11:30 AM 5/23/01 +0100, Jose Alberto Fernandez wrote:
> >> From: Peter Donald []
> >>
> >> >So, how do I refer in the jar Class-Path to a jars and
> >> derectories relative
> >> >to my build directory?
> >>
> >> you don't
> >>
> >> >Or are you telling me that <tasks> in libraries
> >> >cannot use anything that resides on my projects directory
> structure?
> >>
> >> yup.
> >>
> >
> >Well I guess we will have to get rid of the SQLExec task.
> >Since we won't be able to tell it where to find the several
> JDBC drivers
> >I need to test againt. :-(
> nope. It will be configured just like all task attributes.
> One of our goals
> was to eliminate things like this. So just like you are able
> to configure
> the java compiler to be jikes/modern/classic you will be able
> to configure
> task so it uses mysql/db2/oracles jdbc driver.

How do you find the classes used in your task's code. Today there are plenty
of tasks that make calls or inherit from the classes of other tasks: <java>
uses the code from <exec> when fork="yes". And plenty more examples. There
is no reason to forbid a task developer from calling in their tasks, other
tasks provided in other libraries. You will have to be able to especify
where these other classes are when you load the classes for the new task,
and not when you configure the task.

> >> why not. Javadocs works well, is relatively universal and I
> >> think java is
> >> better off with it. Much like ant will be better off with antdoc.
> >>
> >Javadoc, has an entire dedicated development team. I do not
> want jakarta-ant
> >to become a documentation-tool group. We need to be focus. I
> do not want to
> >be on endless discussion and bug fixes about antdoc not
> generating correct
> >PDF files, or about how can I add a multiline copyright
> statement on every
> >screen, "my logo does not show up as I want", etc, etc.
> There are plenty of
> >other projects tackling those issues.
> This has nothing to do with that sort of thing. We define a
> simple DTD and
> they get to transform it in any way they want to using
> whatever method they
> feel like. We don't have to support anything but our core transformer.

Transformation only help for the fixed info or the look&feel. But we would
have to define maintain, etc, the basic things people need to be able to
specify. It is just like javadoc "param" and "exceptions", and "the short
one liner description" and "the long elaborated description", and how do I
*emphasize this" and so on.

I think it is the wrong sac of beans for us to be spending time at. But hey,
I have no veto power ....

Jose Alberto

View raw message