Return-Path: 
 <ant-dev-return-18240-apmail-jakarta-ant-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@jakarta.apache.org
Received: (qmail 26953 invoked by uid 500); 10 Oct 2001 01:52:23 -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 26942 invoked from network); 10 Oct 2001 01:52:22 -0000
Content-Type: text/plain;
  charset="utf-8"
From: Peter Donald <donaldp@apache.org>
To: ant-dev@jakarta.apache.org
Subject: Re: Optional tasks
Date: Wed, 10 Oct 2001 11:43:52 +1000
X-Mailer: KMail [version 1.3.1]
References: <HGEEIKOHHDJKIOMBLAAEKEBOEEAA.tneward@javageeks.com>
 <00d001c150b9$27705690$0100a8c0@jose>
In-Reply-To: <00d001c150b9$27705690$0100a8c0@jose>
X-Wisdom-Cookie: .
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <20011010015202.EWCU13193.mss.rdc2.nsw.optushome.com.au@there>
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

On Tue, 9 Oct 2001 21:54, Jose Alberto Fernandez wrote:
> I also prefer the manual declaration of the libraries being used as opposed
> to some auto-install sort of facility. The reason for this is my believe
> that is much better to document in the buildfile which resources are
> required than to assume that every user will find out by other means.

+1000 ;)

> Once you accept this there is no reason to enforce that libraries are
> located in some especific place, they can be anywhere including a remote
> location. ANT may provide a convinient location (${ant.lib}) but it should
> be just that a convinience.

Sounds like a type.lib.path to me ;)

> The next question is how this libraries interact with ClassLoaders. Should
> each library have its own ClassLoader? 

+1

> Should they be able to share them?

-1 the contract of tasks is at XML/TaskModel level and we shouldn't need 
interaction *unless* you inherit from one. (ie extend zip to create war or 
similar). These however can just be considered an "external library". This 
means in a few rare cases we will load certain task classes in multiple 
ClassLoaders but as they can't interact with each other this should not be a 
problem.

> How about external libraries being required? 

I think we should go with the standard java mechanisms for "Optional 
Packages" (see jdk1.3 docs) combined with the ancient Class-Path: foo.jar 
approach. This is what all new APIs are moving towards and is fairly 
flexible. About the only irritating thing is that there is no standard to say 
2.0 is incompatible with 1.0 version of same library ;(

> Shall one be able to specify
> an additional ClassPath for the library?

besides above I would be -1

> <tasklib name="lib1" location="mydir/mytasks.jar" />

I am also -1 on specifying location. We should just give name of library and 
it can be searched for on type.lib.path or whatever.

-- 
Cheers,

Pete

*--------------------------------------------------*
| Wise men don't need advice. Fools don't take it. |
|              -Benjamin Franklin                  |
*--------------------------------------------------*