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. <antlib> <taskdef .... > <typedef ... > </antlib> 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. +1 > 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... Costin
