ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject RE: [DISC] details of task library concept
Date Wed, 23 May 2001 10:30:33 GMT
> From: Peter Donald [mailto:donaldp@apache.org]
>
> >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. :-(

> >This is exactly why I want to be able to pass property
> information to the
> >task library.
> >So that they can take local info from the build into
> account. I think it is
> >a good question to ask whether to allow passing/inheriting
> any property, or
> >whether we can come up with a particular subset that makes
> sense. My example
> >is for being able to pass a classpath for project specific
> stuff, but one
> >could say we could have a <classpath> parameter added to <tasklib> to
> >acheive the same. Are there other interesting properties.
>
> task/data/other libraries should not be "configured" in this
> way. I expect
> javac to behave the same regardless of whether where I run it.
>

Tasks today REQUIRE scuch things, javac.exe require such things. You need to
be able to tell the compiler where your libraries are -classpath, and it
also allows for you to tell it where extensins are, where your JDK classes
are, etc, etc. There is no reason why other tasks or group of tasks will not
require the same.

Today we need to set this information at each <taskdef> declaration. My hope
in part was that we could do this at the groupping level of the <tasklib>.

> >My point on the description issue is that I do not think ANT
> should force
> >people to use some particular documentation mechanism or
> standard. Not
> >JavaHelp, nor HTML nor anything else. That should be upto
> the task writer to
> >decide how it should be provided.
>
> 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.

Jose Alberto


Mime
View raw message