ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: antlib
Date Thu, 24 Apr 2003 14:22:24 GMT
Stefan Bodewig wrote:

> In the end we are not that far apart at all.  Let's get the things
> together then.
> * antlib needs a way to define mappings between names and classes.
> Costin prefers a properties file.  Most others prefer XML.

I can live with XML. 

What I hate is us inventing  yet another complex DTD. There is nothing wrong
with XML ( the angle brakets and syntax ), but I have a very big problem
with the countless languages that people invent on top of XML. 

If we are to use XML, let's at least use ant syntax - i.e. 
   <taskdef .... >
   <typedef ... >

Things people already know and understand, we have all the code to 
process it, and if we want to extend - it's quite easy.

Please, don't invent a new language. 

In particular the language that is in the proposal - which IMO is the
worst part in it. 

I support properties because:
- that's what people already do. If we need XML later for extra fancy
things, very easy to add.
- it keeps the overhead to a minimum at runtime
- it is _not_ easy to bloat it.

> My argument for XML is the extensibility.  We will need versioning, we
> will need some statement of pre-reqs (like this antlib requires
> log4j), we will need additional capabilities we do not see now.

J2SDK1.2 + defines a  mechanism for declaring dependencies. Which is
actually required for servlet containers and j2ee. (i.e. the manifest ).

Why would we want to invent our own ?

> We certainly could put this into MANIFEST.MF, but it would be hard to
> put all of this into a properties file.  I like to keep the
> information in a single place, so properties plus manifest is no good
> idea IMHO.

Let's keep information where it belongs :-) 
If java defines a format and a place for dependencies - why would we want 
to invent our own ? 

> * if we are having problems with roles right now, lets start small.


> Let's make a version of antlib that knows about two predefined roles,
> task and data-type.  I think this is already feature complete in the
> proposal (which does even more).

This is almost feature complete in the main branch. If you consider
ComponentHelper, it's almost done.

> Let's move this code with the restriction to tasks and types into the
> main branch ASAP.  Let's sort out the classloading requirements as
> well as the interplay of antlib with taskdef and typedef here.

If that means adopting the XML from the proposal - I'm strongly -0.
( and close to -1 :-)

I'm very uncomfortable with the unneeded complexity that is now in
the proposal - and I think we learned that it is much harder to remove 
something than to add.
> After this flies, I'd expect us to get roles sorted out.  If we feel
> like removing the difference between tasks and types, we can do so
> then as well.

As long as we don't start adding more component kinds...


View raw message