On Tue, 12 Sep 2006, Peter Reilly <[EMAIL PROTECTED]> 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 to allow "restricted" types.
>
> These are like normal types except:
> 1) they are only allowed
Matt Benson wrote:
--- Steve Loughran <[EMAIL PROTECTED]> wrote:
Or to have a ConditionTaskBase extends Task. not
having condition base
extends task causes lots of fun whenever you have
any component that
takes a ref to a nested task with an addTask(Task)
thing.
Steve, I was just reading b
--- Steve Loughran <[EMAIL PROTECTED]> wrote:
>
> Or to have a ConditionTaskBase extends Task. not
> having condition base
> extends task causes lots of fun whenever you have
> any component that
> takes a ref to a nested task with an addTask(Task)
> thing.
>
Steve, I was just reading back thr
On 9/13/06, Peter Reilly <[EMAIL PROTECTED]> 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 assoc
(just kidding).
Score:5, Funny ;-)
For me:
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
On 9/13/06, Matt Benson <[EMAIL PROTECTED]> wrote:
--- Dominique Devienne <[EMAIL PROTECTED]> 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 impleme
Am I correct in assuming we'd have, with whatever name:
I think so. Peter can correct me if I'm wrong.
What about ?
Then what about or ?
I don't like them ;-))) --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additi
Thanks,
this is good summing up.
On 9/13/06, Dominique Devienne <[EMAIL PROTECTED]> 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 tas
--- Dominique Devienne <[EMAIL PROTECTED]> 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 speci
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 t
Original-Nachricht
Datum: Wed, 13 Sep 2006 12:14:07 +0100
Von: "Peter Reilly" <[EMAIL PROTECTED]>
An: "Ant Developers List"
Betreff: Re: Roles [WAS:Re: Restricted types: Re: Location in non-Task tasks]
> I do not like the idea of a role.
>
>
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 im
On 9/13/06, Antoine Levy-Lambert <[EMAIL PROTECTED]> 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 cond
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
> > 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 -->
@ant.task -->
@ant.role -->
Role implies (to me at least) that the name is bound to a given role,
like bein
On 9/12/06, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > > > > 2) Introduce a or 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),
>
> > > > 2) Introduce a or 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 to allow "restricted" types.
Cool!!!
I am not too sure th
On 9/11/06, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > > 2) Introduce a or 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 co
On Mon, 11 Sep 2006, Peter Reilly <[EMAIL PROTECTED]> wrote:
> it is in antlib:org.apache.tools.ant.taskdefs.condition
> (possibly should be in o.a.t.a.types.condition !)
+1
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
F
On Mon, 11 Sep 2006, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> 1) Have an Ant-conditions antlib, and force users of AntUnit to
> explicit load it, with or without using an XML namespace. I'd be
> fine with this myself.
We could even add a into AntUnit's antlib.xml and pull the
defined cond
--- Steve Loughran <[EMAIL PROTECTED]> wrote:
> Stefan Bodewig wrote:
>
> > On Sun, 10 Sep 2006, Dominique Devienne
> <[EMAIL PROTECTED]> wrote:
> >>> However, it is a pity that AssetTask has to
> extend
> >>> ConditionBase ... oh well.
> >> It doesn't "have to", does it? All it needs is an
> add
Stefan Bodewig wrote:
On Sun, 10 Sep 2006, Dominique Devienne <[EMAIL PROTECTED]> wrote:
However, it is a pity that AssetTask has to extend
ConditionBase ... oh well.
It doesn't "have to", does it? All it needs is an add(Condition)
method, no?
No. Most of the "old" conditions are not ed and
Stefan Bodewig wrote:
Hi,
I just added the feature to print the line number an error occured on
in AntUnit's plainlistener.
I must admit that my error messages are sometimes not chosen well
enough so having the line number to know which assertion in a longer
testcase failed helps me a lot in J/
> > 2) Introduce a or 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 mec
On 9/11/06, Matt Benson <[EMAIL PROTECTED]> wrote:
--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > >> However, it is a pity that AssetTask has to
> extend
> > >> ConditionBase ... oh well.
> > >
> > > It doesn't "have to", does it? All it needs is
> an add(Condition)
> > > method, no?
> >
--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > >> However, it is a pity that AssetTask has to
> extend
> > >> ConditionBase ... oh well.
> > >
> > > It doesn't "have to", does it? All it needs is
> an add(Condition)
> > > method, no?
> >
> > No. Most of the "old" conditions are not
> ed an
>> However, it is a pity that AssetTask has to extend
>> ConditionBase ... oh well.
>
> It doesn't "have to", does it? All it needs is an add(Condition)
> method, no?
No. Most of the "old" conditions are not ed and so don't
have a "name" of their own, you can't add them to a task that only has
a
On Sun, 10 Sep 2006, Dominique Devienne <[EMAIL PROTECTED]> wrote:
>
>> However, it is a pity that AssetTask has to extend
>> ConditionBase ... oh well.
>
> It doesn't "have to", does it? All it needs is an add(Condition)
> method, no?
No. Most of the "old" conditions are not ed and so don't
ha
Bonjour Stefan,
Original-Nachricht
Datum: Sat, 09 Sep 2006 22:03:16 +0200
Von: Stefan Bodewig <[EMAIL PROTECTED]>
An: dev@ant.apache.org
Betreff: Location in non-Task tasks
> Hi,
>
> I just added the feature to print the line number an error occured on
> in AntUnit's plainliste
However, it is a pity that AssetTask has to extend
ConditionBase ... oh well.
It doesn't "have to", does it? All it needs is an add(Condition)
method, no? --DD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands
I think that Location handling should be at the project
component level, being there could make better
reporting of nested elements. So +1 for handling
of Location in ProjectComponent.
However, it is a pity that AssetTask has to extend
ConditionBase ... oh well.
Peter
On 9/9/06, Stefan Bodew
31 matches
Mail list logo
