ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <br...@callenish.com>
Subject Re: Antlib descriptor
Date Sat, 26 Apr 2003 21:27:25 GMT
(Boy, you fall behind a couple of days on your email and suddenly an 
avalanche breaks loose)

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. :-)



Mime
View raw message