Hi I want to start a new thread to discuss specifically
the concept of Roles (as they were conceived in the ANTLIB proposal)
Costin has suggested we take this separately and whatever it comes of it
will be supported at that time by the antlibs, of course.
So here are my points on what roles are for, what do they do that is not
currently possible in ANT, and how it is done in the code of the proposal.
1) What are roles for:
Roles allow defining families of objects (members of a role) that can be
used by tasks or inner elements developed separately.
The developer of the object accepting a particular role as a subelement
has no knowledge of the implementation of the object but much more
importantly it has no knowledge of the XML element tag used to refer
to this subelement in the XML file.
This means that in the XML the possible content of the XML fragment
of a particular task depends not only on the task itself but, if it accepts
roles,
on the objects currently declared on that role and their respective XML
fragments.
All this without any special support from the object accepting the role as
argument.
What does it all mean? It means we can now write a task, well typed, which
can be accept different XML subelements depending on the declarations of
other objects present on the build. The vendor specific elements of
<ejbjar>, <jspc> and others are typical examples of where this capability
can be very useful. Other parts of core could benefit of course.
2) What do they do that is no possible in ANT:
They allow IntrospectionHelper to connect an XML subelement eventhough
introspection cannot find a create or add/Configured method for it.
It is a well typed methanism, the parent object will only be passed objects
that it knows how to deal with. And the parent object does not need to have
any knowledge of what currently available members are on the role.
The closest thing in ANT today is DynamicConfigurator but its purpose
is on the otherway around. Given an elementTag with no matching method
it is upto the parent object to try to make sense of it.
If we where to use this mechanism to acomplish what roles try to do,
it would require the parent object implementor to be aware of where
to find the correct definintion (remember it is a 3rd party implementation)
and perform the creation. It will be also its responsability to
resolve type conflicts, name collisions, etc. This are all things
that should be done by IntrospectionHelper directly.
Also notice that Roles do not supercede DynamicConfigurator. On one hand roles
let external implementations to be considered as possible subelements
of a parent object, on the other hand, DynamicConfigurator allows a node
to decide given its current state what is the meaning of a particular element.
This cannot be done by roles in the general case, and that is good.
3) How it is done in the proposal:
Here I may deviate from the exact code and add thoughts about where
do I think it should go.
Usage of Roles:
==============
The principle is very simple:
a) A role is defined by an interface. This interface is the parameter
for a new special family of addConfigured(<interface>) methods.
b) When IntrospectionHelper fails to find a create/add method for the
element, it will look at all the roles used in the addConfigured
methods and on each of those roles will try to find an object
declared
with that element-tag name. If one and only one match is found then
the instantiation is successful and the new object will be
configured;
otherwise it is an error and parsing stops.
c) The configured object may or may not implement the Role interface,
if it does not, an Adaptor object may be instantiated as a proxy
for the object. Which adaptor is used depends on how the
implementation
was declared.
d) The resulting object is passed as an argument to the addConfigured()
method.
Declaration of roles:
====================
A role definition associates a name with an (Interface,Adaptor) pair.
The only reason for associating a name with the role is to ease notation when
declaring members of a role.
Notice that the same interface or the same Adaptor may appear in multiple
declarations. This only means that depending on the name used the adaptor
of choice will be different.
There can only be one pair associated with each name.
Declaration of implementations (members):
========================================
A class is declared as belonging to a role by specifying the name to be used
when appearing in that role. The same class may belong to multiple roles
and may specify the same or different names on each one.
The name used for the role during the declaration only determines which
Adaptor will be available, if required.
Within a role-interface there can only be one object associated
with each name.
Scoping rules:
=============
This is probably the more dificult aspect since given the way
<ant> and <antcall> work it means possible redeclarations on every
level of recursion. Whether declarations should just supercede
one another or be smarter is something to look into.
Syntax:
======
I have left out the issues of how the syntax looks like on purpose.
Syntax is just that and I am sure we can reach agreement somehow.
It is also clear that we should provide tasks to define roles
and declare members of roles direclty on the build.
Ok, this is it. If you have any strong opinons about it, let me know.
Jose Alberto
> -----Original Message-----
> From: peter reilly [mailto:[EMAIL PROTECTED]
> Sent: 25 April 2003 13:22
> To: Ant Developers List
> Subject: Re: antlib
>
>
> On Friday 25 April 2003 12:24, Jose Alberto Fernandez wrote:
> > Peter,
> >
> > this is exactly my point. For every new thingy that we add
> we now need to
> > go and modify IntrospectionHelper or something to make
> special allowances
> > for it.
>
> The dynamicelement addition to IntrospectionHelper is general
> and new thingies
> can be added without affecting core ant.
>
> >
> > It is bloating the core like mad and in my opinion it is
> crazy. We need a
> > unified way to treat this things no matter what the things
> are. Ant's
> > engine core should not need to know anything about anything.
>
> Dynamicelement has the potential to remove code (e.g. all the
> add<NAME> methods to conditionbase, selectorbase, and
> filterchain). The
> only problem is name clashes.
>
> >
> > In an ideal world, we should have an engine core with no
> reference to any
> > task/type or its implementing classes and a core-antlib
> which provides the
> > classes and definintions for all the
> > task/types/conditions/selectors/mappers that define core java.
>
> This can be done with dynamicelement, except for name clashes
> and mapper
> (which does not use sub-elements for different filenamemappers).
>
> Peter.
>
> Ps: I am including mods to IntrospectionHelper.java and
> DynamicElementHelper.java
>
