ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: Tasks, DataTypes and Factories
Date Wed, 06 Mar 2002 21:14:24 GMT
On Thu, 7 Mar 2002 07:58, costinm@covalent.net wrote:
> > No need for a separate namespace parameter in interface. Just pass in
> > "namespace:name" as the name and have the factory decode it if it wants.
> > It is not like this code is performance intensive and if it was there is
> > plenty of other places that should be dealt with first.
>
> 'Namespace' is a URI, and passing it mangled and unmangling it is ugly.
> The idea is to improve it, not to hack it.  It's not about performance,
> but about interfaces - and almost all applications that deal with xml
> are now able to support namespaces ( except ant ).

I vaguely remember we voted against URI namespace support in ant2 and instead 
voted for namespace support similar to javas "import" namespace. I am not 
sure if that is changed.

> BTW, a 'namespace' is not an XML thing - it's a way to group
> tasks ( same as a package name in java, etc ). Having a flat
> naming for tasks doesn't scale very well.

Nope - but we don't have to couple to URI directly. Reverse DNS naming of 
java packages or C#s namespace seems to work well and is reasonably familiar 
to most developers using ant.

> > > 4. Make task/datatyle creation and behavior more consistent
> > > with each other. They should use similar code for creation,
> > > adapters ( for 'external' beans not implementing ant interfaces).
> >
> > As long as only classes extending Task/DataType/ProjectComponent are
> > returned from factory then all should be good. Well ... unless you do
> > anything tricky with classloader in which case you will need to mod the
> > rest of code base anyways ;)
>
> Yes, the factory should return a ProjectComponent - be it a Task or
> DataType. It may return an adapter - i.e. TaskAdapter, or a DataType
> adapter.

But all adapters extend ProjectComponent, right?

> Regarding classloader - there is no need to modify anything else in ant.
> You can plug in a TaskFactory that implements/uses whatever class loader
> and policy it wants - no other piece of ant cares about this as long
> as it is consistent.

You sure. Thats what I thought until I started to implement it ;)

> Of course, the default ProjectCompoenentHelper will use the current
> loader policy, but I hope Antlib will be reimplemented as a regular
> task that plugs itself in.

kool.

> It would be very good to have myrmidon and mutant factories wrapped and
> usable with ant1.5 - and I think making this work is essential, so
> if there's anything missing let me know.

The factory interface as it stands is fine - the tricky bit will be how the 
factorys are registered. I don't think your proposal addresses that just yet?

-- 
Cheers,

Pete

--------------------------------
 These aren't the droids you're 
 looking for. Move along. 
--------------------------------

--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message