ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mohamed, Haneef" <>
Subject RE: Looking for a Build Philosophy
Date Thu, 17 Oct 2002 18:39:18 GMT
I had a couple of thoughts on this:
[Background: I am the build, test, test-tools developer for our project]

1. Having worked somea as a developer has saved me a lot of work when the
build breaks. Then I can submit targeted bugs like: two diferrent versions
of log4j.jar are being used, circular dependency, etc.

2. I only rebuild my jars (and do an autocheckout/autocheckin) if the source
code has changed using the uptodate tag [what a life saver!]

3. Each project can be built at its level as well as the root level. For
build purposes I used the master build file which calls the subordinate
projects' build files [inheritall="false" --- another beautiful util]. The
developers use the appropriate build.xml files, and the requisite files to build their individual projects.

Haneef Mohamed
Group1 Software - Hotdata Austin Group

[Acknowledgements: Joe Magdaleno, Ed French]

-----Original Message-----
From: Malik, Yousuff
To: 'Ant Users List'
Sent: 10/17/02 2:18 PM
Subject: RE: Looking for a Build Philosophy

Here are some of the best practices that I have found works 

1)Nightly development and integration builds
2)You need to have different dev, int and QA branches. Clearcase is
3)Schedule the nightly builds on a cron job and if a compilation error
occurs send out an email to the developers
4)Create a junit repeort and mail it to the developers
4)No compilation errors should occur in integration builds
5)The build master should "NEVER" be a developer. If so then he/she
find ways to fix compilation errors

Let me know if you need more information


-----Original Message-----
From: David McTavish []
Sent: Thursday, October 17, 2002 1:05 PM
To: 'Ant Users List'
Subject: RE: Looking for a Build Philosophy

What I'd like to know is how often does your organization build? 
- nightly
What events lead up to your builds? 
- every night, and major releases
How involved are the individual developers? 
- limited in the build process, but empowered
How do you progress from a unit test build to a system test build?
- two distinct phases:
  - unit tests run nightly after build
  - system test runs in separate environment (test lab) that is an
end-to-end testing suite developed in tcl. we are in the process of
integrating this with our nightly build process.

as far as having to run after errant code being applied to the build
process, make sure you are using some form of cvs repository (we use
Rational ClearCase (no endorsement)). if developers are caught checking
code that does not compile, they should be punished as such (ie: bring
donuts/snacks/etc. for the rest of the team the following day). it
be the "build master" who manages the code base, but the developers.
(although the build master is usually a developer too).


-----Original Message-----
From: Unchis, Debra []
Sent: Thursday, October 17, 2002 1:55 PM
To: ''
Subject: Looking for a Build Philosophy

Here's a change of pace question for the group...

I am the Build Manager for my group.  By "Build Manager" I mean I wrote
build.xml for our code, I don't have a full fledged background in what
calling "build philosophy".

So I'm no expert here, I'm just trying to get an idea on how other
organizations do it. Not the technical on internal aspects of the build
the targets and tasks) but the PROCESS, the philosophy behind a build. I
know there is no right or wrong, but I don't have any examples to follow
that's what I'm looking to this large pool of fellow builders for:

I mean I'm sure this can be simplified to build when it's necessary or
changes are made, but I find on my project that we are building every
and I'm finding that I spend half of my day tracking down errors and
rebuilding. I kind of think that's a waste, but I don't have any facts
examples to back me up. Management says "build", so I build, but there
to be a better SYSTEM out there. Can you all help me out with some real
experiences and advice?

Thanks so much.

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:
NOTICE:  This E-mail may contain confidential information.  If you are not
the addressee or the intended recipient please do not read this E-mail and
please immediately delete this e-mail message and any attachments from your
workstation or network mail system. If you are the addressee or the intended
recipient and you save or print a copy of this E-mail, please place it in an
appropriate file, depending on whether confidential information is contained
in the message.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message