Jose Alberto Fernandez wrote: >> 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)
What I meant is the antlib descriptor would be an XML file that is a subset of the ant syntax. We can restrict this to <taskdef>, <typeded>, <condition> and few other that we need, and add more later. > It will confuse people more than anything else if the two things have the > same name. The 2 things will be the same thing. >> 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. The problem is that: - instead of only defining the ant lib, it also adds concepts of role. If everyone but me wants roles - I could live with it, but _not_ if they are added as a side effect of the antlib. - do you call this "simpler" or "easier" than the properties file that we use currently ? The common use case is defining tasks and datatypes. >> 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 The fact that others abuse properties doesn't mean they are wrong. There are a lot of abuses on XML ( far more than properties ). ( I haven't tried the new MSFT office - but I heard that it has some very "easy" use of XML ). Again - I have no problem if we don't use properties and use XML instead. My requirement ( and I'm going to fight as much as I can for this ) is to keep things _simple_. >> 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) I assume you're talking about the ClassPath, which is just a way to specify the CLASSPATH, and has nothing to do with dependencies. I was talking about the "real" dependency part - with Requires-XXX. > This is not dependency declarations. Costin
