ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mitch Gitman" <>
Subject Re: buildnumber Ant task & automated updates of ivy.xml
Date Fri, 21 Nov 2008 00:22:48 GMT
Thanks again for the insights. Few brief comments inline below.

On Thu, Nov 20, 2008 at 3:10 AM, Jonathan Oulds <> wrote:

> Let me try and deal with each of your points one by one and explain how I
> am trying to solve each issue.
> - How to make ivy work differently when projects are build by the CI
> machine versus builds on development machines.

This makes me wonder now why you found the need for Ant to distinguish
between a CI build and a manual developer build. As far as Ivy is concerned,
wouldn't it simply be a matter of CI calling one set of targets, i.e.
publish, and developers calling another set of targets? Anyway, no big deal.

> I include an environment variable on the CI machine that can be read and
> used to parametrise the build.  Here is a snippet of ant code.
> <property environment="env"/>
> <property name="env.builder" value="${env.BUILDER}"/>
> <condition property="">
>  <equals arg1="${env.builder}" arg2="CI"/>
> </condition>
> <target name="publish-ci" if="">...</target>
> <target name="publish-dev" unless="">...</target>
> <target name="build" depends="publish-ci, publish-dev"/>
> - As to including the version number in the ivy file prior to publish.
> You are correct, in that the by using the build number task you are not
> setting a concrete revision for your module until you publish.  The other
> alternative is to hard code the revision into the ivy file pre-delivery.
>  However surely this implies that the developer (or whatever is building the
> module) knows the revision prior to publishing.
> As an example we have our project source under SVN.  Our CI inspects the
> project then builds and publishes if it detects any changes.  however if we
> hard coded the revision number into the ivy file then our CI machine would
> have to update the ivy file with the new version and do a commit.

This is precisely what we did on my previous team. The CI-invoked build
updated the revision build number in the ivy.xml file in source and then
checked in the updated file. This seems like a lot of trouble to go to, and
a potential source of version inconsistencies when its only purpose is as a
kind of documentation.

As I alluded in the lengthy post I sent earlier today, it's becoming
apparent to me that your project source proper is not the ideal place to be
keeping track of the current Ivy version of that project. It's like Ivy does
not want to be used in this way. Not only do you have to keep track of the
version manually through some scheme of your own, but again you have an open
invitation for your current version (as recorded in project source) to get
out of sync with the latest version that exists in the Ivy repository.

> That didn't sound like a good idea to us, so we headed down the route of
> not having the version numbers specified in the ivy file and only resolving
> the correct version number upon delivery.  Our CI machine will auto
> increment the build number, when a module changes significantly we do a
> special build of the module updating the major or minor version.
> long post, hope some of it is helpful
> any advice / comments are welcome

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