Return-Path: 
 <ant-dev-return-13984-apmail-jakarta-ant-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@jakarta.apache.org
Received: (qmail 26742 invoked by uid 500); 22 May 2001 11:49:02 -0000
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
list-help: <mailto:ant-dev-help@jakarta.apache.org>
list-unsubscribe: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
list-post: <mailto:ant-dev@jakarta.apache.org>
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 26644 invoked from network); 22 May 2001 11:48:56 -0000
X-Authentication-Warning: bodewig.bost.de: bodewig set sender to
 bodewig@bost.de using -f
To: ant-dev@jakarta.apache.org
Subject: Re: [DISC] details of task library concept
References: <002501c0e2a9$fcfc56c0$9367883e@viquity.com>
From: Stefan Bodewig <bodewig@apache.org>
Date: 22 May 2001 13:48:55 +0200
Message-ID: <m3lmnpr4d4.fsf@bodewig.bost.de>
Lines: 71
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

Jose Alberto Fernandez <j_a_fernandez@yahoo.com> wrote:

>> From: Stefan Bodewig [mailto:bodewig@apache.org]
>>
>> My preference here is to use an XML file and the syntax one would
>> use in a build file as well, i.e. use <taskdef> to define a task,
>> <typedef> to define a data type and so on.
>>
> 
> I agree with you. And to make it more specific, I would say that we
> also need to allow for the use of properties which can be inherited
> from the including project.

Not sure what this would be used for ...

> That way one can specify other jars or task libs that must be
> loaded.

Why not use the Class-Path header in the Manifest for this (download
extensions)?

>> * Will each task library be loaded with a class loader of its own
>>   to avoid class-name or class-version clashes?
>>
> 
> I think they should follow the current rules of <taskdef> with
> respect to classloaders.  What happens otherwise if I define tasks
> by extending the classes of other tasks defined by other people in
> other task libraries?

Didn't think about that, thanks.

>> * Will each task library be assigned to an XML-Namespace to avoid
>> task-name clashes?
>>
>> IMHO, yes.  Maybe we should use the name of the jar file (without
>> extension) as the namespace prefix.
> 
> I prefer an explicit name assignment.

I was thinking about implicit tasklibs.  If I "import" a task library
into my build system explicitly, having an explicit assignment is
fine.

But we've been thinking about something like an ANT_HOME/ext directory
where all tasks libraries living there would automatically be detected
and added by Ant.  I'm not sure where one would place an explicit
mapping here.

Putting all of them in the default namespace would be possible, but
I'm not sure that this would be the best choice.

>> * The extension of the library file itself.
>>
> 
> I propose that <tasklib> itself does not require a specific
> extention name.

Again, I was thinking about the implicitly loaded task libraries.

>> * We've agreed to store documentation within the library itself -
>> where?
>>
> 
> I think this is way asking too much. How are these documents going
> to be extracted and displayed?

Provide a task that does so - just like <antstructure> walks around
and creates a DTD for all know tasks/types.

Stefan