ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Reilly <peter.rei...@corvil.com>
Subject Re: roles, restricted types
Date Tue, 17 Feb 2004 10:20:08 GMT
See inline for comments.
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 <peter.reilly@corvil.com> 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: 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


Mime
View raw message