ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Inger <ma...@sedonacorp.com>
Subject Re: [PATCH] PropertyCopy and Foreach (NEW OPTIONAL TASKS)
Date Fri, 21 Sep 2001 20:37:27 GMT
WORK IN PROGRESS......  Sourceforge.net
I'm going to call it ant-contrib.
It will use the Apache Software License.

I'm going to make some guidelines on it though.
One of them will be the package name they go into,
but i want to clear this with the ant community.
I propose:
  org.apache.tools.ant.contrib
            /   |    \
        types  util   taskdefs


This would avoid clashes with any other
classes in the core or optional jar, while
still maintaining a reasonably similar
structure to the existing ANT.

On Fri, 2001-09-21 at 16:23, David Jencks wrote:
> There's been a lot of discussion of this, and there is this page of
> external projects:
> 
> http://jakarta.apache.org/ant/external.html
> 
> I think it will simply take someone who has the time to set up a
> sourceforge project for this and have the ant people link to it.  Do you
> have the time?
> 
> david jencks
> 
> On 2001.09.21 15:57:51 -0400 Matthew Inger wrote:
> > I don't think we're necessarily referring to the
> > "foreach" type tasks.  And I think you're misunderstanding
> > what we're griping about.  You mention adding things to
> > the "core".  That is not where we propose these things
> > to be.  We are looking to put stuff in the "optional"
> > tasks.  In addition to "foreach", i have posted several
> > tasks, such as "PropertyCopy", "ReplaceRegExp", and a
> > few others.  But they keep getting rejected.
> > 
> > I never proposed putting anything in the core.  I would
> > rather like to either
> > 
> >    a) Have these things in the "optional" tasks package
> > or
> >    b) Have some sort of "contrib" package where people
> >       can submit the tasks they have developed, so that
> >       others don't have to go and re-implement them.
> >       Much like the optional package is today, there could 
> >       a contrib area where people could go to look for
> >       these types of tasks, and see what others have already
> >       done.
> >  
> > 
> > It seems that the mentality of the project is that if
> > they don't think it's part of the basic ant functionality,
> > it's not going to be part of ant in any form.  There is no
> > reason that everyone should have to re-implement the same
> > tasks over and over again, when we could have some sort
> > of contrib process.  That's part of the whole spirit of
> > open source.
> > 
> > Is there a way to formally propose something like the second
> > thing i suggested?
> > 
> > 
> > 
> > 
> > On Fri, 2001-09-21 at 15:22, Brian Moriarty wrote:
> > > 
> > > I was also wishing for a "foreach", but decided it might not be a good
> > > idea and didn't ask for it because it is a programming construct.
> > > 
> > > The docs say ant is not a scripting language, and I like that it's not.
> > > It describes how to build something task by task, but it's my feeling
> > > that if any scripting like a "foreach" is needed, one should probably
> > > create a Task to do it.  If they start adding programming construct
> > > functionality to the ant core, then build files will start looking like
> > > a script, in which case why not use bash or tcsh or something. (and
> > > don't say cross platform, because it's as easy to make those cross
> > > platform anymore w/ cygwin, etc...).
> > > 
> > > It turned out in my case that writing my own Tasks was actually much
> > > more versatile and it kept the build.xml file clean and straight
> > > forward.  In general, I just extend the Task I would otherwise put in a
> > > foreach loop.  I add any specialized parameters, and call
> > > "super.execute()" method inside my subclass.  The advantage is that you
> > > can do anything you want with the parameters before calling execute()
> > > (in most cases, sometimes the core API keeps the super class attributes
> > > private and doesn't provide full access by other means, which is very
> > > limiting if you need that kind of access).  
> > > 
> > > I'm not totally sold on excluding "foreach" since I could just opt not
> > > to use it, but I do think it would set the stage for making build.xml
> > > files pretty ugly and script like, and deter people from writing their
> > > own specialized Tasks (which, imho, is one of the highlights of using
> > > ant).
> > > 
> > > 
> > > Brian Moriarty
> > > Polexis, Inc.
> > > 2815 Camino del Rio South
> > > San Diego, CA 92108
> > > www.polexis.com
> > > transforming data into knowledge
> > > 
> > > 
> > > 
> > > -----Original Message-----
> > > From: Alejandro Abdelnur [mailto:alejandro.abdelnur@sun.com]
> > > Sent: Friday, September 21, 2001 11:21 AM
> > > To: ant-dev@jakarta.apache.org
> > > Subject: Re: [PATCH] PropertyCopy and Foreach (NEW OPTIONAL TASKS)
> > > 
> > > 
> > > matthew,
> > > 
> > > i've been there already, submitted code doing that, it has been
> > > rejected.
> > > 
> > > it is not the first time, or second time, that these features are
> > > proposed. i
> > > think the the folks driving the evolution of ant should start
> > > considering
> > > these features again, they should listen a little more of what
> > > developers/user
> > > want/need.
> > > 
> > > fyi:
> > > 
> > > for embedded properties i modified the project helper, so you can use
> > > embedded
> > > variables "a.${b}.c" everywhere.
> > > 
> > > for looping i've implemented the "xantcall" target, extending the
> > > "antcall"
> > > target that supports iterations:
> > > 
> > >     <xantcall target="TARGET" iterate="LIST" iterator="VAR"/>
> > > 
> > > where VAR is the name of the variable taht will have the element of the
> > > current iteration.
> > > 
> > > you can find the code in the archives.
> > > 
> > > regards.
> > > 
> > > a
> > > 
> > > Matthew Inger wrote:
> > > 
> > > > attached are two useful tasks i have written, that would
> > > > be helpful to be put into the next release:
> > > >
> > > > PropertyCopy - double dereferencing (ie. ${a.${b}.c})
> > > >
> > > >   this essentially takes the "from" attribute and treats
> > > >   it as a property name.  It gets the value of that property
> > > >   and puts it in the property given by the "name" attribute.
> > > >   It's useful when you have property names that follow a certain
> > > >   pattern with some identifier in it (ie. org.TEST.server)
> > > >
> > > >   ex. <propertycopy name="NewVar" from="a.${b}.c" />
> > > >
> > > > Foreach - relatively self explanatory
> > > >
> > > >   ex. <foreach list="${items}" target="callMe"
> > > >                param="item" delimiter="," />
> > > >
> > > > I'm sure there are foreach tasks floating around, but
> > > > while i'm posting propertycopy i might as well post
> > > > the foreach task as well.
> > > >
> > > > --
> > > > Matt Inger (matt.inger@sedonacorp.com)
> > > > Sedona Corporation
> > > > 455 S. Gulph Road, Suite 300
> > > > King of Prussia, PA 19406
> > > > (484) 679-2213
> > > > "Self-respect - the secure feeling that no one,
> > > >  as yet, is suspicious." -H.L. Mencken
> > > >
> > > >
> > > ------------------------------------------------------------------------
> > > >                         Name: PropertyCopy.java
> > > >    PropertyCopy.java    Type: text/x-java
> > > >                     Encoding: 7bit
> > > >
> > > >                    Name: ForEach.java
> > > >    ForEach.java    Type: text/x-java
> > > >                Encoding: 7bit
> > > 
> > -- 
> > Matt Inger (matt.inger@sedonacorp.com)
> > Sedona Corporation
> > 455 S. Gulph Road, Suite 300
> > King of Prussia, PA 19406
> > (484) 679-2213
> > "Self-respect - the secure feeling that no one,
> >  as yet, is suspicious." -H.L. Mencken 
> > 
> > 
> > 
-- 
Matt Inger (matt.inger@sedonacorp.com)
Sedona Corporation
455 S. Gulph Road, Suite 300
King of Prussia, PA 19406
(484) 679-2213
"Self-respect - the secure feeling that no one,
 as yet, is suspicious." -H.L. Mencken 


Mime
View raw message