ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <DDevie...@lgc.com>
Subject RE: antlib
Date Thu, 24 Apr 2003 14:27:17 GMT
Thanks Jose Alberto for the clear use-case of using the AntLib. I do like it
a lot more now that I understand it better ;-)

> From: Stefan Bodewig [mailto:bodewig@apache.org]
> Sent: Thursday, April 24, 2003 7:04 AM
>
> * antlib needs a way to define mappings between names and classes.
> 
> Costin prefers a properties file.  Most others prefer XML.

+1 to XML

> My argument for XML is the extensibility.  We will need versioning, we
> will need some statement of pre-reqs (like this antlib requires
> log4j), we will need additional capabilities we do not see now.

I'm not fond of this pre-req thing you're describing, for the reason that it
requires to be able to map a pre-req like log4j to an actual jar, which
usually implies a centralized info center of some sort associating a pre-req
name with a given JAR (versioned how? Manifest? In the jar name?).
Versioning if often more than one can chew, and would endanger AntLib. So
for the same reason you want to start with just tasks/types below, I'd
prefer to start *without* versioning.

> Let's make a version of antlib that knows about two predefined roles,
> task and data-type.  I think this is already feature complete in the
> proposal (which does even more).

An AntLib restricted to tasks/types is of no use to me, and I suspect
others... But for the sake of getting AntLib in, I'll follow your pragmatic
approach ;-)

> Let's move this code with the restriction to tasks and types into the
> main branch ASAP.  Let's sort out the classloading requirements as
> well as the interplay of antlib with taskdef and typedef here.

I think classloading issues would be greatly simplified if Ant loaded only
its core in the system CL, and everything else in child AntLoaders. The
current loaderref attribute is enough to deal with having AntLibs sharing
classes IMHO, and can be very easily retrofitter to AntLib. I even think
it's OK to load several time AntLib dependencies like Log4j, if two AntLibs
both depend on them, but were not declared to use the same CL. Keeps
everything simple CL wise, and properly delegating, without going into CL
that dynamically add JARs to lookup classes (I share Connor's concerns about
this), or some graph of loaders (one per jar), or whatever else
(ClassRealm?).

> After this flies, I'd expect us to get roles sorted out.  If we feel
> like removing the difference between tasks and types, we can do so
> then as well.

BIG +1 to getting to roles quickly ;-)

Overall, I agree with Stefan that we are all real close on the principles
discussed in this thread, and their tremendous value to Ant. It's more the
actual rolling out of this new functionality that's problematic.

If I had only one feature I wanted out of Ant 1.6, I'd pick AntLib, even
over <import> (partly cause I have a flexible resource: based XML entity
include system). So a BUG (non-binding ;-) +1 to AntLib getting into Ant!

--DD

Mime
View raw message