Stefan Bodewig wrote:
This would still work - due to the normal ant-reflection on the addOr() method.On Fri, 20 Feb 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
I meant that the core - conditions, filters, mappers can be in
separate namespaces, but that these could still be in ant.jar, one
can have multiple antlib.xml 's in ant.jar.
Wouldn't that break backwards compatibility?
<condition>
<or>
<condition xmlns:c="antlib:org.apache.tools.ant.types.condition"> <or> <c:and> <c:equals arg1="b" arg2="${outputstring}"/> <c:equals arg1="a" arg2="${inputstring}"/> </c:and> <equals arg1="a" arg2="${y}"/> <c:contains string="${basedir}" substring="home"/> </or> </condition>
New core conditions would not be added to the ConditionBase class so:
<condition xmlns:c="antlib:org.apache.tools.ant.types.condition">
<c:filetype type="gif" file="${my_image_file}"/>
</condition>
would work,
but <condition>
<filetype type="gif" file="${my_image_file}"/>
</condition>
would not.
Peter
wouldn't work anymore as <or> would now live in a namespace different from <condition>.
Having a ant-javah.jar, ant-javac.jar ... would seem to be a bit
excessive.
Agreed.
- However I assume you mean that some of the core tasks/types could
be in logical separate jars.
Some middle ground. Grouping related tasks into one jar, but having no single task or type left in ant.jar. I understand that this is exactly the opposite of what you prefer.
My current feeling is that restricted types/roles are not necessary,
one can use namespaces to distingish condition <or> from selector
<or>.
But only if they are not in the same namespace. They are now, or would be if they were defined as types.
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]