ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wannheden, Knut" <knut.wannhe...@paranor.ch>
Subject RE: xml namespace support in ant2
Date Tue, 01 Oct 2002 07:53:12 GMT


> -----Original Message-----
> From: Costin Manolache [mailto:cmanolache@yahoo.com]
> Sent: Montag, 30. September 2002 19:33
> To: ant-dev@jakarta.apache.org
> Subject: RE: xml namespace support in ant2
> 
> 
> My opinion:
> 
> 1. I hate using schema for validation. XML is not the only way to use
> ant - there are already projects using ant tasks as beans, 
> and it's a good
> code reuse. 
> Besides, schema is still slow ( and will allways be - due to it's 
> complexity). Even Relax or simpler schemas can't ever beat the if()
> in the task, which also cover the use of the beans.
> 

If not schemas should be used for validation for the reasons you mention I
still think there should be some other mechansim.  Ideally this mechanism
would ensure proper usage, allow consistent documentation to be generated
and simplify the code inside a task.  As it is now task code gets very
cluttered with validation code, which is sometimes even wrong (because of
lack of a good mechanism).  IMHO having a set of setXXX(), createXXX(),
addXXX(), addConfiguredXXX(), setDynamicAttribute(), and
createDynamicElement() methods just isn't the right way to express how a
task is to be used.

And what you say about beans is probably not entirely true, at least not if
the tasks haven't been implemented with beans in mind.  When used as beans
the client still has to mimic the behaviour of the Ant core somehow to set
up the task for usage.

> 2. However schemas are good for documenting the task and for possible
> tools. As long as we don't use them for validation ( which 
> I'll -1 as strong
> as I can ).
> 

Yes, they would provide a good means to document tasks.  But they could also
be used for validation.  If the tasks should be possible to use differently
(e.g. as beans) I think there should be a mechanism which allows for
validation in both modes.

> 3. The embed proposal uses SAX2, but it is not doing anything 
> ( yet ) with 
> the namespaces. My original plan was ( and still is ) to use 
> the namespace
> as an ID, and use it to locate the task definition using 
> getResource().
> For a task in NS, I would look up 
> META-INF/ant/encoded(NS)/SOMETHING - and 
> locate the description of the tasks in that namespace and additional 
> metadata. The descriptor should support both properties (for 
> simple cases)
> and an XML form. 
> 

If I understand you correctly you would use the namespace as an ID for a set
(library) of tasks and types.  This is what I've been thinking, too.

BTW, what kind of information did you have in mind for the task descriptors?

> 4. A very tricky issue is the syntax of the ID. We can use a 
> meaning-less
> string, or a URL that can be used to download the lib. Even 
> in the first 
> case ( arbitrary string ) we can have a 'antlib registry' - 
> but it would 
> be extra overhead. I know there are many (strong) opinions on this.
> 

Well to use namespaces you would have to use IDs which can be interpreted as
URIs.  And at a later stage you could map that URI to an arbitrary string
with some "antlib registry".

> 5. Even if ns is added, most people will still prefer to use 
> the default
> namespace. It's just much easier to type and use ( at least 
> IMO - and from
> what I've seen ). Should we restrict the default ns to ant 
> core tasks and
> force everyone to use ns for extensions ? I don't think so.  
> 

Yes, as someone else said you should probably not restric the default
namespace.  Wouldn't make very much sense.

> 6. Namespaces should be used instead of 'taskdef' whenever possible 
> ( i.e. the descriptor  ).
> 

I was thinking that namespaces would primarily be used to clearly separate
Ant core tasks from the custom loaded tasks and let the user use any name
for the task.  To load custom tasks the buildfile writer would then either
do a <taskdef> or an <antlib>.  E.g.

  <taskdef name="copy" ns="urn:abc-namespace"
           classname="com.xyz.MyCopyTask"/>
  <bla:copy xmlns:bla="urn:abc-namespace"/>

This would not require that a descriptor exists for every task.

For <antlib> you would require that there be a descriptor which is located
with the encoded namespace URI as you say.  Then you'd probably do something
like:

  <antlib resource="com.xyz.MyAntlib"/>
  <bla:copy xmlns:bla="urn:abc-namespace"/>

where the antlib property would define the namespace URI it uses.  (In all
examples the namespace attributes could of course also be declared in an
enclosing element, like <project>.)

What do you think?

Cheers,

--
knut

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message