ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject RE: xml namespace support in ant2
Date Tue, 01 Oct 2002 17:26:02 GMT
Wannheden, Knut wrote:

>> 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.

Documentation is one issue - and schema may be the right way to document
a task. Or javadoc and xdoclet ( which could generate a schema ? ).

Having a method validate its parameters remains IMO the right way to 
write code. And is far cleaner ( and faster ) than any alternative. 
It is true - there is a duplication between the code checking 
if( param>10 ) throw InvalidArgumentException 
and the documentations or eventually schema. However having a 
'validation' mechanism ( and there are few ) is more complex ( 
at least IMO ).

I don't thing it's clutter to validate your params - just good programming.

> 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 
> the client still has to mimic the behaviour of the Ant core somehow to set
> up the task for usage.

AFAIK that's how ant was designed - so that tasks are beans.
Of course a client needs to instantiate a Project and do a bit of setup.
Jasper is curently using javac task - and I think it is the right thing.

>> 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.

So instead of a task checking its params, you would prefer some
external mechanism. I think we should agree to disagree on this.

But even if a majority would prefer external validation, schema is
one of the worse possible solutions. There are some tools
( aspectj ? ) that are doing this at the code level ( or bytecode ?),
but again I personally prefer explicit java code. 

> If I understand you correctly you would use the namespace as an ID for 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?

I would like 2 possible descriptors.

The 'simple' case will be just the properties file that we curently
use, that proved to work fine so far. I feel pretty strongly
that having something 'simple' is important.
Given that tasks/types are treated the same - and the distinction is
getting small, we need to declare 'project components' and use class
data ( instanceof, introspection ) to extract all other info. 

For more complex cases - an XML file containing the same info
( task name, class name ) plus documentation - for the first step.
Then be conservative ( and have a majority vote ) for each added
item. In any case I'm strongly against a kitchen sink aproach - 
of putting in everything we can dream of. The XML should use
ns to allow extensibility and 'experimental' elements.

>> 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".

I was talking about URLs. A URL is a URI - but many people are against
this because the URL can also be used to locate resources on the net.
But I don't see why it would hurt - and why having a redirection 
stage ( CATALOG or a web service ) is absolutely needed ( it can
be done with URLs ). 

Given the very different opinions - it would be best to keep this
item separated from the discussion on the other issues.

>> 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=""/>
>   <bla:copy xmlns:bla="urn:abc-namespace"/>
> This would not require that a descriptor exists for every task.

The can be used for tasks that don't have descriptors. 
But if a task has a descriptor, there is absolutely no reason to
require the use of taskdef ( unless the user wants to - for example
to change a task name, which should be strongly discouraged and 
is no longer needed with ns ).

> 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=""/>
>   <bla:copy xmlns:bla="urn:abc-namespace"/>

Yes, that's the main use case. 

However I would like to also use 'discovery' mechanisms. That may gain
majority or not - but what I hope is that the hook will be accepted
allowing user-components to support extensions ( just like 
ant-contrib defines procedural tasks, or embed defines alternate
XML processors ).

> 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>.)

As I said, for myself I would rather use:

 <foo:bar xmlns:foo="" >...</foo:bar>

And a discovery mechanism will locate 
inside the classpath, or display a message that I need to download
a library from that location - and not require use of taskdef.

Again: this is my preference, it may or may not be what the majority 
wants. What I want is that regardless of the majority opinion on
how this should work in the standard ant, the minority should have
a hook to implement extensions, just like we allow procedural
extensions or other things that didn't get accepted in the standard

( or just like the ProjectHelper hook is used to plug in different
processors like embed, even if SAX2 and various other features haven't
been yet voted in )


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message