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: antlib
Date Thu, 22 May 2003 10:25:36 GMT
I also think the roles concept is good for the following reasons:

  * The current implemention of conditions/selectors/filters (a
    big sequence of add<Name>()) is tightly coupled.
    The implementation means that new conditions/selectors/filters
    (to be used in the same way as current conditions/selectors/filters)
    mean modification to core ant code. This is not nice and not
    in the spirit of adding new datatype and new tasks.

  * Use of the add(Type) pattern allowing datatypes/tasks to
    be used partially addresses this. But it is not a complete
    solution:  the names are global, current selectors/conditions
    are not, currently use of "and" is context-dependant, it is
    both a selector and a condition and cannot be used in a target
    or at the top level.

The only issue with roles is how to implement them so that the definitions
defined behave in the same way as current conditions/selectors and the
big sequence of add<Name>() methods could be removed. (For BC reasons
they will never be removed ;-)).

My proposal is that <typedef/> is extended (again) to have the
attribute "role" which restricts this definition to only be used
only in the context of add[Configured](Type) and the polymorhic attribute.

A snippet from the antlib.xml file for ant: (after removing
the explicit add<Name>(..) methods from ConditionBase and the
interface and various impls of SelectorContainer.

  <!--    =================================================== -->
  <!--               Define a number of roles                 -->
  <!--    =================================================== -->

  <extendtype name="conditiondef">
    <typedef role="org.apache.tools.ant.taskdefs.condition.Condition"
             onerror="report" />
  </extendtype>

  <extendtype name="selectordef">
    <typedef role="org.apache.tools.ant.types.selectors.FileSelector"
             onerror="report"/>
  </extendtype>

  <!--    =================================================== -->
  <!--                      conditions                        -->
  <!--    =================================================== -->

  <conditiondef name="not" 
                classname="org.apache.tools.ant.taskdefs.condition.Not"/>
  <conditiondef name="and" 
                classname="org.apache.tools.ant.taskdefs.condition.And"/>
  <conditiondef name="or" 
                classname="org.apache.tools.ant.taskdefs.condition.Or"/>
  
  <!--    =================================================== -->
  <!--                      selectors                         -->
  <!--    =================================================== -->

  <selectordef
    name="and"
    classname="org.apache.tools.ant.types.selectors.AndSelector"/>
  <selectordef
    name="contains"
    classname="org.apache.tools.ant.types.selectors.ContainsSelector"/>

Peter

On Thursday 22 May 2003 10:37, Antoine Levy-Lambert wrote:
> I think that roles add clarity to description of datatypes or components. I
> liked the syntax of the antlib descriptor proposed by Jose Alberto, which
> in my example with shapes would have been :
> <antlib version="1.5" >
>   <task name="computearea" class="org.apache.demo.ComputeAreaTask"/>
>   <task name="computeperimeter"
> class="org.apache.demo.ComputePerimeterTask"/>
>  <role name="shape" class="org.apache.demo.ShapeInterface"/>
>   ...
>   <shape name="circle" class="org.apache.demo.Circle"/>
>   <shape name="square" class="org.apache.demo.Square"/>
>   ...
> </antlib>
> Reading this, and knowing that computearea and computeperimeter accept
> shapes as nested element, a build file writer would know that <circle/> and
> <square/> can be nested inside <computearea/> and <computeperimeter/>.
This
> descriptor also says that ShapeInterface should have a special meaning for
> ant, which for instance Serializable, Cloneable, ... do not necessarily
> have.
>
> However, if , as it sounds, I am the only committer who expresses support
> for roles, I will give up on that subject.
>
> Antoine
>
> ----- Original Message -----
> From: "Costin Manolache" <cmanolache@yahoo.com>
> To: <dev@ant.apache.org>
> Sent: Thursday, May 22, 2003 7:02 AM
> Subject: Re: antlib
>
> > Conor MacNeill wrote:
> > > On Thu, 22 May 2003 01:02 am, Jose Alberto Fernandez wrote:
> > >> Whatever we adopt, it definetly need to be written from scratch. :-)
> > >
> > > Cool. All I had to go on was the code. If we agree that roles are based
>
> on
>
> > > the interface implemented by the nested element, that is good. It was
> > > my main concern. I still don't really see the need for roles but that's
>
> just
>
> > > me :-) Go for it.
> >
> > I don't think it's just you, I'm on the same side.
> >
> > Probably a small poll on the remaining issues would help clarify where
> > the majority stands. I think most people are willing to accept a range of
> > solutions, and a lot is a matter of taste and prefference.
> >
> > So far I've heard the strong opinion of Jose on roles - and I'm not sure
> > on the other's opinions. There are 2 negative opinions so far. If we
>
> decide
>
> > to add roles, I would like to be clear where other committers stand.
> >
> > Costin
> >
> >
> > ---------------------------------------------------------------------
> > 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