ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: svn commit: r439014 - in /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition: ConditionBase.java antlib.xml
Date Mon, 11 Sep 2006 15:18:09 GMT
Looks like this chain got out of hand and killed the
discussion.  But we need consensus here on what to do
before 1.7 final ships.  Background:  My assertion is
that we should no longer allow the proliferation of
addNewConditionOfTheWeek() methods on ConditionBase;
my (unorthodox as usual) solution was to allow
business as usual in ConditionBase first:  check for
explicitly named addFoo() methods, then check for
def'd conditions with add(Condition).  The
modification is to then implement DynamicElement in
ConditionBase so that when the first two introspection
methods fail; ConditionBase's DynamicElement
implementation searches for a matching condition by
prepending the
antlib:org.apache.tools.ant.taskdefs.condition ns to
the element name and searching the Project's
ComponentHelper for the corresponding definition.

Reactions were varied.  Antoine thought it sounded
cool (Thanks!).  Peter didn't like it and suggested we
simply define all new/non-colliding conditions.  Steve
voiced concern wrt third-party ConditionBase
extensions already implementing DynamicElement but
conceded (IIUC) that risk was low.  Surprisingly, DD,
who is often more frightened by my solutions than
Peter, had no comment.  ;)

Peter's suggestion to define as many conditions as we
can competes with an earlier imperative to add new
conditions only to the new condition antlib mentioned
above.

I have attempted (with dubious success) to edit down
the thread, since the last activity on the thread was
my (sadly, ignored) response to Steve:  ;)

(RE this warning in oata/types/defaults.properties: )
> > > 
> > > please add new conditions to
> > > oata.types.conditions/antlib.xml instead of
> > > here, to avoid namespace clash with things like
> > > selectors.
> > > 
> > 
(Me to Steve:)
> > > do you recall your train of thought when you
> added
> > > this admonition to the properties file?  Do you
> > > retract that opinion; shall we doubly define
> > > non-colliding conditions in the antlib as well
> as
> > > oata.types/defaults.properties?

( > > = Steve.  > = Me: )
> > I think Stefan told me off :)
> > 
> > Here's the problem
> > 
> > -ant's core conditions are not defined as types
> > -third party classes cannot go add(Condition) and
> > get all conditions
> > -I stuck the antlib in to make it possible, but
> dont
> > think we have any 
> > tests for it being included in the JAR
> > -If you do make them a type, there is the problem
> > that a <contains> 
> > selector already exists, and now we have a
> > <contains> test.
> > 
> > To make things more entertaining, if you do extend
> > ConditionBase, you 
> > don't have a task.
> 
> But with taskadapters, can't any class with an
> execute() method function as a task?  As does
> <condition>?
> 
> > This really annoyed julio, when
> > he was adding the 
> > smartfrog component for ant (the one that lets you
> > use ant stuff in a 
> > smartfrog descriptor, as opposed to the ant tasks
> > for smartfrog).
> > 
> > I had fun in FaultingWaitFor, where I had to
> > reimplement waitfor as a 
> > task. I cannot get at any of the ant1.7 stuff
> unless
> > it is defined as a 
> > condition, because my code needs to build on
> ant1.6:
> > 
> 
> Are you saying that the smartfrog stuff uses Ant
> tasks, but needs true tasks?  Hmm.
> 
> >
>
http://smartfrog.cvs.sourceforge.net/smartfrog/core/extras/ant/src/org/smartfrog/tools/ant/FaultingWaitForTask.java?view=markup
> > 
> > To make things more complex, this task gets nested
> > in a <functionaltest> 
> > task that has a setup, probe, test and application
> > in parallel and a 
> > finally sequence that runs after the tests. It has
> 
> > an order like
> > 
> >             setup
> >          /               \
> >    application   probe (until probe passes or
> > timeout)
> >           |           test
> >           |          finally
> >           \           /
> >         finished
> > 
> > We use it for functional testing, obviously.
> > 
> >
>
http://smartfrog.cvs.sourceforge.net/smartfrog/core/extras/ant/src/org/smartfrog/tools/ant/FunctionalTestTask.java?view=markup
> > 
> > DynamicElement has been round since 1.5; the NS is
> > more recent, and I 
> > dont go near it myself.
> > 
> 
> So what does all this mean for the issue at hand? 
> :)
> 
> -Matt
> 
> > -steve


__________________________________________________
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


Mime
View raw message