ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <>
Subject Re: How do you promote and artifact?
Date Fri, 28 Dec 2012 23:45:50 GMT
Since no one else is fielding this question just yet, I'll go ahead. Ivy
has three predefined statuses, where the status attribute appears
/ivy-module/info in an ivy.xml file:

Even though Ivy in no way enforces this, the presumption is that the
integration status represents snapshot or, well, integration
versions—builds of a version that is still under development. The milestone
and release statuses represent one-off builds. Once you build version
1.0-beta1 with milestone status, you aren't going to overwrite it with
another 1.0-beta1 version, unless you do some kind of special in-house
demotion. Once you build version 1.0.0 with release status, you're not
going to produce another 1.0.0; the next release will be 1.0.1. The
milestone and release modules should be built off tags in your SCM system.

You're welcome to define your own statuses, but it's still advisable to
make a sharp distinction between integration versions and non-integration
versions. It's also advisable to bake the fact that we're talking an
integration version into the the literal version and not just rely on
status="integration". Sticking a suffix in the version, like 1.0-SNAPSHOT
or 1.0-timestamp or 1.0-buildnumber (not unlike what Maven does), is the
typical way to do this. There's a longer discussion about reproducible
builds which I'll spare you.

Now, suppose you have a release branch where you're preparing a release.
You'd create a Jenkins job for this branch, and you'd make it publish to
your enterprise artifact repository with status="integration". As you go
along in the development of this branch, you'd weed out all the
dependencies on integration (i.e. snapshot) versions of other modules. Then
when you finally tag a milestone or release in source control, you would do
a one-off build that publishes the Ivy module and its artifacts to the
enterprise repository with status="milestone" or status="release" and the
integration suffix stripped from the version string (revision="…" in the
ivy.xml). Whether you create a Jenkins job to do this and do it from a
shell shouldn't make a difference in terms of what gets published although
at least with Jenkins you can take advantage of the reporting. At this
point you should  lock the job so that it doesn't build again (don't recall
offhand how you do this). The job becomes effectively a historical document.

Trying to capture some best practices here, but certainly Ivy will give you
plenty of rope with which to hang yourself.

On Thu, Dec 27, 2012 at 6:38 PM, Aris Green <> wrote:

> I have a manually scripted build process using MSBuild for compiling
> and Ant + Ivy for publishing and sharing artifacts.  The goal is to
> move this in a Jenkins based CI system.  I was wondering, how are
> artifacts promoted from snapshots to let say, integration/release?  I
> have yet to find much on how this is actually accomplished.  Do you
> retrieve the artifacts from one branch into a local folder and publish
> them to another.  What are the "best practices".  I am hoping to get
> started in the right direction.
> Thanks
> agreen

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