ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Matthies <>
Subject Re: buildnumber Ant task & automated updates of ivy.xml
Date Thu, 20 Nov 2008 14:56:52 GMT
On Thu 2008-11-20 at 14:00h, Jonathan Oulds wrote on ivy-user:
> At present we tag our sources.
> But we are at an early stage of moving over to Ivy so I'd be interested 
> to hear the experiences of others.  Have others found this approach a 
> particularly bad / good idea, do others do anything different if so why?

What we (plan to) do is the following: First we tag the sources with a
version number (currently manually using an Ant task, but I guess this
could be done by a CI system as well). We have an Ant task, taking a
version number as input (usually from a properties file), which then
retrieves the sources tagged with that version number from the VCS,
invokes the build script that is part of the sources and publishes the
result of the build under that version number. As this build process
is (intended to be) reproducible, the defining moment is tagging the
sources in the VCS. All the rest should just be a function of those
sources and the Ivy repository. In particular it shouldn't matter
whether it is invoked by a CI system or manually/stand-alone.

For local builds from local sources, the tagging and retrieving is
skipped, and a sufficiently unique version number is generated,
something like "{version number from properties file}-{user}-
{timestamp}". The rest of the build process is the same as for
non-local builds, except that the result is published to the local
repository rather than to the shared repository.

The properties file containing the version number is part of the
sources, but this version number is only used for local builds (with
some decoration, as described) and to retrieve the sources for a
non-local build. Meaning that for non-local builds, the version number
contained in the properties file that is part of the retrieved sources
is irrelevant, because the version number has (necessarily) already
been provided externally prior to the retrieving.

In other words, the tag may well be inconsistent with the version
number contained in the properties file that is tagged with that tag,
but non-local builds are not affected by this because effectively they
always use the tag as the version number. In reality though such
inconsistencies normally won't occur, as the Ant task we use for
tagging takes the version number to be used as the tag from the local
copy of that properties file, and tagging verifies that the local
files are unmodified, so this ensures that the tag is consistent with
the version number contained in the tagged properties file.

-- Niklas Matthies

View raw message