svn commit: r384261 - /ant/core/trunk/src/main/org/apache/tools/ant/types/defaults.properties

[st...@apache.org]

Author: stevel
Date: Wed Mar  8 08:38:44 2006
New Revision: 384261

URL: http://svn.apache.org/viewcvs?rev=384261&view=rev
Log:
we should have done this for ant1.6. Now my backwards compatible task has to copy in all the well-known condition names.

Modified:
    ant/core/trunk/src/main/org/apache/tools/ant/types/defaults.properties

Modified: ant/core/trunk/src/main/org/apache/tools/ant/types/defaults.properties
URL: http://svn.apache.org/viewcvs/ant/core/trunk/src/main/org/apache/tools/ant/types/defaults.properties?rev=384261&r1=384260&r2=384261&view=diff
==============================================================================
--- ant/core/trunk/src/main/org/apache/tools/ant/types/defaults.properties (original)
+++ ant/core/trunk/src/main/org/apache/tools/ant/types/defaults.properties Wed Mar  8 08:38:44 2006
@@ -31,15 +31,28 @@
 chainedmapper=org.apache.tools.ant.util.ChainedMapper
 filtermapper=org.apache.tools.ant.types.mappers.FilterMapper
 
-#conditions:
-issigned=org.apache.tools.ant.taskdefs.condition.IsSigned
+#all conditions, in alphabetical order
+and=org.apache.tools.ant.taskdefs.condition.And
+contains=org.apache.tools.ant.taskdefs.condition.Contains
+equals=org.apache.tools.ant.taskdefs.condition.Equals
+filesmatch=org.apache.tools.ant.taskdefs.condition.Filesmatch
+http=org.apache.tools.ant.taskdefs.condition.Http
+isfailure=org.apache.tools.ant.taskdefs.condition.IsFailure
+isfalse=org.apache.tools.ant.taskdefs.condition.IsFalse
 isfileselected=org.apache.tools.ant.taskdefs.condition.IsFileSelected
 isreachable=org.apache.tools.ant.taskdefs.condition.IsReachable
-scriptcondition=org.apache.tools.ant.types.optional.ScriptCondition
-xor=org.apache.tools.ant.taskdefs.condition.Xor
+isreference=org.apache.tools.ant.taskdefs.condition.IsReference
+isset=org.apache.tools.ant.taskdefs.condition.IsSet
+issigned=org.apache.tools.ant.taskdefs.condition.IsSigned
+istrue=org.apache.tools.ant.taskdefs.condition.IsTrue
+not=org.apache.tools.ant.taskdefs.condition.Not
+or=org.apache.tools.ant.taskdefs.condition.Or
+os=org.apache.tools.ant.taskdefs.condition.Os
 parsersupports=org.apache.tools.ant.taskdefs.condition.ParserSupports
-isfailure=org.apache.tools.ant.taskdefs.condition.IsFailure
 resourcesmatch=org.apache.tools.ant.taskdefs.condition.ResourcesMatch
+scriptcondition=org.apache.tools.ant.types.optional.ScriptCondition
+socket=org.apache.tools.ant.taskdefs.condition.Socket
+xor=org.apache.tools.ant.taskdefs.condition.Xor
 
 #ResourceCollections:
 dirset=org.apache.tools.ant.types.DirSet



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: svn commit: r384261 - /ant/core/trunk/src/main/org/apache/tools/ant/types/defaults.properties

[Steve Loughran <st...@apache.org>]

Stefan Bodewig wrote:
> On Wed, 08 Mar 2006, <st...@apache.org> wrote:
> 
>> Now my backwards compatible task has to copy in all the well-known
>> condition names.
> 
> ... or extend ConditionBase, this is well known.

yes, and then you encounter the problem that you can't directly insert 
into sequences without using the adaptor.

> 
> Still, your solution only solves part of the problem since we now have
> <and> defined as a condition, but there also is a file selector by
> that name (and custom file selector containers face the same problem
> as custom condition containers).
> 
> I'd rather have them defined in a separate conditions antlib
> descriptor as well as a separate selectors antlib descriptor and have
> the user simply refere to them via namespaces.

That we could do, yes indeed. Just stick them in conditions/antlib.xml

I could put everything in there, even the ones that were added in 
defaults.properties for ant1.7. That would just leave the 1.6-era 
conditions in defaults.properties.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: svn commit: r384261 - /ant/core/trunk/src/main/org/apache/tools/ant/types/defaults.properties

[Steve Loughran <st...@apache.org>]

Peter Reilly wrote:
> I agree with Stefan,
> we cannot have "and" etc in defaults.properties
> 
> I tried this before by making the and implementation
> class implement both the condition "and" and the file selector "and"
> but it was not a scalable solution.
> 

I've rolled back, and left a note in defaults.properties to remind people.
I also had to patch ConditionBase to know about every condition we added 
since ant1.6.5, with
the sole exception of scriptcondition, which I do declare in 
defaults.properties

Now, we could create a new package typedefs.optional.conditions and
  -move the task there
  -add a new antlib for all optional conditions.
This would make it easier to set the classpath up right for scriptcondition.

-steve

> 
> On 3/12/06, Stefan Bodewig <bo...@apache.org> wrote:
>> On Wed, 08 Mar 2006, <st...@apache.org> wrote:
>>
>>> Now my backwards compatible task has to copy in all the well-known
>>> condition names.
>> ... or extend ConditionBase, this is well known.
>>
>> Still, your solution only solves part of the problem since we now have
>> <and> defined as a condition, but there also is a file selector by
>> that name (and custom file selector containers face the same problem
>> as custom condition containers).
>>
>> I'd rather have them defined in a separate conditions antlib
>> descriptor as well as a separate selectors antlib descriptor and have
>> the user simply refere to them via namespaces.
>>
>> Stefan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: svn commit: r384261 - /ant/core/trunk/src/main/org/apache/tools/ant/types/defaults.properties

[Peter Reilly <pe...@gmail.com>]

I agree with Stefan,
we cannot have "and" etc in defaults.properties

I tried this before by making the and implementation
class implement both the condition "and" and the file selector "and"
but it was not a scalable solution.

Peter


On 3/12/06, Stefan Bodewig <bo...@apache.org> wrote:
>
> On Wed, 08 Mar 2006, <st...@apache.org> wrote:
>
> > Now my backwards compatible task has to copy in all the well-known
> > condition names.
>
> ... or extend ConditionBase, this is well known.
>
> Still, your solution only solves part of the problem since we now have
> <and> defined as a condition, but there also is a file selector by
> that name (and custom file selector containers face the same problem
> as custom condition containers).
>
> I'd rather have them defined in a separate conditions antlib
> descriptor as well as a separate selectors antlib descriptor and have
> the user simply refere to them via namespaces.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>

Re: svn commit: r384261 - /ant/core/trunk/src/main/org/apache/tools/ant/types/defaults.properties

[Stefan Bodewig <bo...@apache.org>]

On Wed, 08 Mar 2006, <st...@apache.org> wrote:

> Now my backwards compatible task has to copy in all the well-known
> condition names.

... or extend ConditionBase, this is well known.

Still, your solution only solves part of the problem since we now have
<and> defined as a condition, but there also is a file selector by
that name (and custom file selector containers face the same problem
as custom condition containers).

I'd rather have them defined in a separate conditions antlib
descriptor as well as a separate selectors antlib descriptor and have
the user simply refere to them via namespaces.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org