You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by co...@covalent.net on 2002/03/06 18:09:32 UTC
Tasks, DataTypes and Factories
At this moment, there are 2 major differences between task/datatype:
1. Datatypes are allowed at top level. Only 3 tasks are allowed ( by
hardcoding their names in ProjectHelperImpl ).
2. Tasks have an execute method that is called. Datatypes don't.
( however filters do have a special method, and it is possible other
datatypes will have some other 'active' method ).
Both Task and DataTypes extend from ProjectComponent. Tasks have
a mechanism to allow regular beans ( not extending Task ) to be
used.
Tasks and DataTypes are registered using a name and a Class, and
are created using newInstance() by some code in Project.
What I'm trying to do:
1. Create a mechanism to allow the ProjectComponent creation to be
delegated to an optional factory ( ProjectComponentHelper ).
The optional factory may use more advanced logic to locate
and create the tasks. This will make things like <antlib> implementable
without changes in the core.
2. Allow the use of optional namespaces in tasks. We already have
too many tasks in the default namespace, some grouping would
improve the readability and maintainability. Of course, all
existing tasks will continue to work without namespaces.
This require a new method in Project: createComponent() that
will take a namespace and a tag name.
3. Make the 'top level tasks' more flexible. I would prefer
allowing all tasks at top level, but anything better than
3 hardcoded tasks is ok.
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).
Votes/comments please. The initial interface for component
creation is checked into proposals/sandbox/embed/ProjectComponentHelper.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tasks, DataTypes and Factories
Posted by co...@covalent.net.
On Thu, 7 Mar 2002, Jose Alberto Fernandez wrote:
> > I'm not sugesting that ant should require namespaces, or get into the
> > religious discussion about the meaning of a namespace.
> >
> > I'm just saying they are part of the xml standard, and
> > it's a good idea to design the task factory API with namespace
> > ( in the generic sense ) in mind. If it's going to be
> > a java-style package name or something else - it doesn't matter
> > from the point of view of the factory interface.
> >
>
> Doesn't NS require a well defined DTD or Schema for the NS declaration?
>
> <xyz:tag ns:xyz="URI" ...>
>
>
> </xyz:tag>
>
> How can ANT work that out? We do not have a well defined DTD at the moment.
Namespace have nothing to do with DTDs or schema ( except that it runs
into the limitations of dtd :-). But we don't use DTDs, so no problem here.
It just says that ":" is reserved and should be used to separate the
local part from the prefix, and it defines the syntax to be used ( the
ns: attribute, etc ).
It's obviously not the perfect standard, I'm sure we can invent something
better :-)
But this has little to do with ant - all tasks included in ant1.5 will
remain unchanged and do not need to use namespaces.
My proposal allow someone to hook in and use namespaces for his own
add-on tasks - the ProjectHelper allow the hook of a SAX2
parser, and the ProjectComponentHelper interface allows to
pass the ns information ( if any ) in a decent way.
BTW, the ns param doesn't have to come from XML or be a XML namespace,
it's just a way to qualify the name of the task and avoid the
flat namespaces or strange naming conventions for the tag names.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tasks, DataTypes and Factories
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
From: <co...@covalent.net>
> On Thu, 7 Mar 2002, Peter Donald wrote:
>
> I vaguely remember W3C voted for namespace support in XML :-)
>
Touche' ;-)
> I'm not sugesting that ant should require namespaces, or get into the
> religious discussion about the meaning of a namespace.
>
> I'm just saying they are part of the xml standard, and
> it's a good idea to design the task factory API with namespace
> ( in the generic sense ) in mind. If it's going to be
> a java-style package name or something else - it doesn't matter
> from the point of view of the factory interface.
>
Doesn't NS require a well defined DTD or Schema for the NS declaration?
<xyz:tag ns:xyz="URI" ...>
</xyz:tag>
How can ANT work that out? We do not have a well defined DTD at the moment.
Thoughts?
JA
>
> > > 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.
>
> I agree, the semantic of the namespace is not my issue. The default
> for ant1 is clearly no namespace, and that should continue to be
> supported, but for user-defined components ( some maybe using
> the task factory ) it's important to leave the door open.
>
>
> > > 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?
>
> Right. I'll change the interface.
>
>
> > > 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 ;)
>
> I'm very sure, no need to worry about that.
>
>
> > > 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?
>
> Oh, that's trivial. Just 1 method in Project -
> addProjectComponentHelper(), and all helpers will be called before
> defaulting the Class.
>
> It's exaclty how normal task registation take place - a task like
> taskdef can register new tasks - or task factories.
>
> Well, probably a better solution would be to move all the code
> from createTask/createType in a DefaultProjectComponentHelper,
> so Project code will be cleaner and simpler - I'll try this
> out.
>
> Costin
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tasks, DataTypes and Factories
Posted by co...@covalent.net.
On Thu, 7 Mar 2002, Peter Donald wrote:
> 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.
I vaguely remember W3C voted for namespace support in XML :-)
I'm not sugesting that ant should require namespaces, or get into the
religious discussion about the meaning of a namespace.
I'm just saying they are part of the xml standard, and
it's a good idea to design the task factory API with namespace
( in the generic sense ) in mind. If it's going to be
a java-style package name or something else - it doesn't matter
from the point of view of the factory interface.
> > 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.
I agree, the semantic of the namespace is not my issue. The default
for ant1 is clearly no namespace, and that should continue to be
supported, but for user-defined components ( some maybe using
the task factory ) it's important to leave the door open.
> > 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?
Right. I'll change the interface.
> > 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 ;)
I'm very sure, no need to worry about that.
> > 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?
Oh, that's trivial. Just 1 method in Project -
addProjectComponentHelper(), and all helpers will be called before
defaulting the Class.
It's exaclty how normal task registation take place - a task like
taskdef can register new tasks - or task factories.
Well, probably a better solution would be to move all the code
from createTask/createType in a DefaultProjectComponentHelper,
so Project code will be cleaner and simpler - I'll try this
out.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tasks, DataTypes and Factories
Posted by Peter Donald <pe...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tasks, DataTypes and Factories
Posted by co...@covalent.net.
On Thu, 7 Mar 2002, Peter Donald wrote:
> > 2. Allow the use of optional namespaces in tasks. We already have
> > too many tasks in the default namespace, some grouping would
> > improve the readability and maintainability. Of course, all
> > existing tasks will continue to work without namespaces.
> > This require a new method in Project: createComponent() that
> > will take a namespace and a tag name.
>
> 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 ).
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.
> > 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.
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.
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.
> Also
> * hasRole() should be hasProjectComponent() ?
> * createProjectComponent() should return a ProjectComponent ?
>
> BTW just as a note that this is the same mechanism I have been using in
> Myrmidon for a while now (Though I called it TypeFactory). It was also the
> method via which I made it possible for users to write tasks as templates or
> scripts etc. So when I upload this stuff next week sometime it may be a good
> idea to prototype that stuff to make sure it is doable under your proposal
> (though I can't see why it shouldn't be depending on how you register the
> factorys).
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.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tasks, DataTypes and Factories
Posted by Peter Donald <pe...@apache.org>.
On Thu, 7 Mar 2002 04:09, costinm@covalent.net wrote:
> 2. Allow the use of optional namespaces in tasks. We already have
> too many tasks in the default namespace, some grouping would
> improve the readability and maintainability. Of course, all
> existing tasks will continue to work without namespaces.
> This require a new method in Project: createComponent() that
> will take a namespace and a tag name.
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.
> 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 ;)
Also
* hasRole() should be hasProjectComponent() ?
* createProjectComponent() should return a ProjectComponent ?
BTW just as a note that this is the same mechanism I have been using in
Myrmidon for a while now (Though I called it TypeFactory). It was also the
method via which I made it possible for users to write tasks as templates or
scripts etc. So when I upload this stuff next week sometime it may be a good
idea to prototype that stuff to make sure it is doable under your proposal
(though I can't see why it shouldn't be depending on how you register the
factorys).
--
Cheers,
Pete
---------------------------------------------------
"It is easy to dodge our responsibilities, but we
cannot dodge the consequences of dodging our
responsibilities." -Josiah Stamp
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tasks, DataTypes and Factories
Posted by co...@covalent.net.
On Wed, 6 Mar 2002, Jose Alberto Fernandez wrote:
> The only problem with what you are proposing is that
> data-types do not need to extend DataType and hence
> they are not necessarily ProjectConponents.
Tasks do no need to extend Task class either.
( almost none of the tasks I wrote outside ant
extend Task ).
That's what TaskAdapter is supposed to do.
> This was the first thing I had to work around when
> looking at the use of Roles for data-types.
And what I'm proposing is to have a consistent way to
deal with task and datatype creation _and_ adaptation
of external components ( not implementing ant
interfaces ).
A ProjectComponentHelper can create either a real
ProjectComponent ( Task, DataType, etc ) or a wrapper
( ProjectComponentAdapter ).
Same rules that apply for TaskAdapter whould work for
data types as well - less confusing for the task/type
developers, simpler ( and easier to maintain ) ant.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Tasks, DataTypes and Factories
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
The only problem with what you are proposing is that
data-types do not need to extend DataType and hence
they are not necessarily ProjectConponents.
This was the first thing I had to work around when
looking at the use of Roles for data-types.
Jose Alberto
--- costinm@covalent.net wrote: > At this moment,
there are 2 major differences
> between task/datatype:
>
> 1. Datatypes are allowed at top level. Only 3 tasks
> are allowed ( by
> hardcoding their names in ProjectHelperImpl ).
> 2. Tasks have an execute method that is called.
> Datatypes don't.
> ( however filters do have a special method, and it
> is possible other
> datatypes will have some other 'active' method ).
>
> Both Task and DataTypes extend from
> ProjectComponent. Tasks have
> a mechanism to allow regular beans ( not extending
> Task ) to be
> used.
>
> Tasks and DataTypes are registered using a name and
> a Class, and
> are created using newInstance() by some code in
> Project.
>
> What I'm trying to do:
> 1. Create a mechanism to allow the ProjectComponent
> creation to be
> delegated to an optional factory (
> ProjectComponentHelper ).
> The optional factory may use more advanced logic to
> locate
> and create the tasks. This will make things like
> <antlib> implementable
> without changes in the core.
>
> 2. Allow the use of optional namespaces in tasks. We
> already have
> too many tasks in the default namespace, some
> grouping would
> improve the readability and maintainability. Of
> course, all
> existing tasks will continue to work without
> namespaces.
> This require a new method in Project:
> createComponent() that
> will take a namespace and a tag name.
>
> 3. Make the 'top level tasks' more flexible. I would
> prefer
> allowing all tasks at top level, but anything better
> than
> 3 hardcoded tasks is ok.
>
> 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).
>
> Votes/comments please. The initial interface for
> component
> creation is checked into
> proposals/sandbox/embed/ProjectComponentHelper.
>
> Costin
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>