>>>>> "PD" == Peter Donald <[EMAIL PROTECTED]> writes:
>> Maybe I've misunderstood your proposal.
PD> Nope. Your right there.
I was afraid I would be.
For those "other tasks", those not extending AbstractTasklet, would
you want scripts to be able to work on them - setting/getting
attributes? Or would you want the user to be aware that there are two
kinds of tasks, those that you could manipulate and those you could
not?
>> One thing you miss here IMHO is that the same problems - setting
>> of attributes, creation of nested elements, validation of
>> attributes - holds for all the other objects corresponding to XML
>> elements in the buildfile as well.
PD> true :P but the validation I was wanting to use is very very
PD> specific and not really general like a dtd/schema etc.
Oh, but I'm talking about this simple validation. Let's assume we have
a fileset attribute like the one Arnout has described:
<jar file="jarfile.jar">
<fileset dir="dir1tojar">
<include ... />
...
</fileset>
</jar>
Then you will certainly find
if (dir == null) {
throw new BuildException("dir attribute must be set on filesets");
}
in whatever represents filesets.
This is exactly the kind of validation you want to put into
AbstractTasklet, isn't it?
I'm not saying that a Validator class of some kind would be useless,
quite the opposite. But put it to good use for the nested elements as
well.
Stefan
