However on thinking about this (naming problem, namespace issues, types etc) I
realized that one could use the antlib scheme to solve the problem:
For example:
<target name="x" xmlns:c="antlib:org.apache.tools.ant.types.conditions">
<c:or id="or.ref">
<c:equals arg1="a" arg2="a"/>
<c:equals arg1="b" arg2="b"/>
</c:or> <condition property="p">
<c:reference refid="or.ref"/>
</condition></target>
I used the new package for conditions to allow consistence:
org.apache.tools.ant.types.conditions org.apache.tools.ant.types.selectors org.apache.tools.ant.types.mappers org.apache.tools.ant.types.filters
New conditions/selectors could be just placed in the relevant antlib.xml with no need to modify any container code.
The neat thing with this approach is that 1) we get to eat our own dogfood - using antlib/namespaces. 2) no need to make IntrospectionHelper more complicated.
Peter
Stefan Bodewig wrote:
On Thu, 12 Feb 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
I have reactivated my code for restricted/roled types.
I think we need that in order to decompose ant.jar.
If this means making multiple jars from ant.jar, I would be against.
The basic idea is that one can define a type that can only
be used as a nested element in a type container. The type
may not be used at the top-level.
Hmm, is the later restriction realy needed? How about requiring a qualification for them when they are used at the top level?
<or id="needs.jdk1.3+"
contract="org.apache.tools.ant...Selector">
<filename name="${ant.package}/taskdefs/TestProcess*"/>
<filename name="${optional.package}/extension/**"/>
</or>
This sounds like a good idea however it may be difficult to implement. One problem would be the attribute for the role or contract - it would need to be something like "ant-role" to avoid clashes with reflection discovered attributes.
Take a look at Ant's own build file, it uses <selector> which is a simple container, but we may need something like this for conditions as well.
The user-level issues would be: Is the attribute "contact" a good
name for this attribute
Even if spelled correctly ;-) I'm not convinced that contract is
something the user may understand. role is probably better. This
is not a very strong preference.
"role" would be fine
And I'd like to have shorter names, somehow. role="condition".This becomes a naming problem... One would have to define the
mapping between the role and the class the type would need be an instanceof.
This mapping may need to be unique through a number of third party antlibs - a
world of pain unless use is made of xml namespaces.
Should this be a separate task and not typedef.
I don't have a problem with using typedef for it.
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]
