ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@bost.de>
Subject Re: [RFE] Richer Task Specification
Date Wed, 14 Jun 2000 10:55:35 GMT
>>>>> "PD" == Peter Donald <donaldp@mad.scientist.com> writes:

 PD> What I would like is some method of knowing how to preprocess
 PD> properties so that they are in form task wants.  [...]  This
 PD> would also mean it would be possible to have properties that are
 PD> not strings and in fact could effectively be any Object.

Peter, take a look at spec/core.html. Some things you want are already
there, some things have been discussed and even been agreed on but
unfortunately the document hasn't been updated to reflect this.

Basically it has been agreed that project properties as well as task
attributes should be richer objects not just plain strings. The way to
go for attributes (IIRC) was to use classes with a constructor taking
a String object as its only argument.

Say you have a task Foo with an Attribute named bar of type Baz then
you would need:

public class Baz {
    public Baz(String value) {...}
    ...
}

class Foo extends Task {
    ...
    public void setBar(Baz value) {...}
    ...
}

and the conversion would be done automatically. Additionally simple
types could be used as well. I can't remember whether there has been
agreement on how to get the same functionality for project properties.

So this approach is similar to your Converter idea but without the
need for a registry. I realize it is more limited in one way, that is
you can only convert from String - but that seems fine to me as the
values are going to be specified in the build.xml file as strings.

I don't know what to do with the processing part of your idea
though. I view this as very tightly coupled to the task at hand in
most cases - with the exception of file lists maybe, but then using
DirectoryScanner seems a reasonable approach to me. I'm not convinced
that moving the processing out of the individual tasks into Ant's core
would be a good idea.

 PD> Request 2:

 PD> Would it be possible to have a bunch of standard ant properties
 PD> in Tasks that effect project in other manners.

We should have properties that are named and used in the same way
across different tasks. Other than that I don't think I understand
what you mean. 

Your example would be tied to the Javac and maybe the Java task, so
let's make sure they use the attribute classpath consistently.

 PD> Request 3:

 PD> This would allow a single build file to compile the taskdefs it
 PD> needs and then use those in turn to do further processing.

That is you want to build the Task and use it in the same build file,
right? I've never thought about doing something like this
myself. Maybe you are trying unusual things 8^)?

 PD> Request 4:

 PD> A standardised set of taskdefs for invoking standard C/C++ tools

I think after Ant has settled there will be some kind of library for
optional tasks - hopefully somewhere under the Jakarta umbrella but
not necessarily in the same repository. I view things like this as
prime candidates for "standard optional tasks" i.e. optional tasks
with an implementation from the Ant developers.

A draft on how to handle optional tasks in future versions of Ant can
be found in spec/core.html again.

Stefan

Mime
View raw message