ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/types
Date Sat, 29 Dec 2001 05:31:21 GMT
On Wed, 26 Dec 2001 06:50, Magesh Umasankar wrote:
> Hi,
> >   Modified:    src/main/org/apache/tools/ant
> >   Added:       src/main/org/apache/tools/ant/types
> >               
> >               
> >   Log:
> >   IntrospectionHelper has been modified such that overridden setter
> methods
> >   that take in 'PreferredAttribute's as argument gain higher precedence.
> >   New attribute types - SrcDir, SrcFile, DestDir and DestFile are
> introduced.  Each of these types is a PreferredAttribute.

Justa note that I would prefer that changes like this be discussed before 
they get done or at least implemented in a proposal branch first.

> A lot of the tasks that we have perform one validation or another before
> performing the actual execution.  One such validation that is commonly
> repeated is the check to see if a file exists, if it is a directory, or if
> it is a
> file, etc.  These are the common rules that most of the tasks check:
> 1. Src File must exist and must be a file.
> 2. Src Dir must exist and must be a directory.
> 3. Dest File may not exist, but if it does exist, it must be a file.
> 4. Dest Dir may not exist, but if it does exist, it must be a directory.

Yep - validation is some that needs factoring out but I am not sure this is 
the way to do it.

> These new classes encapsulate this validation thereby minimizing
> the validation code that the task writer has to write.
> I have modified IntrospectionHelper such that it stays backwards
> compatible while at the same time takes advantage of the newly
> introduced 'PreferredAttribute' mechanism.  I look at PreferredAttribute
> as a stop gap measure till Ant2 is released at which time, this may go off,
> as we wouldn't be backwards compatible anyway.
> There are a lot of tasks that currently take in File as argument to the
> setter methods.  I will be refactoring these shortly, such that they take
> in ValidatedFileAttributes as arguments.
> The concept of validation here is somewhat similar to EnumeratedAttribute.

Type and validation of type are different concepts and shouldn't be merged 
together. There should be a method that allows validation to be extracted 
outside the task but I don't like the way that you do it. For example lets 
consider that there may be N different types. Each instance of a type may 
have M rules applied to it. Thus under your system you could potentially have 
N x M objects!!!! I would much prefer to have just M objects that could be 
composed together - much more manageable ;)

Heres one way of "fixing" this - maybe to wait till Ant2. Lets call the 
objects that do checking "Validators". Each time we call a setter for either 
an attribute or an element we call an associated chain of Validators (chain 
may be null in which case zero validation occurs). 

The chain of validators is built up by looking at the TaskInfo object - which 
lists all validators that must be run etc. Because writing the TaskInfo 
object would be monotonous we could have them automagically generated based 
on comments in javadocs for the setters. ie. Something like

 * ...
 * @validator org.apache.ant.validators.SourceValidator
void setSrc( File src )

This would mean much less objects required to do validating and so forth and 
should be relatively easy to implement by Task writers (not so easy for us 



 Beer is proof that God loves us and wants 
 us to be happy. -- Benjamin Franklin

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

View raw message