ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bhatia <Bha...@OFAC.CH>
Subject Re: Little Ivy survey (was: development process)
Date Fri, 24 Aug 2007 14:24:54 GMT

Basically, the questions basically are about "when to publish",  with
revision="branch-tag" or branch="branch-tag" etc...


bhatia wrote:
> Thanks to all of you. You have well responded on what a build server
> should do in the context of product development and I believe many are
> still in the dark over the big picture, the real truth :-)
> However, I still have questions related to working with Ivy in the Eclipse
> workspace e.g.
> 1) After making changes to a project (checkout out or updated from CVS),
> do I publish it to the repository with revision="CURRENT" or
> revision="latest.integration" and then reference this dependency from a
> dependant project from my workspace ? Is this the way to go ? So work on a
> dependency, publish it and then reference it from a dependant project ?
> Doesnt this make the development process longer in the Eclipse workspace ?
> 2) How can developers work on the HEAD using IvyDE, ant targets in the
> local workspace and with the Ivy repository I have set up ?
> e.g. Developer A gets a project from the HEAD, adds his changes, tests in
> local, if all is OK, he commits to HEAD in CVS. At this point, should he
> also publish this to the repository, if yes revision="HEAD" or
> revsion="latest.integration"....
> 3) Similar questions on the branch. I saw that there is a branch attribute
> documented on the website. So ,after making changes to a branch in
> Eclipse, a developer publishes the version/tag he commits to CVS like
> branch="branch-tag" or revision="branch-tag"...stuff like that...
> I hope you understand that the questions I have are concerned with "how to
> work in Eclipse with Ivy" rather than what the best practices of a build
> processes are on the build server which you have very well responded to
> and your response is a great starting point for me in the 2nd phase of
> this project when I try to integrate Ivy in our continuous build process.
> I hope my questions are making sense :-)
> thanks 
> Xavier Hanin wrote:
>> Thanks a lot for this detailed report, Matthias, I think it can help many
>> users.
>> To make it easier to find by users, I think it would be a nice idea to
>> convert it to a little article. Do you have a blog? It would be a very
>> interesting post, to which we could link from Ivy site.
>> Xavier
>> On 8/24/07, Matthias Kilian <> wrote:
>>> On Fri, Aug 24, 2007 at 03:03:49AM -0700, bhatia wrote:
>>> > How do we work in the Ivy world ? Checkout a project from CVS, compile
>>> it
>>> > thanks to IvyDE by retrieving dependencies, make changes to it in the
>>> local
>>> > workspace, then what ??? publish it with changes to the ivy repository
>>> with
>>> > rev="CURRENT"... ?? Same logic for the branch ? And when I am ready to
>>> > commit and tag on a branch, I publish the branch with
>>> rev="my-branch-tag" ?
>>> So, since Xavier wrote that a little survey would be welcome, and
>>> since this survey may answer your questions, here's what we do.
>>> YMMV.
>>> (Assuming development on the HEAD trunk for now, I'll describe when and
>>> how we deal with branches in a minute)
>>> - Checkout or Update the sources, make the appropriate changes, build,
>>>   test, commit.
>>> - If everything looks well, trigger a release (major, minor or
>>>   patchlevel) on a dedicated build machine -- we're running
>>>   cruisecontrol on it, so for HEAD revisions we can use cruisecontrol's
>>>   JMX interface to trigger a build with a special target. We've a couple
>>>   of standard targets in some special build.xml that's imported in the
>>>   build scripts of all projects: release-major, release-minor,
>>>   release-patch, release-fix (the latter for hot fixes on a branch, see
>>>   below). The same set exists for milestone builds, but we don't use
>>>   this yet.
>>> - The release-* targets will do the following steps:
>>>     * cvs update
>>>     * Pull in the current version (major, minor, patch, fix) from a file
>>>       "".
>>>     * Calculate appropriate new version numbers (increase the requested
>>>       level, and set all lower levels to 0).
>>>     * Write the new
>>>     * Run the normal build, including ivy resolution and retrieval. We
>>>       also include release information (status, revision, date, build
>>>       account) into the manifests of our applications.
>>>     * Make a backup copy of ivy.xml (to ivy.xml~). The important thing
>>>       here is that our project's ivy files typically don't have status,
>>>       rev etc. set, and also contain "latest.release" or "x.y.+"
>>>       revisions in their dependencies.
>>>     * Deliver the ivy file with appropriate status (currently always
>>>       "release", since we don't use milestone and integration builds
>>>       yet, as noted above).
>>>     * Publish the delivered ivy file and the artifacts.
>>>     * Commit the changed ivy.xml and with a proper
>>>       cvs log message (e.g. Release, and tag it
>>>       (with RELEASE_0_8_15_0 in this case).
>>>     * Move ivy.xml~ to ivy.xml, to get back the undelivered ivy file.
>>>     * Commit again, this time with "Unfreeze" as the cvs commit message.
>>> That's all for releases on the HEAD trunk. When we need a hotfix
>>> for an older revision (which happens quite often, since we're not
>>> supposed to deploy our latest and greatest features without lots
>>> of testing on dedicated QA machines), we proceed as following:
>>> - If it's the first hotfix for the revision currently running on our
>>>   production systems (e.g. RELEASE_0_8_15_0), check out / update to this
>>>   revision and create a new branch (BRANCH_0_8_15).
>>> - Update to the branch.
>>> - Modify, build, test, commit (on the branch). Developers must be take
>>>   special care about the ivy.xml they are using here -- it's the
>>>   delivered on, containing only fixed dependencies (no latest.* or
>>>   x.y.+). If that's not desired, the devlopers have to change
>>>   dependencies manually before committing their changes back to the
>>>   branch. Actually, we had a case two weeks ago where we *only*
>>>   changed dependencies for some hot fixes.
>>> - On the build machine, checkout that branch, then run ant as above with
>>>   the release-fix target. This does the same as the other release-*
>>>   targets.
>>> This gives absolutely reproducable results, which is especially
>>> important when you've rather long development cycles with the need
>>> of beeing able to reproduce builds from several months ago to apply
>>> bug fixes to them. One caveat when using branches for hotfixes like we
>>> do: if you bump some dependency to a newer revision, double-check wether
>>> all other dependencies are still at the correct revisions; you may have
>>> to use force="true" on some dependencies. For example:
>>> - A- depends on B- and on C-
>>> - B- depends on C-, too.
>>> - B- depends on C-
>>> - When you now update A's dependency on B to, you'll get
>>>   C- when using the default conflict manager. This may or
>>>   may not lead to problems.
>>> What's still on my TODO list are the mentioned integration and milestone
>>> builds and a better integration of ivy and cruisecontrol (or any other
>>> CI-like system).
>>> Milestone builds would be nice, since we could test them on the QA
>>> machines and then, if everything is ok, switch them from milestone
>>> to release status, using the same mechanism as above. Unfortunately,
>>> there're also some problems, since we deploy on WebSphere Application
>>> Server, but we don't put EJB and resource bindings into our builds,
>>> so this is kind of error-prone, and it's more safe to just copy the
>>> tested applications from QA to the production machines.
>>> I'm also planning to support pure integration builds on the CI
>>> machine, so tightly coupled projects will be tested without having
>>> to make and tag a new release all time.
>>> Oh, and one final remark: NEVER EVER ship code built only in your
>>> IDE. It's not reproducible. I've even seen projects that were not
>>> buildable on any except a single developer's machine. Even if IvyDE
>>> helps a lot, there may still be problems, like a forgotten commits,
>>> different locale settings, or just sloppy developers not caring at
>>> all about quality. So, ALWAYS use a dedicated build machine that
>>> ONLY builds, tags and publishes releases.
>>> Ciao,
>>>         Kili
>>> --
>>> I don't care what gutter Wim is lying in, make sure he's lying on
>>> his back, please!
>>>                 -- Marc Espie on
>> -- 
>> Xavier Hanin - Independent Java Consultant

View this message in context:
Sent from the ivy-user mailing list archive at

View raw message