ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anderson, Rob (Global Trade)" <>
Subject RE: Targeting Multiple Environments
Date Thu, 01 Jun 2006 16:27:33 GMT
Comments below... 

> -----Original Message-----
> From: Kanjo, Samer [] 
> Sent: Thursday, June 01, 2006 7:29 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. 

Using a single build file makes a lot of sense, in my opinion.

> The application 
> root is outside the scope of the Eclipse projects that are 
> contained within the application root. 

Consider moving the Eclipse project root up a few directories so that
the project root and the Eclipse project root are the same.

> The generic 
> 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.

You might also consider creating a build.xml within your Eclipse
projects and using the subant task in your master build.xml to call the
necessary targets within the Eclipse projects.

> 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@).

This should not be the case. Please post the specific issues you are
facing with this. 

> 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.

You should be able to do this within Eclipse. What version of Eclipse
are you using? Version later than 3.1M6 have a custom input handler that
allows you to use the input task for getting input during the build. Or
define default property values for developers, as Jan suggests.

> 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.

Yes. Or creating a single Eclipse project a few directories up.

> 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.

I would not give up on Eclipse, especially since you have 10 years of
experience with it. I think you can find an acceptable solution that is
Eclipse friendly.

-Rob A

> 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>
> 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: For 
> additional 
> > commands, e-mail:
> > 
> > 
> > 
> ---------------------------------------------------------------------
> 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:

View raw message