HI David:
I use a technique which is slightly different ....
I have a MasterBuild.xml that defines most of the tasks
and I have MyProjectBuild1.xml ... that would override properties that are
project specific (like directories .. includes.. excludes etc)and every
project specific build files would have a stub code that looks like below
...
<target name="defaultTarget" depends="init" description="Invokes
appropreate task in Master" >
<echo message="Entering defaultTarget PolluxBuild.xml"/>
<ant antfile="${masterBuildFilePath}" target="${execTarget}"
inheritAll="true" inheritrefs="true" >
</ant>
<echo message="Exiting defaultTarget PolluxBuild.xml"/>
</target>
User command for deploying MyProject1: ant -buildfile MyProjectBuild1.xml
-DexecTarget=deploy
User command for deploying all projects " ant -buildfile MasterBuild.xml
deploy
Do u see any advantanges/disadvantages in the above approach ?
Prem
-----Original Message-----
From: David McTavish [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, 26 November 2002 11:58 PM
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 26, 2002 12:31 PM
To: [EMAIL PROTECTED]
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:[EMAIL PROTECTED]]
> 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:[EMAIL PROTECTED]]
> Sent: Tuesday, November 26, 2002 10:48 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Naming build files
>
> On Tue, 26 Nov 2002, Dominique Devienne <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
>
--
----------------------------------------------------------------------------
--
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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
