----- Original Message -----
From: "Magesh Umasankar" <[EMAIL PROTECTED]>
To: "Ant Developers List" <[EMAIL PROTECTED]>
Sent: Sunday, December 30, 2001 18:06
Subject: Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/types
> From: "Peter Donald" <[EMAIL PROTECTED]>
>
> > 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.
Well, that bit of info does not need need to be used by the container, but
it could be used to generate a DTD or XmlSchema for use in an editor (this
does not mean that ant will be DTD bound, it cant do that and be extensible,
but you could introspect through the classes' MD and generate a DTD for the
current class set.
And it could be used by the documentation. There is no real need for us to
have this split between javadoc generated docos and hand HTML docs if we
move more to the javadocs. This would make it easier to keep the html docs
up to date.
>
> 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
> way.
>
> public boolean isSrcDirOptional() {
> if (srcFile == null) {
> return false;
> } else {
> return true;
> }
> }
The code I write (check sandbox/http) moves all validation into a method
called validate() that the subclasses can (and do) extend/override, you can
always call the old thing if you want. It also puts all task implemented
testing into one place, which makes it easier to see the rules at a glance,.
> 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.
I agree.
One of the issues with MD in java is that only one javadoc tag,
'@deprecated', gets into the class file. the .NET story of metadata is much
better; MD is associated with classes, fields, interfces methods and
packages...etc, and the introspection API lets you find out about the
metadata. Plus you can write new metadata constructors really easily. Java
is behind here, even if the class file is probably powerful enough to take
this stuff on board (I am not even aware of a JCP working on this yet tho').
What we do have today is xdoclet task; find it from the ant resources page;
which is a javadoc doclet that takes an xml description of the doc comments
you expect and can generate stuff from it, like an xml descriptor. It can do
EJB and struts descriptors already; once we ever decide on an ant
descriptor, we just patch in the tags to all our tasks and run with it.
Course we still need to support all those external tasks without it .
>
> 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...
There does seem some merit in this, but I'd like to emphasise my preference
that in future interfaces are used to specify what you implement, rather
than just well known names. Your failonerror example seems aligned with it.
> This way, we do not also need the new tool to
> preprocess special tags embedded as comments.
Agreed, but xdoclet exists already; the most work is in a) getting consensus
on what to do and b) patching the tasks.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
