ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Magesh Umasankar" <>
Subject Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/types
Date Mon, 31 Dec 2001 02:06:27 GMT
From: "Peter Donald" <>

> Whats not straightforward about that?

I feel it is not straightforward because it brings in
the concept of a new 'preprocessor (?)' tool to
generate the required code.  I will try to illustrate below
why having methods instead of  meta data will be
more powerful as well as straightforward.

> > Can't we instead introduce methods like getSrcDirValidator,
> > getSrcDirAttribute, getSrcDirDefault, isSrcDirOptional, etc?
> Im not sure how that is easier.

It is not just a question of easiness.  I feel we need to
factor in flexibility also.  For example, let us consider
the scenario where we have the metadata tag suggested
by Steve.

* @ant:optional 

Here, all we can say is that this attribute is considered
optional and if this method hasn't been invoked by the
Introspector, it is OK.

It is not always so straightforward.  An attribute may
be considered optional if another attribute is defined.
For example, let's say task <foo>'s dir attribute *may* be
specified if and only if the file attribute is not specified.
If we choose the alternative 'method based' approach 
instead of meta data, it will let the task writer use the 
expressive power of the Java Language.  Using methods, 
the above problem can be easily solved in an uncomplicated

public boolean isSrcDirOptional() {
    if (srcFile == null) {
        return false;
    } else {
        return true;

While this is a trivial example, there might be much more
processing logic involved - like checking to see if
a fileset has been defined, etc.  So, embedding all
these 'rules' in meta data will be tougher on the
task writer because of extra learning involved, asuming
we can come up with a nice syntax to express all these
in meta data comments.

Ant's introspection mechanism would start invoking
attribute validators and corresponding setters in pairs.
After exhausting them, it will start making checks to see
is those attributes which are not 'optional' are set by
invoking the isXXXOptional() methods...

This way, we do not also need the new tool to
preprocess special tags embedded as comments.

All IMHO, of course.

> Pete


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message