Added axiom number 2 to requested-features.txt. James Cook <[EMAIL PROTECTED]> wrote:
> 1. Task developers will not have to go through an external class to > access its data. I think this basically says "keep the old interface" and therefore is already covered. If you want stronger emphasis on this point, let me know. Anyway, completely agreed with this point. > 2. A Task must identify the name of all modifiable properties. As you point out, this is already possible via "all methods following our naming convention represent attributes/nested elements" - and there even are support methods in IntrospectionHelper to aid external tools. But sometimes one might pick up false positives (setUserProperty in Property being something that shouldn't lead to an attribute for example). So in principle I agree. > a. The Task developer identifies the properties for the Task as a > return value for a specific method, such as getProperties(). > > b. The Task developer uses an external file (ala the Task list file) > to specify the properties. > > c. The properties are encoded in JavaDoc for the Task. I'd go for a combination of b and c - i.e. encode it in JavaDoc and make a custom doclet generate the task describing file (as well as the documentation in the correct XML DTD). This could also be used to identify required attributes, default values and stuff. > 3. A Task must be able to return resolved and unresolved values of > its properties. I understand your communication with Pete as that you are no longer backing that point, right? Like Pete I don't think tasks should be aware of "unresolved variables" at all. Stefan
