Mailing-List: contact ivy-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of gscokart@gmail.com designates
 66.249.92.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=from:to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:in-reply-to:x-mimeole;
        b=RyhIhrJZrjG2VBuv9SA1g7fiblm9SKb+oREV4Bz2167ekmqsye5d9g7fL4T+aC2VUIq/qpqnZePUcJKuXzZjl78N7vujOao4EETQEw4wlSo6t/P8if7XZhF1VEaZw/XZTglwtdm9DJemBsNShwy04rKdWnPrGigzIy2tPw79mOc=
From: "Gilles Scokart" <gscokart@gmail.com>
To: <ivy-user@incubator.apache.org>
Subject: RE: Status promotion
Date: Mon, 10 Dec 2007 13:46:33 +0100
Message-ID: <01b101c83b2a$b61565e0$0920a8c0@isabelteam.be>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: Acg7H3tgFH+TLGbcTnO55d37FFIkDQACac3Q
In-Reply-To: <20071210112548.GC47609@nmhq.net>


Some ideas:
One thing you could do is to use different repositories.  A promotion =
can maybe be base on an install task.
You can maybe even try to use a dual resolver to keep your jar in an =
unpromoted repository, and put the ivy.xml into
other repositories.

An other idea might be to have you continuous build deploying modules =
with organisation like 'myorg.continuous'. Then
when you want to promote it, you could release an ivy.xml without =
artefact in 'myorg.release' that only depends the
corresponding module in 'myorg.continuous'.


My 2c.

Gilles


> -----Original Message-----
> From: Niklas Matthies [mailto:ml_ivy-user@nmhq.net]
> Sent: lundi 10 d=E9cembre 2007 12:26
> To: ivy-user@incubator.apache.org
> Subject: Status promotion
>=20
> On the Best Practices page, "Dealing with integration versions" talks
> about promoting the status of builds, but remains pretty vague on how
> to go about this. Ideally, we'd like to simply relabel (or copy) the
> tested build of a module to a better status. Is there a recommended
> way how to do this?
>=20
> Side note: We'd like to avoid to actually re-build the artifacts of
> the module, since it introduces an unnecessary risk of the build not
> being 100% the same after all.
>=20
> -- Niklas Matthies