ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Castrianni <>
Subject RE: Sharing Ivy settings file amongst developpers
Date Wed, 03 Mar 2010 22:25:36 GMT
I have all the ivy settings files (I use one per product release) checked into a SCM repo.
 This repo contains ant along with my master ant build file in which all others import, ivy
along with all the ivy settings files, and any other build related tools a developer would
use to build his code.  A developer just checks out this buildtools sandbox and his module's
sandbox and he is ready to go.  I have my master.xml build file coded to prompt the user for
what ivy settings file he wants to use by giving him a list of choices by product release
name.  He responds, and then my master.xml loads in that ivysettings file and the build starts.
 The list of choices of ivy settings files is constrained to only those that list the module
to be built in the modules section AND to only those that match the branch listed in the modules
section with the branch the sandbox was checked out from.  In other words, if the developer
checked out a sandbox for module_A from branch_A, then only the ivysettings files that contain
module_A with branch_A specified will show up in the list.  If they hardcode an ivysettings
file (possible by setting a RELEASE_NAME env variable in which my master.xml looks for) and
that ivysettings file doesn't list that module OR specifies a branch for that module that
doesn't match the sandbox, then the developer gets a warning.  This usually means the developer
checked out the wrong branch sandbox to be used for the release he specified in which case
he should get a warning because he is making a mistake.

I have about 200 hundred developers across a large enterprise and this works beautifully.

Shawn Castrianni

-----Original Message-----
From: normand gagnon [] 
Sent: Wednesday, March 03, 2010 4:15 PM
Subject: Sharing Ivy settings file amongst developpers


I'm looking for a way to manage ivy settings file.  My two main goals are
"build reproducibility" and provide a standard way within the enterprise to
resolve dependencies.  I want to have your thoughts on this,  do you use a
single ivy settings file for all your enterprise modules? Or are every
projects having their own ivy settings? Ar you committing settings file in a
SCM (and therefore, when building past versions of a given project, you are
using the ivy setting file that was in use at that time)?

Or maybe, you are giving a "template" of an ivy settings file to each
developer and you let them manage it as they want in their IDE, but when it
is time to publish a new module, they are forced to use a central build
system (or publishing is in fact managed by a continuous integration server
like Hudson)?

My idea is to let developer manages their own ivysettings file, which could
include another "enterprise-scope" ivysettings file, for the whole
development process.  To publish new "public" release, then I would use a
central build system which would use an "official" ivysettings file that
would be used for all modules under the same branch.  This to insure that
the dependencies are always resolved the same way when released publicly, so
you won't find in the public repository modules that were published
differently by different developers who were using different ivysettings


This e-mail, including any attached files, may contain confidential and privileged information
for the sole use of the intended recipient.  Any review, use, distribution, or disclosure
by others is strictly prohibited.  If you are not the intended recipient (or authorized to
receive information for the intended recipient), please contact the sender by reply e-mail
and delete all copies of this message.

View raw message