ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From SimonRichards...@hbosts.com
Subject RE: Naming build files
Date Wed, 27 Nov 2002 10:07:50 GMT
David

I'm encouraged by your views and experiences here, particularly because your reasons for moving
to the "distributed" approach are similar to ours.

However, I do have one question regarding the description of your approach .. 

Does the "build.<product>" (e.g. build.foo) exist as a target in your master build.xml
file, and within this target do you make your ant call as:

<target name="build.foo>
	<ant antfile="foo.xml"/><!-- assumes default target set in "foo.xml" -->
</target>

Or, is the request forwarded to the specified product by some other means?

Once again thanks for your response it is very encouraging.

Simon

> -----Original Message-----
> From: David McTavish [mailto:dmctavish@SANDVINE.com]
> Sent: 26 November 2002 18:28
> To: 'Ant Users List'
> Subject: RE: Naming build files
> 
> 
> Hi Simon,
> 
> We used to subscribe to the notion that all of our build 
> logic should be in
> one place, and quickly realized that this is not conducive to 
> managing the
> build environment. Our build script was quickly becoming 
> unwieldy (~3000
> lines), and prevented anyone from understanding the process 
> other than it
> working by "magic". We've gone to a distributed approach, 
> similar to what
> most people are familiar with when implementing a make-based 
> build strategy
> that seems to work better for us on several fronts.
> We still have the high level build.xml at the root of all our 
> project source
> trees that is responsible for delegating requests to the child build
> scripts. ie: the parent build file will contain a target 
> "build" that will
> call the build target on all child build scripts, but you 
> could narrow down
> the field by calling "ant build.<product>". this would only 
> forward the
> request to the specified product. This approach has greatly 
> reduced our
> build script complexity by dispersing the logic to the actual 
> folders where
> it is relevant. Overall, our file size grew slightly due to 
> having some
> redundancy on declaring properties that change based on the 
> project being
> invoked. However, we have made our build scripts MUCH more 
> understandable
> for the rest of the team to be able to follow the logic. We're also
> experiencing faster build times in some cases, as a lot of 
> our developers
> are working on one product at a given time. By separating the logic
> throughout, we are no longer required to load one build 
> script at ~3000
> lines, but rather 2 build scripts at a combined total of 800 
> lines. (Mind
> you, our scripts are heavily commented :). 
> Another benefit to this is you gain a finer granularity of 
> how your build
> scripts work and interact, provided that you fully plan your 
> build scripts
> beforehand. We've settled on set rules that all build files 
> MUST support a
> given set of targets in order to ensure that peer-products 
> are guaranteed
> that a particular target will be available. Some of this goes 
> back to just
> having a firm grasp of how to plan the build environment, 
> etc. (I would also
> recommend Eric's book Java Development in Ant, or something 
> like that. I
> picked up a few good ideas on how to streamline our build 
> environment from
> there).
> We also make extensive use of the XML ENTITY capability to allow for
> reusable targets to be imported into any build script. The 
> first issue we
> found when we separated the logic to separate build files was 
> that we had a
> lot of duplicated targets that required multiple updates with even the
> slightest change. With everything buried in cvs repository, 
> this became a
> combersome task. With the XML ENTITY ability, we haven't 
> experienced any
> problems, and we've been able to refactor most of our targets to be
> re-usable for optimal management. (I know only have to update 
> one file to
> manage our master build process, and all child projects are updated
> automatically :). Anywhere we could refactor our ant targets 
> to make them
> re-usable, we did. We put all of these into categorized .xml 
> files (ie:
> named bundle.xml, archive.xml, ...) and store them in a 
> common /scripts
> location. This makes it MUCH easier to manage re-usable 
> targets, as any
> build file that requires them can just import them without having to
> duplicate the effort. (A few examples of refactored targets 
> include our
> methodology to create windows installers using NSIS, our BSD 
> and RedHat RPM
> packaging targets, archiving all installers to our software 
> repository, and
> other re-usable targets like importing dependencies and declaring task
> definitions. In all honesty, I wish we had done this MUCH 
> earlier, as every
> aspect of managing our build environment has become VASTLY 
> easier. If you're
> thinking of doing this, (I'd highly recommend it), I'd only 
> suggest that you
> first sit down and outline what you want to accomplish first 
> (set of all
> targets, find what targets can be refactored, try to have everything
> configured via properties set at the top of a build script, 
> and outline all
> dependencies of your projects). I'd then plan a weekend to 
> implement all of
> the changes so as to provide as minimal impact as possible 
> (or even do this
> in tandem with all of your new files named build2.xml until 
> you are ready to
> switch...)
> 
> hope this helps,
> d.
> 
> 
> 
> -----Original Message-----
> From: SimonRichardson2@hbosts.com 
> [mailto:SimonRichardson2@hbosts.com] 
> Sent: Tuesday, November 26, 2002 12:31 PM
> To: ant-user@jakarta.apache.org
> Subject: RE: Naming build files
> 
> 
> I'm pleased to hear someone ask this question.
> 
> We're considering splitting our single build file into more 
> manageable units
> as the size and complexity of our project is now being 
> reflected in a large
> and increasingly more complex build file.
> 
> I like the prospect of using and embedding smaller build 
> files using XML
> ENTITY include:-
> http://marc.theaimsgroup.com/?l=ant-user&m=103768806331229&w=2
> 
> Or, using the <ant> task to make calls to 'other' build files:-
> http://marc.theaimsgroup.com/?l=ant-user&m=103790411410183&w=2
> 
> Which may be the better option - given the apparent bugs in 
> the XML ENTITY
> include method (FAQ's)?
> 
> In any event this modular approach does appear at first 
> glance to offer some
> benefits - making our build files smaller and more 
> manageable, also a degree
> of modularity.  But from what Dominique is saying there are 
> also some issues
> to resolve.  Has anyone tried this and if so are there any 
> benefits? - I'd
> like to know before I split our buildfile up.
> 
> Regards
> 
> Simon
> 
> > -----Original Message-----
> > From: Dominique Devienne [mailto:DDevienne@lgc.com]
> > Sent: 26 November 2002 16:57
> > To: 'Ant Users List'
> > Subject: RE: Naming build files
> > 
> > 
> > Indeed, so are the two build scripts I work on most usually.
> > But then if you
> > use entity includes in your XML (see the FAQ), you expose 
> > yourself to bugs
> > in some tasks that do not resolve entity the same way as Ant 
> > (AntDoc is one
> > example, but there are others), which when cannot find the 
> > entities and thus
> > fail. I now always put my Ant build script at the top-level, 
> > which is also
> > the Best Practice in my opinion.
> > 
> > So Stefan is right of course, but I do still recommend a
> > top-level build.xml
> > 
> > If you decide otherwise, don't complain to me later is 
> something's not 
> > working ;-) Cheers, --DD
> > 
> > -----Original Message-----
> > From: Stefan Bodewig [mailto:bodewig@apache.org]
> > Sent: Tuesday, November 26, 2002 10:48 AM
> > To: ant-user@jakarta.apache.org
> > Subject: Re: Naming build files
> > 
> > On Tue, 26 Nov 2002, Dominique Devienne <DDevienne@lgc.com> wrote:
> > 
> > > Putting the Ant build script at the top level is important, as 
> > > everything can then easily be defined relatively from this point 
> > > (see the location attribute of <property>).
> > 
> > Actually it will be relative to the basedir attribute of 
> your project 
> > element.
> > 
> > "For historic reasons" the build.xml of the biggest CVS 
> module in the 
> > company I work for is not at the top level but one level into the 
> > source tree - it has basedir=".." and so it is the same as 
> if it was 
> > at the top level.
> > 
> > Stefan
> > 
> > --
> > To unsubscribe, e-mail:   
> > <mailto:ant-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> > <mailto:ant-user-help@jakarta.apache.org>
> > 
> > 
> > 
> 
> -- 
> 
> --------------------------------------------------------------
> --------------
> --
> For more information on HBOS Treasury Services, please visit
> http://www.HBOSTS.com
> 
> Or for details of our online FX & Deposit services, please go to
> http://www.HBOSdeal.com
> 
> HBOS Treasury Services plc is part of the HBOS Group, which 
> also includes
> Halifax plc and Bank of Scotland. Registered Office: 33 Old 
> Broad Street,
> London EC2N 1HZ. Registered No. 2692890. Registered in 
> England. Regulated by
> the Financial Services Authority.
> 
> The information contained in this message is confidential and 
> is intended
> for the addressee only. If you have received this message in 
> error or there
> are any problems please notify the originator immediately. 
> The unauthorised
> use, disclosure, copying or alteration of this message is strictly
> forbidden. This mail and any attachments have been scanned 
> for viruses prior
> to leaving the HBOS Treasury Services plc network. HBOS 
> Treasury Services
> plc will not be liable for direct, special, indirect or consequential
> damages arising from alteration of the contents of this 
> message by a third
> party or as a result of any virus being passed on.
> 
> HBOS Treasury Services plc reserves the right to monitor and 
> record e-mail
> messages sent to and from this address for the purposes of 
> investigating or
> detecting any unauthorised use of its system and ensuring its 
> effective
> operation.
> 
> ==============================================================
> ==============
> ==
> 
> 
> --
> To unsubscribe, e-mail:   
<mailto:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>



-- 

------------------------------------------------------------------------------
For more information on HBOS Treasury Services, please visit http://www.HBOSTS.com

Or for details of our online FX & Deposit services, please go to http://www.HBOSdeal.com

HBOS Treasury Services plc is part of the HBOS Group, which also includes Halifax plc and
Bank of Scotland.
Registered Office: 33 Old Broad Street, London EC2N 1HZ. Registered No. 2692890. Registered
in England.
Regulated by the Financial Services Authority.

The information contained in this message is confidential and is intended for the addressee
only. If you have received this message in error or there are any problems please notify the
originator immediately. The unauthorised use, disclosure, copying or alteration of this message
is strictly forbidden. This mail and any attachments have been scanned for viruses prior to
leaving the HBOS Treasury Services plc network. HBOS Treasury Services plc will not be liable
for direct, special, indirect or consequential damages arising from alteration of the contents
of this message by a third party or as a result of any virus being passed on.

HBOS Treasury Services plc reserves the right to monitor and record e-mail messages sent to
and from this address for the purposes of investigating or detecting any unauthorised use
of its system and ensuring its effective operation.

==============================================================================


--
To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>


Mime
View raw message