ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bailey, Darragh" <dbai...@hp.com>
Subject Using artifactory/archiva/nexus with Ivy
Date Tue, 12 Oct 2010 16:56:39 GMT

Not a true ivy question, but more of a use case query. I'm curious as to how most people who
use Ivy and an artifact repository manager such as artifactory/archiva/nexus, integrate between
them with snapshot and release builds.

Thinks I'd like to know are:
Snapshots/Releases
* Do you use snapshot repositories and then use the repository manager to promote releases
from snapshot to release (requires pro version in most cases)
* Alternatively do you instead run a separate build with arguments to have ivy publish directly
to the release repository? (seems better as it uses ivy directly rather than depending on
the management software)

Versioning SNAPSHOT or unique
* Do you publish latest integration builds with ivy with unique versions (version numbers
or timestamps) even to the snapshot repositories
* Or do you use the string SNAPSHOT in the version and overwrite each release in the snapshot
repository until you make a release?

My impressions from looking at how to get Ivy working with artifactory is that the basic setup
is a breeze, but configuring everything so that I get the best out of it is going to require
a understanding the interactions a bit more.


I'm currently trying to get my head around retaining repeatability. My plan is that when builds
are done, the current source is copied to a tagging directory and to use ivy:delivery to generate
the fully resolved ivy file and then tag the contents with the build number (suggested previously
to me on this list). This means I should know exactly what revision each dependency was at
when the build was done.

The main concern is with using snapshot versions as opposed to unique versions. Resolved ivy
files will likely point to revisions such as 1.0.0-SNAPSHOT which could point to an artifact
built to any number of integration builds. This pretty much will make doing repeatable integration
builds require manual building of anything that's not a build of HEAD. This also makes storing
the resolved ivy files much less useful.

I may of course be reading a bit too much into the artifactory documentation of http://wiki.jfrog.org/confluence/display/RTF/Local+Repositories,
and unique versions in the snapshot repository may not be quite as bad as is made out.


Alternatively I was thinking that it might be better to just have different release/integration
builds and supply different arguments to ant to have ivy publish to the different repositories.
Set the release to snapshot/integration for automated builds that trigger on commits, and
set the release with an updated version number each week or as required for an interm release.
Seems a bit of a kludge though, as most of the weekly releases are nothing more than glorified
snapshots rather than actual releases.


--
Regards,
Darragh Bailey

Mime
View raw message