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 <[EMAIL PROTECTED]> wrote:
On Wed, 08 Mar 2006, <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
