ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: [Proposal] myrmidon
Date Wed, 06 Dec 2000 08:08:29 GMT
Peter Donald <donaldp@apache.org> wrote:

> At 05:11  5/12/00 +0100, you wrote:
>>Peter Donald <donaldp@apache.org> wrote:

>>Two minor details I wanted to note: (1) Currently you can specify
>>both, if and unless attributes to Target, any reason why you've
>>restricted that? (2) I've proposed to perform ${} expansions in the
>>attributes of project and target as well, maybe you should move the
>>resolution of properties out of TaskletContext into a class of its
>>own - or maybe use project's context which is a TaskletContext.
> 
> right - I am not sure I like ${} resolution in if/unless attributes
> thout it could be done.

The main thing that could benefit from added ${} resolutions are
things like project's basedir where you might want to expand the
system property user.home. And then I think it would be nice to have a
consistent rule, something like ${} will be expanded in _all_
attributes.

>>> Currently there is some things that will not evaluate ${} inside
>>> it (ie includes in filesets)
>>
>>They don't?
> 
> they didn't when I forked not sure about now ;)

I think you are wrong. ${} will be expanded for all attributes of
everything except <project> and <target> right now - and this has been
true when you forked of your code, believe me - as it even worked that
way before Ant 1.1. There has been a bug report because patterns
inside the file you can specify with the includesfile attribute are
not resolved - maybe you are mixing these issues.

>>> The tasks and converters for the job will be loaded from
>>> proposal/myrmidon/dist/lib/core.tsk. You will notice that there is
>>> extremely simple meta-data in "TASK-LIB/*.properties" of core.tsk.
>>
>>Make that an XML file, pleeeeease ...
> 
> ;) The converter one will definetly got to xml - but is there any
> need for changing taskdefs.properties to an xml file ?

Well, if I want to specify defaults for attributes or choose a
specific implementation of a given task (jikes in the javac case). I'd
love to get rid of magic properties, as you might know.

I envision you'd use a <taskdef> like syntax in that XML file. Why
have two ways to define a task, <taskdef> and a properties file? Let's
use the <taskdef> mechanism in the tasklibs as well.

Stefan

Mime
View raw message