> From: Costin Manolache [mailto:[EMAIL PROTECTED]
>
> 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.
>
But we are. To start with the top element in <antlib> and not <project>
your things inside are not the <taskdef> tasks, they are something
different (for example the "file", "resource", "classpath", "classpathref" and
"loaderRef" attributes are meaningless here)
It will confuse people more than anything else if the two things have the same
name.
This is exactly why I proposed new names, because otherwise it will confuse
people
more than be helpful.
> In particular the language that is in the proposal - which IMO is the
> worst part in it.
>
Sorry to here that.
The language was trying to make writing antlibs easier you really only
have one basic declaration which defines the elements available to you:
<role name="X" classname="x.y.Z" adaptor="p.q.R"/>
every declaration like this, implicitly makes available a new element tag:
<X name="Xname" classname="Xa.Xb.XC"/>
That's it. The DTD is dynamic just like the DTD of ANT is dynamic.
The only think that the implementation gives you is that the role declarations
for "task" and "type"
are implicitly declared incide the <antlib> element.
That's it. I thought that was as simple as I could do.
> 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.
>
Properties files are the most abuse thing in java, tryings to encode
as much information as possible in the name of the key. If you take
a look at things like log4j and such their P-file configurations
are just as full of
this.that.1.here=X
this.that.1.there=Y
and so on, just to pass all the information that needs to be passed.
>
> > 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 ?
>
JDK only defines a mechanism to indicate which other jars are need to be
loaded to find additional classes (which are located relatively to the current
jar)
This is not dependency declarations.
Jose Alberto
