You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Peter Reilly <pe...@gmail.com> on 2006/09/12 23:03:16 UTC
Restricted types: Re: Location in non-Task tasks
On 9/11/06, Dominique Devienne <dd...@gmail.com> wrote:
>
> > > > 2) Introduce a <tagdef> or <roledef> for the purpose
> > > > of locating extension points as nested elements.
>
> > but I looked at the code and realized that the type
> > handling in ant would become too complicated - there
>
> I see your point. Increased complexity is not good. But is it really
> that complex? This new mechanism would only kick in when IH would
> overwise have rejected a nested element, and only add lookup into a
> new mapping when the current type has an add(Type) extension point.
>
> True, their can be tricky cases when a type has both an add(Condition)
> and a add(FileSelector), but that should be pretty rare, and could be
> thrown out as ambiguous. It could even be resolved using the
> undocumented ant:type attribute.
Ok, I dug out my old code and after digging out some of the bugs
and misunderstanding, I have modded IH, CH (componenthelper),
and <typedef> to allow "restricted" types.
These are like normal types except:
1) they are only allowed in add[Configured](Class) contexts, they
cannot be used at the top level or task containers.
2) One can have a multiple number of definitions with
the same name. IH will pick the one that matches the
add() methods in the container class. If there are multiple
matches, - for example class that has add(Condition) and
add(FileSelector)
presented with "and", IH will throw a buildexception for ambigeous.
I am not too sure this should be user visible but it can be implemented
by an extra attribute to the typedef task - restrict=yes/no default is no.
One problem is that the antlib.xml for antlib:org.apache.tools.ant would
be long and tedious when all the conditions, selectors, mappers, resources
are added.
Being long means that startup time for ant would suffer a little (the file
needs to
be parsed) and being tedious means that it would be difficult to maintain.
To solve the startup problem, I propose that we use an AntLibDefinitions
class associated
with a name-space which would contain the definitions.
To solve problem two, I propose that we use annotation like syntax:
* @ant.type [restrict="yes"/"no"] [name="whatever"]
or
* @ant.task [name="whatever"]
Where the defaults are restrict=no, name={classname in lower case without
package)
And have a task that will generate the definitions - either as an antlib xml
file
or as a AntLibDefinitions java.
I will create a bugzilla issue where I will place the diffs and task.
This will not of course be for ant 1.7!,
however we can add the @ant.type tags now for documentation?,
@ant.task is already in place for the ant doc project.
@ant.datatype is used as well - but ant types do not need to be
datatypes and not all datatypes are ant types.
Peter
> It would however be nice to get something that
> > allows add(Condition) or add(FileSelector) to work
> > without having to extend BaseCondition or whatever
> > is done for FileSelector .
>
> Precisely. Unless I'm mistaken, this can already be achieved now by
> using namespaces, and the condition antlib. So AssertTask could be
> made ConditionBase independent now, no?
>
> --DD
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: Restricted types: Re: Location in non-Task tasks
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 12 Sep 2006, Peter Reilly <pe...@gmail.com> wrote:
> Ok, I dug out my old code and after digging out some of the bugs
> and misunderstanding, I have modded IH, CH (componenthelper),
> and <typedef> to allow "restricted" types.
>
> These are like normal types except:
> 1) they are only allowed in add[Configured](Class) contexts, they
> cannot be used at the top level or task containers.
> 2) One can have a multiple number of definitions with
> the same name. IH will pick the one that matches the
> add() methods in the container class. If there are multiple
> matches, - for example class that has add(Condition) and
> add(FileSelector)
> presented with "and", IH will throw a buildexception for
> ambigeous.
+1
> I am not too sure this should be user visible but it can be
> implemented by an extra attribute to the typedef task -
> restrict=yes/no default is no.
Like the others I'd prefer a new taskname as well, just don't ask me
for names.
> One problem is that the antlib.xml for antlib:org.apache.tools.ant
> would be long and tedious when all the conditions, selectors,
> mappers, resources are added.
I don't think this is really that big a problem, but I'm fine with
automation as well.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Roles [WAS:Re: Restricted types: Re: Location in non-Task tasks]
Posted by Peter Reilly <pe...@gmail.com>.
Thanks,
this is good summing up.
On 9/13/06, Dominique Devienne <dd...@gmail.com> wrote:
>
> > Sorry I did not read all the svn commit emails. Which classes implement
> these role definitions ?
>
> None, at least none that "define" a role.
>
> Peter has extended IH and co. to lookup nested-element in tasks/types
> that have add(X)-type methods, in a new mapping he called restricted
> types (because they cannot use by themselve, only as nested element of
> declared tasks/types).
>
> Suppose I write FooTask in my bar AntLib. If FooTask as a
> add(Condition) method, as of now, I can only use as nested elements
> conditions which have been explicitly typedef'd.
>
> Currently, there are none in Ant.
Except for isfileselected and scriptcondition.
There is an antlib.xml for conditions, but I'm forced to explicitly
> load it to be able to use them in my FooTask, and doing so I bring
> them all into the "global" tasks/types mapping, so they can be used at
> the top-level in <project> or <target>.
>
> Peter's "restricted" types form a new mapping (I would normally say a
> new namespace, but it becomes confusing because of XML namespaces...),
> which is used exclusively to resolve add(X)-type methods.
>
> This new mapping doesn't define any roles. The role that one of this
> mapping will play in a task will depend on (1) the add(X) method of
> that task, and (2) the types this one mapping is compatible with (in
> the sense of instanceof or Class.isAssigneableFrom).
>
> So there's no real notion of a role, IMHO. Which is why I'm not fond
> of using <roledef> to declare this "restricted" types. I believe Peter
> now added a 'restrict' attribute to <typedef>, which I'm also not fond
> of, but it may turn out to be the less controversial choice...
>
> No code to look at yet, since I don't think Peter posted his diffs to
> BugZilla yet. --DD
I will soon...
Peter
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: Roles [WAS:Re: Restricted types: Re: Location in non-Task tasks]
Posted by Dominique Devienne <dd...@gmail.com>.
> Sorry I did not read all the svn commit emails. Which classes implement these role definitions ?
None, at least none that "define" a role.
Peter has extended IH and co. to lookup nested-element in tasks/types
that have add(X)-type methods, in a new mapping he called restricted
types (because they cannot use by themselve, only as nested element of
declared tasks/types).
Suppose I write FooTask in my bar AntLib. If FooTask as a
add(Condition) method, as of now, I can only use as nested elements
conditions which have been explicitly typedef'd.
Currently, there are none in Ant.
There is an antlib.xml for conditions, but I'm forced to explicitly
load it to be able to use them in my FooTask, and doing so I bring
them all into the "global" tasks/types mapping, so they can be used at
the top-level in <project> or <target>.
Peter's "restricted" types form a new mapping (I would normally say a
new namespace, but it becomes confusing because of XML namespaces...),
which is used exclusively to resolve add(X)-type methods.
This new mapping doesn't define any roles. The role that one of this
mapping will play in a task will depend on (1) the add(X) method of
that task, and (2) the types this one mapping is compatible with (in
the sense of instanceof or Class.isAssigneableFrom).
So there's no real notion of a role, IMHO. Which is why I'm not fond
of using <roledef> to declare this "restricted" types. I believe Peter
now added a 'restrict' attribute to <typedef>, which I'm also not fond
of, but it may turn out to be the less controversial choice...
No code to look at yet, since I don't think Peter posted his diffs to
BugZilla yet. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Roles [WAS:Re: Restricted types: Re: Location in non-Task tasks]
Posted by Antoine Levy-Lambert <an...@gmx.de>.
-------- Original-Nachricht --------
Datum: Wed, 13 Sep 2006 12:14:07 +0100
Von: "Peter Reilly" <pe...@gmail.com>
An: "Ant Developers List" <de...@ant.apache.org>
Betreff: Re: Roles [WAS:Re: Restricted types: Re: Location in non-Task tasks]
> I do not like the idea of a role.
>
> A class declares which Interfaces it supports - Condition, Selector
> or whatever, the java compiler and java runtime enforces that.
> There is no need for us to invent new ways to do this!
> It is complicated - and prone to bugs both in the core ant code
> and when users define them (in xml).
>
Agreed that it is fine to use the interfaces that a class declares to find out which roles this class can be used for.
Sorry I did not read all the svn commit emails. Which classes implement these role definitions ?
> Peter
>
Antoine
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Roles [WAS:Re: Restricted types: Re: Location in non-Task tasks]
Posted by Peter Reilly <pe...@gmail.com>.
On 9/13/06, Antoine Levy-Lambert <an...@gmx.de> wrote:
>
> Hi,
>
> I did not see the changes. But in principle I agree with Dominique
> that a roledef should have 3 attributes :
> name, role, classname
> or can we make the role attribute optional by finding out by
> introspection whether a class is a condition, or a selector, or a ...
> In any case we should have the field role in the table storing the
> roles in memory. It is also possible that one class be both a
> condition and a selector for instance.
> In this case, the class could be bound to different names as a
> function of its role.
I do not like the idea of a role.
A class declares which Interfaces it supports - Condition, Selector
or whatever, the java compiler and java runtime enforces that.
There is no need for us to invent new ways to do this!
It is complicated - and prone to bugs both in the core ant code
and when users define them (in xml).
Peter
Regards,
> Antoine
>
>
> On Sep 13, 2006, at 2:52 AM, Dominique Devienne wrote:
>
> >> > > however we can add the @ant.type tags now for documentation?,
> >> >
> >> > Sure, provided we settle on a doc tag name, which ideally would
> >> match
> >> > the <*def> we choose. --DD
> >>
> >>
> >> @ant.type --> <typedef>
> >> @ant.task --> <taskdef>
> >> @ant.role --> <roledef>
> >
> > Role implies (to me at least) that the name is bound to a given role,
> > like being a condition or a file selector, which would be explicitly
> > specified by name (or class name). Since your changes just bind a
> > name, without an explicit "role", it's not my favorite. I lean toward
> > <elementdef> or <tagdef> myself, the latter being my preference.
> >
> > But I'm beyond neat picking here ;-) --DD
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: Roles [WAS:Re: Restricted types: Re: Location in non-Task tasks]
Posted by Dominique Devienne <dd...@gmail.com>.
>Am I correct in assuming we'd have, with whatever name:
> <xxx name="and"
> classname="oata.taskdefs.condition.And" />
> <xxx name="and"
> classname="oata.types.selectors.AndSelector" />
I think so. Peter can correct me if I'm wrong.
> What about <def>?
> Then what about <adaptdef> or <flexdef>?
I don't like them ;-))) --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Roles [WAS:Re: Restricted types: Re: Location in non-Task tasks]
Posted by Peter Reilly <pe...@gmail.com>.
On 9/13/06, Peter Reilly <pe...@gmail.com> wrote:
>
>
>
> Some classes thus may have multiple names associated
> with them, a unique top-level name and a restricted name that
> can be s
>
Opps, I hit a emacs keystroke that sent the email...
to continue:
Some classes thus may have multiple names associated
with them, a unique top-level name and a shared name
so one could have
<andcondition> at the top-level.
<and> in the <condition> type.
Peter
Re: Roles [WAS:Re: Restricted types: Re: Location in non-Task tasks]
Posted by Dominique Devienne <dd...@gmail.com>.
> <compodef> (just kidding).
Score:5, Funny ;-)
> For me:
> <componentdef> sounds the best. Do not forget that
> this will probally not be used outside the ant core code as
> the resultant name may not be used at the top-level, or
> in targets - or sequential bodies.
I don't see why it would be limited to ant core. Any antlib that
defines custom conditions, file selectors, filter readers, etc...
should use it rather than doing a regular typedef. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Roles [WAS:Re: Restricted types: Re: Location in non-Task tasks]
Posted by Peter Reilly <pe...@gmail.com>.
On 9/13/06, Matt Benson <gu...@yahoo.com> wrote:
>
> --- Dominique Devienne <dd...@gmail.com> wrote:
>
> > > I did not see the changes. But in principle I
> > agree with Dominique
> > > that a roledef should have 3 attributes :
> > > name, role, classname
> >
> > Just to clarify, I like the way Peter implemented it
> > (binding a class
> > to a name, without specifying what "role"s this
> > class should play).
> > But the term "role" also implies to me a (name,
> > role, classname)
> > tupple, which is why I'd prefer not using <roledef>,
> > that's all.
> >
> > Last night I thought that <componentdef>, although
> > longuish, might be
> > a better term than <elementdef> or <tagdef>. --DD
>
> <componentdef> is okay, given ComponentHelper, etc.
> But agreed, long. What about <def>? Am I correct in
> assuming we'd have, with whatever name:
>
> <xxx name="and"
> classname="oata.taskdefs.condition.And" />
>
> <xxx name="and"
> classname="oata.types.selectors.AndSelector" />
Yes, this is the case.
My original idea was:
<typedef restrict="yes" name="and" classname="oata...conditon.And"/>
<typedef restrict="yes" name="and"
classname="oata...selectors.AndSelector"/>
?
>
> Then what about <adaptdef> or <flexdef>?
Other names:
<restrictdef>
<classdef>
<subdef>
<compodef> (just kidding).
For me:
<componentdef> sounds the best. Do not forget that
this will probally not be used outside the ant core code as
the resultant name may not be used at the top-level, or
in targets - or sequential bodies.
Some classes thus may have multiple names associated
with them, a unique top-level name and a restricted name that
can be s
-Matt
>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail:
> > dev-help@ant.apache.org
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: Roles [WAS:Re: Restricted types: Re: Location in non-Task tasks]
Posted by Matt Benson <gu...@yahoo.com>.
--- Dominique Devienne <dd...@gmail.com> wrote:
> > I did not see the changes. But in principle I
> agree with Dominique
> > that a roledef should have 3 attributes :
> > name, role, classname
>
> Just to clarify, I like the way Peter implemented it
> (binding a class
> to a name, without specifying what "role"s this
> class should play).
> But the term "role" also implies to me a (name,
> role, classname)
> tupple, which is why I'd prefer not using <roledef>,
> that's all.
>
> Last night I thought that <componentdef>, although
> longuish, might be
> a better term than <elementdef> or <tagdef>. --DD
<componentdef> is okay, given ComponentHelper, etc.
But agreed, long. What about <def>? Am I correct in
assuming we'd have, with whatever name:
<xxx name="and"
classname="oata.taskdefs.condition.And" />
<xxx name="and"
classname="oata.types.selectors.AndSelector" />
?
Then what about <adaptdef> or <flexdef>?
-Matt
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Roles [WAS:Re: Restricted types: Re: Location in non-Task tasks]
Posted by Dominique Devienne <dd...@gmail.com>.
> I did not see the changes. But in principle I agree with Dominique
> that a roledef should have 3 attributes :
> name, role, classname
Just to clarify, I like the way Peter implemented it (binding a class
to a name, without specifying what "role"s this class should play).
But the term "role" also implies to me a (name, role, classname)
tupple, which is why I'd prefer not using <roledef>, that's all.
Last night I thought that <componentdef>, although longuish, might be
a better term than <elementdef> or <tagdef>. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Roles [WAS:Re: Restricted types: Re: Location in non-Task tasks]
Posted by Antoine Levy-Lambert <an...@gmx.de>.
Hi,
I did not see the changes. But in principle I agree with Dominique
that a roledef should have 3 attributes :
name, role, classname
or can we make the role attribute optional by finding out by
introspection whether a class is a condition, or a selector, or a ...
In any case we should have the field role in the table storing the
roles in memory. It is also possible that one class be both a
condition and a selector for instance.
In this case, the class could be bound to different names as a
function of its role.
Regards,
Antoine
On Sep 13, 2006, at 2:52 AM, Dominique Devienne wrote:
>> > > however we can add the @ant.type tags now for documentation?,
>> >
>> > Sure, provided we settle on a doc tag name, which ideally would
>> match
>> > the <*def> we choose. --DD
>>
>>
>> @ant.type --> <typedef>
>> @ant.task --> <taskdef>
>> @ant.role --> <roledef>
>
> Role implies (to me at least) that the name is bound to a given role,
> like being a condition or a file selector, which would be explicitly
> specified by name (or class name). Since your changes just bind a
> name, without an explicit "role", it's not my favorite. I lean toward
> <elementdef> or <tagdef> myself, the latter being my preference.
>
> But I'm beyond neat picking here ;-) --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Restricted types: Re: Location in non-Task tasks
Posted by Dominique Devienne <dd...@gmail.com>.
> > > however we can add the @ant.type tags now for documentation?,
> >
> > Sure, provided we settle on a doc tag name, which ideally would match
> > the <*def> we choose. --DD
>
>
> @ant.type --> <typedef>
> @ant.task --> <taskdef>
> @ant.role --> <roledef>
Role implies (to me at least) that the name is bound to a given role,
like being a condition or a file selector, which would be explicitly
specified by name (or class name). Since your changes just bind a
name, without an explicit "role", it's not my favorite. I lean toward
<elementdef> or <tagdef> myself, the latter being my preference.
But I'm beyond neat picking here ;-) --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Restricted types: Re: Location in non-Task tasks
Posted by Peter Reilly <pe...@gmail.com>.
On 9/12/06, Dominique Devienne <dd...@gmail.com> wrote:
>
> > > > > > 2) Introduce a <tagdef> or <roledef> for the purpose
> > > > > > of locating extension points as nested elements.
>
> > Ok, I dug out my old code and after digging out some of the bugs
> > and misunderstanding, I have modded IH, CH (componenthelper),
> > and <typedef> to allow "restricted" types.
>
> Cool!!!
>
>
> > I am not too sure this should be user visible but it can be implemented
> > by an extra attribute to the typedef task - restrict=yes/no default is
> no.
>
> I'd personally prefer a new <*def>, rather than overloading <typedef>,
> perhaps called <tagdef> or <roledef> or <elementdef>.
I do not really mind what it is called, <roledef> is probally the best of
the bunch.
> One problem is that the antlib.xml for antlib:org.apache.tools.ant would
> > be long and tedious when all the conditions, selectors, mappers,
> resources
> > are added.
>
> long, for sure, for not more tedious than before. But I'm not against
> automating this, on the contrary.
>
> > To solve the startup problem, I propose that we use an AntLibDefinitions
> > class associated
> > with a name-space which would contain the definitions.
>
> Do you mean to having a .java equivalent to an antlib.xml?
Yes, it would be a class that has a public method AntTypeDefintion[]
getDefinitions().
The name of the class could be fixed <package>.AntTypeDefinitions - or
set by the jar service entry. The XML namespace would be the same as
a corresponding antlib.xml ie <package> -> antlib:<package>
> * @ant.type [restrict="yes"/"no"] [name="whatever"]
> > Where the defaults are restrict=no,
>
> Against, I'm not fond of restrict, but I wouldn't -1 is I'm the only one.
>
> > I will create a bugzilla issue where I will place the diffs and task.
> > This will not of course be for ant 1.7!,
>
> Thanks again. This is great.
>
> > however we can add the @ant.type tags now for documentation?,
>
> Sure, provided we settle on a doc tag name, which ideally would match
> the <*def> we choose. --DD
@ant.type --> <typedef>
@ant.task --> <taskdef>
@ant.role --> <roledef>
Peter
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: Restricted types: Re: Location in non-Task tasks
Posted by Dominique Devienne <dd...@gmail.com>.
> > > > > 2) Introduce a <tagdef> or <roledef> for the purpose
> > > > > of locating extension points as nested elements.
> Ok, I dug out my old code and after digging out some of the bugs
> and misunderstanding, I have modded IH, CH (componenthelper),
> and <typedef> to allow "restricted" types.
Cool!!!
> I am not too sure this should be user visible but it can be implemented
> by an extra attribute to the typedef task - restrict=yes/no default is no.
I'd personally prefer a new <*def>, rather than overloading <typedef>,
perhaps called <tagdef> or <roledef> or <elementdef>.
> One problem is that the antlib.xml for antlib:org.apache.tools.ant would
> be long and tedious when all the conditions, selectors, mappers, resources
> are added.
long, for sure, for not more tedious than before. But I'm not against
automating this, on the contrary.
> To solve the startup problem, I propose that we use an AntLibDefinitions
> class associated
> with a name-space which would contain the definitions.
Do you mean to having a .java equivalent to an antlib.xml?
> * @ant.type [restrict="yes"/"no"] [name="whatever"]
> Where the defaults are restrict=no,
Against, I'm not fond of restrict, but I wouldn't -1 is I'm the only one.
> I will create a bugzilla issue where I will place the diffs and task.
> This will not of course be for ant 1.7!,
Thanks again. This is great.
> however we can add the @ant.type tags now for documentation?,
Sure, provided we settle on a doc tag name, which ideally would match
the <*def> we choose. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org