ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject RE: antlib
Date Thu, 24 Apr 2003 17:23:11 GMT
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




Mime
View raw message