Thanks for the quick response. I have a couple of follow-ups.

I've gotten the impression from reading other posts that <antcall> is to be
avoided, so I'm wondering about its use here.

The other question I have is: How would I satisfy the deploy-all use case
while reusing as much of the script as practical?

Thanks again,
Jamie

On 7/28/06, Andrew Goktepe <[EMAIL PROTECTED]> wrote:

Oops. s/<properties file/<property file/

On 7/28/06, Andrew Goktepe <[EMAIL PROTECTED]> wrote:
>
>  We use a separate properties file for each environment, and have common
> property names. Instead of integ.transfertype, stage.transfertype, etc,
I
> would just have 'transfertype' and it would have different values in the
> different files. Then the Ant script has targets based on the possible
> values of the property, and one generic parent target that calls them.
>
> Example:
> <properties file="${envname}.properties" />
> <target name="deploy">
>     <antcall target="deploy-${transfertype}" />
> </target>
> <target name="deploy-nfs"> ... </target>
> <target name="deploy-ssh"> ... </target>
>
> envname determines which environment-specific properties file needs to
be
> read.
>
> This is a more scalable solution. Adding a new environment is as simple
as
> creating a new properties file.
>
> This assumes the build has already occurred and you can make run the
> deployment Ant script separately for each environment.
>
> -Andrew
>
> On 7/28/06, Jamie Jackson <[EMAIL PROTECTED]> wrote:
> >
> > I'm having a problem trying to grok the "ant way" to do things (i.e.,
> > without conditionals). I just got started with Ant a couple days ago,
so
> >
> > take that into consideration.
> >
> > I'm trying to produce a well-factored script to handle code deployment
> > to
> > remote servers.
> >
> > Tasks:
> > *  deploy-integ
> > *  deploy-stage
> > *  deploy-prod
> > *  deploy-all (all of the above)
> >
> > Here's the problem: Depending on the set of servers, some are
available
> > via
> > SSH, others are available via NFS, and I'd like the script to be
> > generalizable enough to specify the transfer type in the properties
> > file,
> > along with the (potentially) varying paths among servers.
> >
> > Here's a stab at the properties file:
> > -----------------------------------
> > svn.url=http://myhost/myrepos/myproj
> >
> > integ.transfertype=nfs
> > stage.transfertype=ssh
> > prod.transfertype=ssh
> >
> > # a nfs basepath would look like //webdev/websites
> > # an ssh basepath would look like [EMAIL PROTECTED]:/path/to/docroot
> > integ.basepath=//devserver/docroot
> > [EMAIL PROTECTED] :/path/to/docroot
> > [EMAIL PROTECTED]:/path/to/docroot
> >
> > integ.proj.wwwroot=childwelfare
> > stage.proj.wwwroot=childwelfare
> > prod.proj.wwwroot=childwelfare
> > ---------------------------------
> >
> > Here are a couple of the salient tasks (see inline comments):
> >
> >    <target name="deploy-integ">
> >        <deploy basepath="integ.basepath" proj.wwwroot="
> > integ.proj.wwwroot"
> > transfertype="integ.transfertype" />
> >    </target>
> >
> >    <macrodef name="deploy">
> >        <attribute name="args" />
> >        <attribute name="basepath" />
> >        <attribute name="proj.wwwroot" />
> >        <attribute name="transfertype" />
> >        <!-- I'd like to do it the "right way, and avoid "if", but
don't
> > know how -->
> >        <!-- Not to mention that I can't even put the "if" in macrodef,
> > so
> > it doesn't work anyway -->
> >        <if>
> >            <equals arg1="@{transfertype}" arg2="ssh" />
> >            <then>
> >                <property name="@{args}" value="-e ssh -Cacvz @{
> > local.buildDir}/* @{basepath}/@{proj.wwwroot}" />
> >            </then>
> >            <else>
> >                <property name="@{args}" value="-av @{local.buildDir}/
> > @{basepath}/@{proj.wwwroot}/" />
> >            </else>
> >        </if>
> >        <echo message="rsync ${args}" />
> >        <exec executable="rsync">
> >            <arg line="${args}" />
> >        </exec>
> >    </macrodef>
> >
> > What's the right approach?
> >
> > Thanks,
> > Jamie
> >
> >
>


Reply via email to