ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ron Ohmer" <>
Subject RE: Targeting Multiple Environments
Date Thu, 01 Jun 2006 14:43:35 GMT
  We have a similar "problem".  We have a multi-platform C++ application we use Ant to build.
 We don't build it from Eclipse, but we do edit our build scripts in Eclipse.  What we did
was have a master build script on one of our build machines.  This controls everything, builds
the Windows specific components (That machine is a windows box) and then calls out remoteant
calls to the various other machine architectures required.
Ours is a little more complicated than what you need since we have to copy files back to the
original machine to create the package.
What I would do is something like:
Have a build script that you run from eclipse that does your build, then FTPs the files to
a staging directory on your Unix Test/QA/Prod/Whatever machines.  Then run a remote ant to
an antserver on those Unix machines to deploy from those staged packages.
It all sounds a little complex, but it is really quite simple.  We really like our solution,
and it only took about 2 or 3 hours to fully automate.


From: Kanjo, Samer []
Sent: Thu 6/1/2006 10:28 AM
To: 'Ant Users List'
Subject: RE: Targeting Multiple Environments

I am not happy with the solution because the current setup is not Eclipse
friendly. Our small team develops on Windows machines and we deploy to Unix
for testing, training, and production. I would like to have a master build
script that can be invoked on a Unix based build server. The master build
process would involve getting the source for an application from version
control, building it, and then deploying it to the servers. Each build would
require the application name, the target environment, the version control
tag, and the target servers

In order for this to work I (think I) need a single build script in the
application root directory. The application root is outside the scope of the
Eclipse projects that are contained within the application root. The generic
application directory structure looks like this:

        /build (volatile)
        /dist (volatile)
        /service (Eclipse project root)
                /etc (environment properties defined in here)
                /main (main source branch)
                /web (web artifacts)
                /test (test source)
        /webapp (Eclipse project root and dependent on service)
        /remote (Eclipse project root and dependent on service)
        properties.xml (standard build properties across environments)

I like the single build script in the application root for the Unix side of
the build. However for Eclipse, this setup is not satisfactory. Initially it
seems that Ant and Eclipse are not congruent when using Ant to select
property files based on target environment and when substituting
placeholders in property files (using @placeholder@). In this situation I
find it difficult to run the application in Eclipse without first running a
separate build to simply setup the propetty files and substititute
placeholder values and store the resulting files, which will not be stored
in version control, in the build path.

Right now I am trying to figure out how to better setup the build scripts to
allow running the application in Eclipse while allowing a simple build
process to kickoff on the Unix build server. This may involve having build
files within each eclipse project and have the root build script simply call
these scripts.

It seems to me that using Ant along with unit/integration testing would not
require the use of Eclipse for debugging. In fact I am starting to wonder
why I need Eclipse at all. I think its my mind set since I have been using
IDEs since '96 and only just started using Ant.

Samer Kanjo

-----Original Message-----
From: Anderson, Rob (Global Trade) []
Sent: Wednesday, May 31, 2006 11:18 AM
To: Ant Users List
Subject: RE: Targeting Multiple Environments

I use the same strategy, except I use plain old property files instead
of xml. I have also added a user-friendly error message or input task if
the TARGET_ENV prop is missing:

<fail unless="TARGET_ENV">You must specify TARGET_ENV on the command
line. For example...
ant -DTARGET_ENV=dev deploy</fail>


<target name="getTargetEnv" unless="TARGET_ENV">

Why are you not satisfied with this solution?

-Rob A

> -----Original Message-----
> From: Kanjo, Samer []
> Sent: Wednesday, May 31, 2006 6:26 AM
> To: Ant Users (E-mail)
> Subject: Targeting Multiple Environments
> I am curious as to how others are using Ant to target
> multiple environments such as development, test, training,
> and production. In my world each environment typically has
> its own set of databases, servers, and application servers.
> What I have done is externalize all properties into a set of
> property files that end with the target environment name (The
> target environment names are dev, test, train, and prod). So
> if I had a properties file named "myprops.xml" included in
> the build I would create one for each environment naming the
> files as such: "", "myprops.xml.test",
> "myprops.xml.train", "". The build script
> would check for an environment variable named TARGET_ENV and
> attempt to load the file "myprops.xml" suffixed with the
> value of TARGET_ENV. Once loaded all the properties
> associated with that target are available to the build script.
> In order for this to work I must specify a value for
> TARGET_ENV on the command line. To simplify the command line
> I created a batch/shell script that accepts the target
> environment and a set of Ant targets and creates the command
> line used to invoke Ant.
> This works fine but I am just not happy with the solution. I
> have searched the web for solutions others have created for
> this problem but it doesn't seem to be anything anyone really
> talks about or I am looking in the wrong places.
> So what have you done?
> Samer Kanjo
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: For
> additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

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