You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by mb...@apache.org on 2006/08/31 21:04:13 UTC
svn commit: r439014 - in
/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition:
ConditionBase.java antlib.xml
Author: mbenson
Date: Thu Aug 31 12:04:12 2006
New Revision: 439014
URL: http://svn.apache.org/viewvc?rev=439014&view=rev
Log:
Auto-discover built-in conditions added >= 1.7 from the accompanying antlib so we can stop adding junk setters to ConditionBase.
Modified:
ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition/ConditionBase.java
ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition/antlib.xml
Modified: ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition/ConditionBase.java
URL: http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition/ConditionBase.java?rev=439014&r1=439013&r2=439014&view=diff
==============================================================================
--- ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition/ConditionBase.java (original)
+++ ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition/ConditionBase.java Thu Aug 31 12:04:12 2006
@@ -19,6 +19,9 @@
import java.util.Enumeration;
import java.util.Vector;
+import org.apache.tools.ant.Project;
+import org.apache.tools.ant.DynamicElement;
+import org.apache.tools.ant.ComponentHelper;
import org.apache.tools.ant.ProjectComponent;
import org.apache.tools.ant.taskdefs.Available;
import org.apache.tools.ant.taskdefs.Checksum;
@@ -31,7 +34,11 @@
*
* @since Ant 1.4
*/
-public abstract class ConditionBase extends ProjectComponent {
+public abstract class ConditionBase extends ProjectComponent
+ implements DynamicElement {
+
+ private static final String CONDITION_ANTLIB
+ = "antlib:org.apache.tools.ant.taskdefs.condition:";
/**
* name of the component
@@ -44,17 +51,16 @@
private Vector conditions = new Vector();
/**
- * simple constructor.
+ * Simple constructor.
*/
protected ConditionBase() {
taskName = "component";
}
/**
- * constructor that takes the name of the task
- * in the task name
+ * Constructor that takes the name of the task in the task name.
* @param taskName
- * @since Ant1.7
+ * @since Ant 1.7
*/
protected ConditionBase(String taskName) {
this.taskName = taskName;
@@ -261,24 +267,6 @@
}
/**
- * Add an <typefound> condition.
- * @param test a TypeFound condition
- * @since Ant 1.7
- */
- public void addTypeFound(TypeFound test) {
- conditions.addElement(test);
- }
-
- /**
- * Add an <isfailure> condition.
- *
- * @param test the condition
- */
- public void addIsFailure(IsFailure test) {
- conditions.addElement(test);
- }
-
- /**
* Add an <isfileselected> condition.
* @param test the condition
*/
@@ -287,81 +275,30 @@
}
/**
- * Add an <isreachable> condition.
- *
- * @param test the condition
- * @since Ant 1.7
- */
- public void addIsReachable(IsReachable test) {
- conditions.addElement(test);
- }
-
- /**
- * Add an <issigned> condition.
- *
- * @param test the condition
- * @since Ant 1.7
- */
- public void addIsSigned(IsSigned test) {
- conditions.addElement(test);
- }
-
- /**
- * Add an <parsersupports> condition.
- *
- * @param test the condition
- * @since Ant 1.7
- */
- public void addParserSupports(ParserSupports test) {
- conditions.addElement(test);
- }
-
- /**
- * Add a <ResourcesMatch> condition.
- *
- * @param test the condition
- * @since Ant 1.7
- */
- public void addResourcesMatch(ResourcesMatch test) {
- conditions.addElement(test);
- }
-
- /**
- * Add an <xor> condition.
- *
- * @param test the condition
- * @since Ant 1.7
- */
- public void addXor(Xor test) {
- conditions.addElement(test);
- }
-
- /**
- * Add a <hasMethod> condition.
- *
- * @param test the condition
- * @since Ant 1.7
- */
- public void addHasMethod(HasMethod test) {
- add(test);
- }
-
- /**
- * Add an <antversion> condition.
- *
- * @param test the condition
- * @since Ant 1.7
- */
- public void addAntVersion(AntVersion test) {
- conditions.addElement(test);
- }
-
- /**
* Add an arbitrary condition
- * @param c a condition
+ * @param c a condition
* @since Ant 1.6
*/
public void add(Condition c) {
conditions.addElement(c);
}
+
+ /**
+ * Create a dynamically discovered condition. Built-in conditions can
+ * be discovered from the org.apache.tools.ant.taskdefs.condition
+ * antlib.
+ * @param name the condition to create.
+ */
+ public Object createDynamicElement(String name) {
+ Object cond = ComponentHelper.getComponentHelper(getProject())
+ .createComponent(CONDITION_ANTLIB + name);
+ if (!(cond instanceof Condition)) {
+ return null;
+ }
+ log("Dynamically discovered '" + name + "' " + cond,
+ Project.MSG_DEBUG);
+ add((Condition) cond);
+ return cond;
+ }
+
}
Modified: ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition/antlib.xml
URL: http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition/antlib.xml?rev=439014&r1=439013&r2=439014&view=diff
==============================================================================
--- ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition/antlib.xml (original)
+++ ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition/antlib.xml Thu Aug 31 12:04:12 2006
@@ -1,8 +1,8 @@
<?xml version="1.0"?>
<antlib>
<!--
- /*
- * Copyright 2006 The Apache Software Foundation
+/*
+ * Copyright 2006 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -19,11 +19,17 @@
*/
-->
- <!-- ant1.6+ antlib declaration for the conditions
- use with the declaration xmlns:cond="antlib:org.apache.tools.ant.condition" to
- trigger ant's autoload of this file into a namespace.
+ <!-- Ant 1.6+ antlib declaration for conditions:
+ Use with the declaration xmlns:cond="antlib:org.apache.tools.ant.condition" to
+ trigger Ant's autoload of this file into namespace 'cond' (or whatever name
+ suits).
- Please keep this list in alphabetical order -it is easier to verify that way
+ Please keep this list in alphabetical order; it is easier to verify that way.
+
+ Additionally, ConditionBase uses this antlib to discover built-in conditions.
+ Prior to Ant 1.7, a new built-in condition required an addXXX method to be
+ added to ConditionBase. Conditions added in or after version 1.7 need only
+ to be added to this antlib.
-->
<typedef name="and" classname="org.apache.tools.ant.taskdefs.condition.And"/>
@@ -31,7 +37,7 @@
classname="org.apache.tools.ant.taskdefs.condition.AntVersion"/>
<typedef name="contains" classname="org.apache.tools.ant.taskdefs.condition.Contains"/>
<typedef name="equals" classname="org.apache.tools.ant.taskdefs.condition.Equals"/>
- <typedef name="filesmatch" classname="org.apache.tools.ant.taskdefs.condition.Filesmatch"/>
+ <typedef name="filesmatch" classname="org.apache.tools.ant.taskdefs.condition.FilesMatch"/>
<typedef name="http" classname="org.apache.tools.ant.taskdefs.condition.Http"/>
<typedef name="isfailure" classname="org.apache.tools.ant.taskdefs.condition.IsFailure"/>
<typedef name="isfalse" classname="org.apache.tools.ant.taskdefs.condition.IsFalse"/>
@@ -50,4 +56,4 @@
<typedef name="socket" classname="org.apache.tools.ant.taskdefs.condition.Socket"/>
<typedef name="typefound" classname="org.apache.tools.ant.taskdefs.condition.TypeFound"/>
<typedef name="xor" classname="org.apache.tools.ant.taskdefs.condition.Xor"/>
-</antlib>
\ No newline at end of file
+</antlib>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: svn commit: r439014 - in /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition: ConditionBase.java antlib.xml
Posted by Dominique Devienne <dd...@gmail.com>.
> I'm still not sure I understand why inheriting from
> ConditionBase/using TaskAdapter is so terrible,
> especially if we move the location stuff up to
> ProjectComponent as Stefan proposed. What am I
> missing here?
It's not terrible, but it's not clean IMHO. It complicates the
interface quite a bit when a simple little add(Condition) should be
enough. Which makes me think in reply to Peter's comment about the
added complexity in IH, I tend to prefer adding the complexity once in
the framework, rather than N times in the "user" tasks. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: svn commit: r439014 - in /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition: ConditionBase.java antlib.xml
Posted by Matt Benson <gu...@yahoo.com>.
--- Dominique Devienne <dd...@gmail.com> wrote:
> > Surprisingly, DD, who is often more frightened by
> my
> > solutions than Peter, had no comment. ;)
>
> I thought it was clever and pragmatic. OK, maybe too
> clever ;-) But it
> reminds me of dynamic languages that allow custom
> handling of missing
> methods in classes, which is useful sometimes.
:)
>
> > 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.
>
> This is also a pragmatic solution, but I like it
> less somehow.
>
> I don't have a magic solution, but I also strongly
> agree that we
> absolutely need to go away from addTypeOfTheWeek()
> methods, and solve
> the issue ones and for all. Probably too late for
> Ant 1.7, sure, but
> I'd hate to have AntUnit go out with a legacy
> inheritance to
> ConditionBase because we didn't address this issue
> once and for all.
>
I'm still not sure I understand why inheriting from
ConditionBase/using TaskAdapter is so terrible,
especially if we move the location stuff up to
ProjectComponent as Stefan proposed. What am I
missing here?
> --DD
>
>
---------------------------------------------------------------------
> 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: svn commit: r439014 - in /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition: ConditionBase.java antlib.xml
Posted by Dominique Devienne <dd...@gmail.com>.
> Surprisingly, DD, who is often more frightened by my
> solutions than Peter, had no comment. ;)
I thought it was clever and pragmatic. OK, maybe too clever ;-) But it
reminds me of dynamic languages that allow custom handling of missing
methods in classes, which is useful sometimes.
> 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.
This is also a pragmatic solution, but I like it less somehow.
I don't have a magic solution, but I also strongly agree that we
absolutely need to go away from addTypeOfTheWeek() methods, and solve
the issue ones and for all. Probably too late for Ant 1.7, sure, but
I'd hate to have AntUnit go out with a legacy inheritance to
ConditionBase because we didn't address this issue once and for all.
--DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: svn commit: r439014 - in
/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition:
ConditionBase.java antlib.xml
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 11 Sep 2006, Matt Benson <gu...@yahoo.com> wrote:
> Looks like this chain got out of hand and killed the discussion.
Might be related to the Subject line ;-)
> But we need consensus here on what to do before 1.7 final ships.
Yes. We don't need consensus on how to deal with
newConditionOfTheWeek before the release, but on the use of
DynamicElement in ConditionBase.
I don't have any problem with ConditionBase (or AssertTask) not
extending Task, BTW.
> 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).
I'd hope that this was enough.
> 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.
Cool, but maybe too complex for this problem.
> 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.
Can't we have them both? Add them to the new antlib and define them
inside of defaults.properties?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: svn commit: r439014 - in /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition: ConditionBase.java antlib.xml
Posted by Matt Benson <gu...@yahoo.com>.
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
Re: svn commit: r439014 - in /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition: ConditionBase.java antlib.xml
Posted by Matt Benson <gu...@yahoo.com>.
--- Steve Loughran <st...@apache.org> wrote:
> Matt Benson wrote:
> > --- Steve Loughran <st...@apache.org> wrote:
> >
> >> mbenson@apache.org wrote:
> >>> Author: mbenson
> >>> Date: Thu Aug 31 12:04:12 2006
> >>> New Revision: 439014
> >>>
> >>> URL:
> >> http://svn.apache.org/viewvc?rev=439014&view=rev
> >>> Log:
> >>> Auto-discover built-in conditions added >= 1.7
> >> from the accompanying antlib so we can stop
> adding
> >> junk setters to ConditionBase.
[SNIP]
> >
> > please add new conditions to
> > oata.types.conditions/antlib.xml instead of
> > here, to avoid namespace clash with things like
> > selectors.
> >
>
>
> > I suspected, but did not bother to check, who that
> > committer was yesterday. Today I checked and
> found my
> > suspicions were correct. It was you, Steve! :)
> So
> > 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?
> >
>
> 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
>
>
>
---------------------------------------------------------------------
> 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: svn commit: r439014 - in /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition:
ConditionBase.java antlib.xml
Posted by Steve Loughran <st...@apache.org>.
Matt Benson wrote:
> --- Steve Loughran <st...@apache.org> wrote:
>
>> mbenson@apache.org wrote:
>>> Author: mbenson
>>> Date: Thu Aug 31 12:04:12 2006
>>> New Revision: 439014
>>>
>>> URL:
>> http://svn.apache.org/viewvc?rev=439014&view=rev
>>> Log:
>>> Auto-discover built-in conditions added >= 1.7
>> from the accompanying antlib so we can stop adding
>> junk setters to ConditionBase.
>>> +
>>> + /**
>>> + * Create a dynamically discovered condition.
>> Built-in conditions can
>>> + * be discovered from the
>> org.apache.tools.ant.taskdefs.condition
>>> + * antlib.
>>> + * @param name the condition to create.
>>> + */
>>> + public Object createDynamicElement(String
>> name) {
>>> + Object cond =
>> ComponentHelper.getComponentHelper(getProject())
>>> + .createComponent(CONDITION_ANTLIB +
>> name);
>>> + if (!(cond instanceof Condition)) {
>>> + return null;
>>> + }
>>> + log("Dynamically discovered '" + name +
>> "' " + cond,
>>> + Project.MSG_DEBUG);
>>> + add((Condition) cond);
>>> + return cond;
>>> + }
>>> +
>>> }
>>>
>> hmm. What happens to third party tasks that extend
>> this and already have
>> dynamic binding stuff built in. I dont know of any,
>> though I've done two
>> extensions myself, <failingwaitfor> and some little
>> toy one to count
>> conditions for the book
>>
>
> My expectation is that Dynamic(Element|Attribute)(NS)?
> have not been publicized to the point that any
> ConditionBase extension implementing DynamicElement is
> likely to exist in the wild. Anyone who has bred such
> a beast is with around 99% certainty subscribed to
> this list, and if so, he hasn't spoken up yet. Still,
> if this change stands, it could technically be
> categorized as a possible breaker in WHATSNEW. Again,
> while this is theoretically possible, I would not just
> be surprised--I would be shocked--if anyone not
> subscribed to dev@ant.ao were bitten by this.
I'd expect cactus and ant-contrib to be the only other projects that
extend these things, but they should be warned.
>
> please add new conditions to
> oata.types.conditions/antlib.xml instead of
> here, to avoid namespace clash with things like
> selectors.
>
> I suspected, but did not bother to check, who that
> committer was yesterday. Today I checked and found my
> suspicions were correct. It was you, Steve! :) So
> 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?
>
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. 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:
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.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: svn commit: r439014 - in /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition: ConditionBase.java antlib.xml
Posted by Matt Benson <gu...@yahoo.com>.
--- Steve Loughran <st...@apache.org> wrote:
> mbenson@apache.org wrote:
> > Author: mbenson
> > Date: Thu Aug 31 12:04:12 2006
> > New Revision: 439014
> >
> > URL:
> http://svn.apache.org/viewvc?rev=439014&view=rev
> > Log:
> > Auto-discover built-in conditions added >= 1.7
> from the accompanying antlib so we can stop adding
> junk setters to ConditionBase.
> >
>
> > +
> > + /**
> > + * Create a dynamically discovered condition.
> Built-in conditions can
> > + * be discovered from the
> org.apache.tools.ant.taskdefs.condition
> > + * antlib.
> > + * @param name the condition to create.
> > + */
> > + public Object createDynamicElement(String
> name) {
> > + Object cond =
> ComponentHelper.getComponentHelper(getProject())
> > + .createComponent(CONDITION_ANTLIB +
> name);
> > + if (!(cond instanceof Condition)) {
> > + return null;
> > + }
> > + log("Dynamically discovered '" + name +
> "' " + cond,
> > + Project.MSG_DEBUG);
> > + add((Condition) cond);
> > + return cond;
> > + }
> > +
> > }
> >
>
> hmm. What happens to third party tasks that extend
> this and already have
> dynamic binding stuff built in. I dont know of any,
> though I've done two
> extensions myself, <failingwaitfor> and some little
> toy one to count
> conditions for the book
>
My expectation is that Dynamic(Element|Attribute)(NS)?
have not been publicized to the point that any
ConditionBase extension implementing DynamicElement is
likely to exist in the wild. Anyone who has bred such
a beast is with around 99% certainty subscribed to
this list, and if so, he hasn't spoken up yet. Still,
if this change stands, it could technically be
categorized as a possible breaker in WHATSNEW. Again,
while this is theoretically possible, I would not just
be surprised--I would be shocked--if anyone not
subscribed to dev@ant.ao were bitten by this.
>
> package org.antbook.conditions;
>
> import
>
org.apache.tools.ant.taskdefs.condition.ConditionBase;
> import
> org.apache.tools.ant.taskdefs.condition.Condition;
> import java.util.Enumeration;
>
> public class CountConditions extends ConditionBase {
>
> public void execute() {
> int passes=0;
> int failures=0;
> Enumeration conditions = getConditions();
> while (conditions.hasMoreElements()) {
> Condition c = (Condition)
> conditions.nextElement();
> boolean pass=c.eval();
> if(pass) {
> passes++;
> } else {
> failures++;
> }
> }
> log("Conditions passing: "+passes+"
> failing: "+failures);
> }
> }
>
> Personally, I'd like add(Condition) just to work :)
>
As Peter said, just "def"ing new conditions should be
a viable alternative. The likely sources of
collision--and/or/not/etc--are already accounted for
with setters. Before, I mentioned that some committer
had written 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.
I suspected, but did not bother to check, who that
committer was yesterday. Today I checked and found my
suspicions were correct. It was you, Steve! :) So
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?
-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: svn commit: r439014 - in /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition:
ConditionBase.java antlib.xml
Posted by Steve Loughran <st...@apache.org>.
mbenson@apache.org wrote:
> Author: mbenson
> Date: Thu Aug 31 12:04:12 2006
> New Revision: 439014
>
> URL: http://svn.apache.org/viewvc?rev=439014&view=rev
> Log:
> Auto-discover built-in conditions added >= 1.7 from the accompanying antlib so we can stop adding junk setters to ConditionBase.
>
> +
> + /**
> + * Create a dynamically discovered condition. Built-in conditions can
> + * be discovered from the org.apache.tools.ant.taskdefs.condition
> + * antlib.
> + * @param name the condition to create.
> + */
> + public Object createDynamicElement(String name) {
> + Object cond = ComponentHelper.getComponentHelper(getProject())
> + .createComponent(CONDITION_ANTLIB + name);
> + if (!(cond instanceof Condition)) {
> + return null;
> + }
> + log("Dynamically discovered '" + name + "' " + cond,
> + Project.MSG_DEBUG);
> + add((Condition) cond);
> + return cond;
> + }
> +
> }
>
hmm. What happens to third party tasks that extend this and already have
dynamic binding stuff built in. I dont know of any, though I've done two
extensions myself, <failingwaitfor> and some little toy one to count
conditions for the book
package org.antbook.conditions;
import org.apache.tools.ant.taskdefs.condition.ConditionBase;
import org.apache.tools.ant.taskdefs.condition.Condition;
import java.util.Enumeration;
public class CountConditions extends ConditionBase {
public void execute() {
int passes=0;
int failures=0;
Enumeration conditions = getConditions();
while (conditions.hasMoreElements()) {
Condition c = (Condition) conditions.nextElement();
boolean pass=c.eval();
if(pass) {
passes++;
} else {
failures++;
}
}
log("Conditions passing: "+passes+" failing: "+failures);
}
}
Personally, I'd like add(Condition) just to work :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: svn commit: r439014 - in /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition: ConditionBase.java antlib.xml
Posted by Matt Benson <gu...@yahoo.com>.
If we don't have to retain API compatibility from
1.7beta1 to 1.7beta2... :)
Thanks,
Matt
--- Antoine Levy-Lambert <an...@gmx.de> wrote:
> Hello,
>
> this sounds cool.
>
> Regards,
>
> Antoine
> -------- Original-Nachricht --------
> Datum: Thu, 31 Aug 2006 19:04:13 -0000
> Von: mbenson@apache.org
> An: ant-cvs@apache.org
> Betreff: svn commit: r439014 - in
>
/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition:
> ConditionBase.java antlib.xml
>
> > Author: mbenson
> > Date: Thu Aug 31 12:04:12 2006
> > New Revision: 439014
> >
> > URL:
> http://svn.apache.org/viewvc?rev=439014&view=rev
> > Log:
> > Auto-discover built-in conditions added >= 1.7
> from the accompanying
> > antlib so we can stop adding junk setters to
> ConditionBase.
> >
> > Modified:
> >
> >
>
>
---------------------------------------------------------------------
> 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: svn commit: r439014 - in
/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition:
ConditionBase.java antlib.xml
Posted by Antoine Levy-Lambert <an...@gmx.de>.
Hello,
this sounds cool.
Regards,
Antoine
-------- Original-Nachricht --------
Datum: Thu, 31 Aug 2006 19:04:13 -0000
Von: mbenson@apache.org
An: ant-cvs@apache.org
Betreff: svn commit: r439014 - in /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition: ConditionBase.java antlib.xml
> Author: mbenson
> Date: Thu Aug 31 12:04:12 2006
> New Revision: 439014
>
> URL: http://svn.apache.org/viewvc?rev=439014&view=rev
> Log:
> Auto-discover built-in conditions added >= 1.7 from the accompanying
> antlib so we can stop adding junk setters to ConditionBase.
>
> Modified:
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: svn commit: r439014 - in /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition: ConditionBase.java antlib.xml
Posted by Matt Benson <gu...@yahoo.com>.
--- Peter Reilly <pe...@gmail.com> wrote:
> On 8/31/06, mbenson@apache.org <mb...@apache.org>
> wrote:
> >
> > Author: mbenson
> > Date: Thu Aug 31 12:04:12 2006
> > New Revision: 439014
> >
> > URL:
> http://svn.apache.org/viewvc?rev=439014&view=rev
> > Log:
> > Auto-discover built-in conditions added >= 1.7
> from the accompanying
> > antlib so we can stop adding junk setters to
> ConditionBase.
> > ...
>
> I do not like this change.
:(
>
> 1) mixing add(Type) and createDynamicElement() is
> normally not
> good.
IH handles it; add(Type) gets precedence, as I think
it should... is there really a "normally" where
Dynamic(Element|Attribute)(NS)? are concerned; i.e.
are they really used widely enough to say what is
"normal" use?
> 2) this is a strange way to use antlibs (nice but
> strange).
IMHO it's not really any stranger than ComponentHelper
knowing that no ns usually means ant-core.
>
> 3) most of the types can be put in
> o.a.t.a.types.default.properties without
> problems (isX or Xcondition).
>
This is probably true, but there needs to be consensus
here because someone commented
oata.types/defaults.properties with the idea of adding
conditions only to the antlib in question. I just
think we can do better than adding a setter every time
we ship a new condition.
-Matt
> Peter
>
__________________________________________________
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: svn commit: r439014 - in /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition: ConditionBase.java antlib.xml
Posted by Peter Reilly <pe...@gmail.com>.
On 8/31/06, mbenson@apache.org <mb...@apache.org> wrote:
>
> Author: mbenson
> Date: Thu Aug 31 12:04:12 2006
> New Revision: 439014
>
> URL: http://svn.apache.org/viewvc?rev=439014&view=rev
> Log:
> Auto-discover built-in conditions added >= 1.7 from the accompanying
> antlib so we can stop adding junk setters to ConditionBase.
> ...
I do not like this change.
1) mixing add(Type) and createDynamicElement() is normally not
good.
2) this is a strange way to use antlibs (nice but strange).
3) most of the types can be put in o.a.t.a.types.default.properties without
problems (isX or Xcondition).
Peter