ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: Little Ivy survey (was: development process)
Date Fri, 24 Aug 2007 13:36:01 GMT
Thanks a lot for this detailed report, Matthias, I think it can help many

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.


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.
> (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

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