ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/types
Date Sun, 30 Dec 2001 07:15:43 GMT

----- Original Message -----
From: "Peter Donald" <>
To: "Ant Developers List" <>
Sent: Friday, December 28, 2001 21:31
Subject: Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/types

> >
> > 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
> 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
> > 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
> > in ValidatedFileAttributes as arguments.
> >
> > The concept of validation here is somewhat similar to
> 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
> N x M objects!!!! I would much prefer to have just M objects that could be
> composed together - much more manageable ;)

I retrofitted <loadfile>, which only went in last week. The SrcFile trick
makes coding easier, but it makes it hard for me to implement the "dont
raise an excepto in failonerror=false", which is what I had originally
implemented. So, if anyone had used the task we would have changed behavior.
Actually we have broken the docs and (a now commented out unit test), so the
change did effectively break things.

So we have a problem
 -the new datatypes do simplify task implementation
 -but they remove much of the flexibility of implementation

The failonerror semantics is an issue; unless the introspection helper calls
getFailOnError() methods implemented in tasks it wont know the failonerror
status, and even then we would need datatypes which differentiate
"OptionalSourceFile" and

> 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
> an attribute or an element we call an associated chain of Validators
> may be null in which case zero validation occurs).
> The chain of validators is built up by looking at the TaskInfo object -
> lists all validators that must be run etc. Because writing the TaskInfo
> object would be monotonous we could have them automagically generated
> 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
> should be relatively easy to implement by Task writers (not so easy for us
> though).

I am +1 on metadata. Personally I think the md. associated with an attr
should be very detailed:

  * @since 1.9
  * @ant:attribute set the dir to use
  * @ant:default current dir
  * @ant:optional
  * @ant:validator org.apache.ant.validators.SourceDirValidator
 void setSrcDir( File src )

However, the metadata derived validators still cant
 -probe failonerror status
 -let the task spec their own error message
and any other task specific stuff

A simple validation alternative is to have one or more validator classes
with methods

interface Validates {

class BasicValidator implements Validates {

    private Task owner;

     * @pre owner!=null;
    BasicValidator(Task owner) {
        this.owner = owner;

    public void validateSrcFile(File f) throws BuildException {
        validateSrcFile(f, "file {0} not valid, cause {1} ");

    public void validateSrcFile(File f, String message) throws
BuildException {
        validateSrcFileWithFailOnError(f, false, message);

    public boolean validateSrcFileWithFailOnError(File f, boolean foe,
String message) throws BuildException {
        // do the test,
        if(!f.exists()) {
            String errortext;
            //build an error string w/ java.text

            if(failonerror) {
                throw new BuildException(errortext, Task.location);
            } else {
                Task.log(errortext, Project.MSG_ERR);

    public void validateSrcFileOptional(File f) throws BuildException {

    public void validateSrcFileOptional(File f, String message) throws
BuildException {


then in a task usage would be

BasicValidator validator=new BasicValidator(this);

  * @since 1.9
  * @ant:attribute set the dir to use
  * @ant:default current dir
  * @ant:optional
  * @todo do something with this param
void setSrcDir( File src ) {
   validator.validateSrcFileWithFailOnError(src,failonerror,"We cant use
file {0} because of {1}");

So the effort of a task is fairly minimal, you state in code what you want,
not metadata but get to pass in current state in the process.

This is *very* easy to start adding...

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

View raw message