At 10:39 AM 4/25/2003 -0700, Costin Manolache wrote:
However I'm more convinced than ever that the XML should use a subset of ant, and reuse the same processing infrastructure. I.e. not another parser or rules.
I really do not like this idea. I am -0.9.
This descriptor is a deployment descriptor for an existing ant type (currently task or data type) into an Ant container. As such, it is exactly like the EJB, WAR, and EAR descriptors. It describes the information that the container needs in order to put the new type into a context from which it can be used.
Trying to overload the meaning of Ant's existing build-oriented XML onto a language that defines how to deploy into an Ant container seems wrong to me for a lot of reasons. Yes, it will be more familiar to people who use Ant. Yes, it will allow reuse of some portions of code. But both of these are downsides as well.
The needs for describing a deployment into the Ant container are often similar but sometimes subtly different from the needs for describing a build. Code specific to antlib would inevitably end up in the code for all builds. And the principle of least surprise would be violated when people expected a certain type of behaviour in <antlib> based on their experience writing build files that wasn't appropriate or reasonable for a deployment descriptor (like scripting the initialization using ant tasks, to use your example).
If it had been available at the time, do you think anyone would have thought that requiring a subset of JSTL-only syntax in web.xml was a good idea? To my mind, that is somewhat equivalent to what you are proposing.
If this is the case - then using ant syntax in the antlib descriptor would be as good as another syntax.
Clearly I'm not in agreement with that statement. :-)
