ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Goodnough" <>
Subject RE: Targeting Multiple Environments
Date Thu, 01 Jun 2006 14:50:00 GMT
I haven't see this dir structure before - with the Eclipse root being
different from the app root - it might have it's benefits but I think
this might be your problem.  If you were to make your Eclipse project
root the same as your App root, then the build.xml, build.bat, etc would
be visible and accessible from within Eclipse.  Using Eclipse's ant
integration, it would be easy to kick off a build with a 'deploy' target
from within Eclipse, exactly as you want to do from the Unix command
line.  Also, instead of the build.bat which had the hard-coded -D
parameter for the DEV, TEST, or whatever, you could create different Ant
launchers in Eclipse to hard-code them for each launcher.  Or, you could
call the build.bat from Eclipse too.

The only thing required to make this change is to change the Eclipse
project settings (written out to .project and .classpath) to find your
source at /<app_name>/service/main/src instead of main/src.  We commit
these to files at the app root so everyone gets their path setup

You should be able to check out the project (at its root) and build
from the command line or from Eclipse, calling the same targets in the
same way.


"Ooooh how I hate those damnable nerds and their obsession with
"uptime" and "scalability"! What do those words even mean anyway, it's
like they speak some kind of crazy moon language!"

>>> On Thu, Jun 1, 2006 at  9:28 am, in message
Samer" <> wrote: 
> I am not happy with the solution because the current setup is not
> 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
> script that can be invoked on a Unix based build server. The master
> process would involve getting the source for an application from
> control, building it, and then deploying it to the servers. Each
build would
> require the application name, the target environment, the version
> tag, and the target servers
> In order for this to work I (think I) need a single build script in
> application root directory. The application root is outside the scope
of the
> Eclipse projects that are contained within the application root. The
> application directory structure looks like this:
> /<app_name>
> 	/build (volatile)
> 	/dist (volatile)
> 	/docs
> 		/require
> 		/design
> 		/change
> 		/...
> 	/etc
> 	/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)
> 	/...
> 	build.xml
> 	build.bat
> 	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
> 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
> 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
> process to kickoff on the Unix build server. This may involve having
> 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
> why I need Eclipse at all. I think its my mind set since I have been
> 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
> 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>
> Or: 
> <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: user- For 
>> additional commands, e- mail: user-
> To unsubscribe, e- mail: user-
> For additional commands, e- mail: user-
> To unsubscribe, e- mail: user-
> For additional commands, e- mail: user-

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

View raw message