ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Vogel <pvo...@arsin.com>
Subject RE: Did somebody say Shut up and Write? :)
Date Thu, 28 Dec 2000 18:39:55 GMT
I think you have the mistaken impression that I was talking about
core ant, I wasn't.  I was referring to the ant customizations that
are done locally (i.e. task extensions, etc.) and that might be 
specific to a particular development project.

I agree, one way to approach the problem is to say that the CM group
(assuming there is one, and that is frequently not the case) maintains
the official toolset and any extension required to successfully build
the product must be officially supported by the CM group.  It does 
imply that CM must have a clean mechanism for propagating new versions of
ant to all development groups (otherwise you have a real mess).

I was thinking more in terms of what I believe would be a more efficient
use model, namely, extensions to ant that are required to build the product
are a part of the product tree, and ant builds them first and integrates
those extensions before beginning the actual product build.  By having the
extensions to ant as a part of the tree, we also ensure that the correct
version of ant is used for any build, since the ant changes are tagged along
with the rest of the product build.  This is what I do all the time with 
perl-based builds (or perl-wrapped builds) but the "update" issue doesn't
exist with perl because perl "compiles" extension modules on the fly, so as
long as the .pm is in the tree, perl is happy with it.

-Peter


> -----Original Message-----
> From: Scotte Zinn [mailto:szinn@patronix.com]
> Sent: Thursday, December 28, 2000 6:56 AM
> To: ant-dev@jakarta.apache.org
> Subject: RE: Did somebody say Shut up and Write? :)
> 
> 
> IMHO, this kind of feature seems to have nothing to do with building
> product, and shouldn't be part of ant itself.  The CM group should
> manage/define the 'official' toolset.  Others, (i.e., the 
> developers) may
> have their own local mods, which is fine, as long as they 
> either aren't
> required for the 'official' build, or are accepted by the CM 
> group.  Having
> a tool that modifies itself may hinder the mandate of the CM 
> group which is
> to build any past version of the product at any time exactly.
> 
> If a -selfupdate kind of feature is requested, maybe it 
> should be a task
> unto itself and a Build.xml (or whatever it is going to be 
> called) is part
> of the distribution that will provide the updated information.
> 
> This suggests another kind of extensibility: namely, the 
> ability to write a
> java class that is used by a custom command-line switch.
> 
> -- Scotte
> 
> > -----Original Message-----
> > From: James Duncan Davidson [mailto:duncan@x180.net]
> > Sent: Thursday, December 28, 2000 2:28 AM
> > To: ant-dev@jakarta.apache.org
> > Subject: Re: Did somebody say Shut up and Write? :)
> >
> >
> > On 12/27/00 11:11 PM, "Diane Holt" <holtdl@yahoo.com> wrote:
> >
> > > Actually, I would expect whatever "group" (even if it's
> > only an individual
> > > just working privately) "owns" Ant to -not- necessarily
> > have an up-to-date
> > > version of Ant. I would expect them to only update the version (or
> > > possibly only certain source-files) for specific reasons 
> and only at
> > > acceptable points in time. For example, I currently have a
> > mixture of
> > > 1.2alpha, some straight 1.2, some post-1.2, plus some
> > in-house mods. When
> > > 1.3 becomes available, I'll review what's changed, see if
> > there's anything
> > > that I want/need, and if there is, determine when would be
> > a good time to
> > > (either fully or partially) update.
> >
> > One way of handling this is to have an ant.conf file that is
> > part of the
> > distro. One of the properties of this file could be something like
> > 'udpateserver=http://jakarta.apache.org/ant/latestversion".
> > This location
> > could have a pointer to where the latest version was along
> > with version
> > number, etc.
> >
> > Then, in an installation like yours, you could change that 
> -- thereby
> > changing the action of `ant -selfupdate` to only grab your version.
> >
> > .duncan
> >
> > --
> > James Duncan Davidson
> > duncan@x180.net
> >
> >     !try; do()
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: ant-dev-help@jakarta.apache.org
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: ant-dev-help@jakarta.apache.org
> 

Mime
View raw message