I don't like the fact that it's so easy to mess up my BeanInfo mapping in Struts-EL, as it's all validated at runtime through introspection. After 1.1 is released, I plan to do some minor rearrangement inside the BeanInfo classes and add a custom task to the build which uses a class I just wrote which parses a TLD (using Digester) and tries to verify that all the tag attributes have valid setter methods in the tag class.
The introspection mechanics of this class are relatively straightforward, but really putting this into the build presents some questions in my mind, mostly Ant-related: Where should I put the Ant task class? Obviously, it would go in the "struts-el" tree, but I'm not sure of the logistics of this. The task can only be performed after the library is built, but I guess the task class has to be available when ant starts. I'd be glad to avoid writing an Ant task and just execute "java" in the build, but I can't figure out how I can make what happens in the execution of my class to cause the build to fail. Note that I'm only referring to the Struts-EL build, although it's conceivable we could also do this in the main build. It's still possible to mess up the "property name"->"setter" mapping, even if you just use the standard mapping. Catching the error at build time might save someone a few minutes. Testing for this could be done in unit testing, but the entire unit test suite is not normally done as part of the build, because it takes too long. This task would go pretty quickly, so it wouldn't be painful to have it as part of the default build. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
