On 11/13/00 5:27 PM, "Sam Ruby/Raleigh/IBM" <[EMAIL PROTECTED]> wrote:
>> My involvement in this project is going to change
>> substantially over the next few months. Yes, I've
>> tried to do this before and failed. However, this
>> time *will* be different.
>
> Yea, right ;-)
:) Yeah -- I deserve that.
>> Solidification of the Project/Target/Task hierarchy. This is the
>> core of Ant's model and it should be explicitly locked.
>
> Please consider another layer above project ... it would be nice to compose
> a system out of projects. Example: Tomcat implements ServletAPI and
> requires a project that implements JAXP. One could even imagine encoding
> "default" choices ...
Ok. I'll mix that into the thought process.
>> A clear definition of how scripting (external or inline CDATA)
>> can be used with Ant through the Task interface -- keeping scripting
>> clearly separate and yet making Ant infinitely malleable to scripts.
>>
>> A clear mechanism for providing tasks as source code and compiling
>> them on demand into tasks that can be used with the current project.
>
> One should also be able to *define* tasks in scripting languages.
Yep. When I say that the data model should be exported to tasks (which can
be reflected to scripts through tasks), I should also say that I think that
the model should be fully plastic to those tasks (and the scripts that are
run through tasks). This means additions, subtractions, and modifications to
tasks, targets, properties, etc.
Given that ability, it becomes easier to write an "AntConf" like tool that
has scripts test for certain things, output a final ant build file based on
the modified object model, and go.
--
James Duncan Davidson [EMAIL PROTECTED]
!try; do()
