Return-Path: 
 <ivy-user-return-220-apmail-incubator-ivy-user-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-ivy-user-archive@locus.apache.org
Received: (qmail 3998 invoked from network); 4 Jan 2007 00:15:36 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 4 Jan 2007 00:15:36 -0000
Received: (qmail 859 invoked by uid 500); 4 Jan 2007 00:15:43 -0000
Delivered-To: apmail-incubator-ivy-user-archive@incubator.apache.org
Received: (qmail 797 invoked by uid 500); 4 Jan 2007 00:15:42 -0000
Mailing-List: contact ivy-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:ivy-user-help@incubator.apache.org>
List-Unsubscribe: <mailto:ivy-user-unsubscribe@incubator.apache.org>
List-Post: <mailto:ivy-user@incubator.apache.org>
List-Id: <ivy-user.incubator.apache.org>
Reply-To: ivy-user@incubator.apache.org
Delivered-To: mailing list ivy-user@incubator.apache.org
Received: (qmail 786 invoked by uid 99); 4 Jan 2007 00:15:42 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Jan 2007 16:15:42 -0800
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (herse.apache.org: domain of andreas.sahlbach@gmail.com
 designates 64.233.166.183 as permitted sender)
Received: from [64.233.166.183] (HELO py-out-1112.google.com) (64.233.166.183)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Jan 2007 16:15:33 -0800
Received: by py-out-1112.google.com with SMTP id p76so3561861pyb
        for <ivy-user@incubator.apache.org>;
 Wed, 03 Jan 2007 16:15:12 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=C2NCs36OJTF7yvRfY4bTFTr02ccNOmeIQdQ6fin/iQbc7HGU6EjuoHZIauIMW7DCxIiGPPt9aYfaO4uUzdtx3gpF+u3vwQpO56vIB4rBCnP2fvHwJiWaeQh5rNnid7S0x8DZEP9qr4VRDXiRE672cN6qchd9vyM37eg+gfCr5N4=
Received: by 10.35.81.1 with SMTP id i1mr40739686pyl.1167869712455;
        Wed, 03 Jan 2007 16:15:12 -0800 (PST)
Received: by 10.35.51.1 with HTTP; Wed, 3 Jan 2007 16:15:12 -0800 (PST)
Message-ID: <45ebb5590701031615s5f62fba5wfdca79e1f7478028@mail.gmail.com>
Date: Thu, 4 Jan 2007 01:15:12 +0100
From: "Andreas Sahlbach" <andreas.sahlbach@gmail.com>
Reply-To: andreas@sahlbach.com
To: ivy-user@incubator.apache.org
Subject: Re: Build promotion?
In-Reply-To: <635a05060701031051v42ec91c6s4b3466f7f577df63@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <e6c6cc500701030940y77736ba4j401bf9b7bc610c11@mail.gmail.com>
	 <635a05060701031051v42ec91c6s4b3466f7f577df63@mail.gmail.com>
X-Virus-Checked: Checked by ClamAV on apache.org

Hm, I have a different opinion here, but I think, this is a matter of
taste. I prefer to build a webapp once, then test it and then deploy
the very same artifact that I have successfully tested to the
production environment. Out webapps are independent from their
location, getting most configurations from the jndi environment, so
why taking a risk and do a new build just for promoting? Yeah sure, my
build should guarantee that the builds will produce the same
artifacts, but why taking a risk? This way the deployment is done just
by promoting and a little bit of file copy and server restart.

So I like build promoting and here is, what I am doing:

1) Our staging goes like this: development - integration - qs - productive

2) in my ivyconf, I have this
<?xml version="1.0" encoding="utf-8"?>
<ivyconf>
...
    <statuses default="development">
        <status name="productive" integration="false"/>
        <status name="release" integration="false"/>
        <status name="qs" integration="false"/>
        <status name="milestone" integration="false"/>
        <status name="integration" integration="false"/>
        <status name="development" integration="true"/>
    </statuses>
...
   <resolvers>
        <filesystem name="install">
            <artifact pattern="${user.home}/.ivy/install/[artifact].[ext]"/>
            <ivy pattern="${user.home}/.ivy/install/[artifact].[ext]"/>
        </filesystem>
   </resolvers>
</ivyconf>

3) in my common ant script, I have this:
    <macrodef name="change-status-macro">
        <attribute name="fromstatus"/>
        <attribute name="tostatus" />
        <sequential>
            <delete dir="${install-rep}"/>
            <mkdir dir="${install-rep}"/>
            <ivy:install from="umsrep"
                         to="install"
                         organisation="${ivy.organisation}"
                         module="${ivy.module}"
                         revision="latest.@{fromstatus}"
                         overwrite="true"/>
            <delete>
                <fileset dir="${install-rep}" includes="ivy.xml.*"/>
            </delete>
            <groovy>
                import org.dom4j.*
                import org.dom4j.io.*
                File ivyFile = new File(properties['install-rep'],"ivy.xml")
                Document ivyDoc = new SAXReader().read(ivyFile)
                def xpathSelector =
DocumentHelper.createXPath("/ivy-module/info[@status='@{fromstatus}']")
                xpathSelector.selectNodes(ivyDoc).each() {
                    ((Element)it).addAttribute("status","@{tostatus}")
                    OutputFormat outformat = OutputFormat.createPrettyPrint();
                    XMLWriter writer = new XMLWriter(ivyFile.newOutputStream());
                    writer.write((Document)ivyDoc);
                    writer.flush();
                }
            </groovy>
            <ivy:install from="install"
                         to="umsrep"
                         organisation="${ivy.organisation}"
                         module="${ivy.module}"
                         revision="latest.@{tostatus}"
                         overwrite="true"/>
        </sequential>
    </macrodef>

    <target name="promote-development" depends="configure,resolve"
            description="Pushes the latest.development version to
integration status">
        <change-status-macro fromstatus="development" tostatus="integration"/>
    </target>

    <target name="promote-integration" depends="configure,resolve"
            description="Pushes the latest.integration version to qs status">
        <change-status-macro fromstatus="integration" tostatus="qs"/>
    </target>

    <target name="promote-qs" depends="configure,resolve"
            description="Pushes the latest.qs version to productive status">
        <change-status-macro fromstatus="qs" tostatus="productive"/>
    </target>
4) install-rep is a simple directory
<property name="install-rep" value="${user.home}/.ivy/install"/>
which is also defined as a repository (see above)

I had to simplify the script a bit, but it should give you an idea how
to do it. The targets configure and resolve do the ivy tasks that you
expect.

Some support in ivy itself for it would be nice too, but it actually
works pretty well this way. Once again groovy saved my day... :)

Hope that helped a bit,

ciao,

Andreas

On 1/3/07, Xavier Hanin <xavier.hanin@gmail.com> wrote:
> On 1/3/07, John Williams <jrw@pobox.com> wrote:
> >
> > I read about to idea of build promotion at
> > <http://www.jaya.free.fr/ivy/doc/bestpractices.html>, but I can't find
> > any documentation on how to actually do it.
>
>
> As I say on this best practices page, Ivy does not support build promotion
> on its own, because build promotion is a complex thing that is not only
> related to module and dependency management. For instance you will certainly
> need to tag the sources that were used for your build if you promote it.
>
> Is the best way just to
> > manually edit an Ivy file in the repository to change the status
> > declaration?  That sounds easy enough, but the presence of the
> > checksum files in the repository makes me think that editing the ivy
> > files after the fact is frowned upon.
>
>
> I don't think that editing the ivy file is a good thing. I think that a
> revision should never change. So in my opinion a build promotion needs to be
> a new version. And in this case  you don't have to modify a file, you just
> publish a new version, and state somewhere (maybe in your ivy file in the
> description section) that it is simply another build which has been
> promoted.
>
> Ivy has no particular support for build promotion, the only thing is that
> Ivy helps in build reproducibility, and it's a good basis for build
> promotion. But setting up a build system supporting build promotion is not a
> trivial task IMO.
>
> Xavier
>
> Alternatively, does anyone have experiences to share with "snapshot"
> > revisions?  My understanding is that every snapshot revision should
> > eventually be replaced by a non-snapshot revision that is identical to
> > the last snapshot, but then what happens to the snapshot revision?
> > Does it just get deleted?  Or do you keep two identical revisions with
> > different numbers?
> >
> > --jw
> >
>
>



-- 
Andreas Sahlbach