After thinking about this for a while I think it is the best approach to go
the introspection way first without blocking the xDoclet way, because of the
following:
1. Direct Introspection works for all tasks and types "out of the box" quite
"well"!
Certainly. And this is essentially what XDoclet is doing too. As long as you're using IntrospectionHelper and some of the same tricks to get the values for EnumeratedAttributes then you'll get everything XDoclet does (I think?) except for documentation, with some exceptions. There actually are some setters (maybe even creators/adders) that are in the code that are not meant for public consumption and hence are not documented in Ant's documentation. Look for
@ant.attribute ignore="true"
In Ant's current source code and you'll see what I mean. Of course, XDoclet takes these into account and excludes them. This will likely trip you up if you only use introspection.
3. A reason to stick to introspection for a while is, that not "all" ;) Tasks and types have xDoclet tags in them!
In Ant's source code they do, or at least I think they do. Its not necessary for "well-formed" (i.e. straightforward, clean) Ant tasks to have XDoclet markup. Simply having 'public void execute()' is sufficient and XDoclet can do the rest. If there are exceptions to the task name mapping, which attributes should be excluded, etc, *then* the @tags are necessary. I worked hard to make the basic Ant tasks not need to concern themselves with XDoclet tags at all.
Of course, the generated descriptor is the key though. XDoclet or not, the descriptor is needed for tools to get this info unless introspection is used.
A two-way solution is perhaps the way to go though, since introspection will be fine in the majority of the cases (well, if you search Ant's source for ignore="true", there are more exceptions than you might think in Ant's own code). If the descriptor is present, use it, if not, use introspection - although perhaps note this on the UI inspectors so the user realizes that the info is not guaranteed to be 100% accurate?!
Erik: Do you think, that it can be valuable for all of us to use parts of
what your xDoclet proposal dos, direcly for introspection (like sucking the
value lists out of EnumeratedAttributes)?
There is nothing fancy there. From XDoclet's CVS code, which is where I migrated it - TaskTagsHandler.java:
Object instance = null;
try {
instance = clazz.newInstance();
}
catch (InstantiationException e) {
}
catch (IllegalAccessException e) {
}if (instance != null && instance instanceof EnumeratedAttribute) {
EnumeratedAttribute enum = (EnumeratedAttribute) instance;
String[] values = enum.getValues();
display = "";
for (int i = 0; i < values.length; i++) {
display += """ + values[i] + """;
if (i != (values.length - 1)) {
display += ", ";
}
}
return display;
}The key line just being enum.getValues, where clazz is the Class of the type of the setter.
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
