ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kanjo, Samer" <SKa...@tribune.com>
Subject RE: Targeting Multiple Environments
Date Thu, 01 Jun 2006 18:53:43 GMT
"This should not be the case. Please post the specific issues you are
facing with this."

The specific problem here is when I have placeholders in my properties files
and when I need to "import" environment properties based on the target
environment. For example, if I had a database.properties file that defined
the following:

db.driver=@DB_DRIVER@
db.url=@DB_URL@
db.user=@DB_USER@
db.password=@DB_PASSWORD@

The database.properties file is intended to be included in my archive files
like any standard properties file. Now assume I had the following
environment specific property files that defined the values for database
properties based on the target environment:

dev.xml
<property name="db.driver" value="oracle.jdbc.driver.OracleDriver"/>
<property name="db.url" value="jdbc:oracle:thin:@devhost:1521:DEV1"/>
<property name="db.user" value="foo1"/>
<property name="db.password" value="bar1"/>

test.xml
<property name="db.driver" value="oracle.jdbc.driver.OracleDriver"/>
<property name="db.url" value="jdbc:oracle:thin:@tsthost:1521:TST1"/>
<property name="db.user" value="foo2"/>
<property name="db.password" value="bar2"/>

etc.

What I do with Ant in this example is enter the target environment at the
command line as an environment variable. The value of the target environment
variable determines which environment specific properties I load (i.e.
dev.xml, test.xml, train.xml, prod.xml). The values from that target
environment property file are used to fill in the values in the
database.properties file and finally the application uses the
database.properties file to connect to the database.

If I ran 
ant -Dtarget_env=dev dist

then the database.properties included in my archive would look like:

db.driver=oracle.jdbc.driver.OracleDriver
db.url=jdbc:oracle:thin:@devhost:1521:DEV1
db.user=foo1
db.password=bar1

The Eclipse problem with this configuration is that I have no idea how to
tell Eclipse to do this for me when running a test or debugging or just
prototyping some idea within Eclipse.

In the past I have used batch files to copy the appropriate property files
into the source path before creating an archive or running within Eclipse.
So instead of having environment files like dev.xml, test.xml, etc. I would
have a folder structure like:

/etc
	/dev
	/test
	/train
	/prod

and in each folder would be the enviroment specific property files with the
correct name. To continue my example from above I would have a
database.properties file in each folder and the batch file would simply copy
the appropriate property files to my source path and which would then be
included in the Eclipse build.

As far as your suggestion to use a single project at the application root, I
agree that could solve problems but I would rather have the each logical
component as separate projects. To me it makes things very clear and from
what I have learned of Ant I think it would be easier to abstract my Ant
scripts into reusable modules (like JAM) if I separated my projects in this
way. But if I am doing that with Ant why am I using Eclipse?

I have used MyEclipse for a few years now and have grown quite attached to
its ability to build and deploy projects with a few mouse clicks and debug
an application on the server from within Eclipse. The problem is that my new
employer has IBM RAD that is Eclipse-based and designed for developing J2EE
apps using the classic heavy weight and defunct J2EE architecture and
deploying to WebSphere only. The tool is behind the times and one huge
resource hog. Bottom line, I hate it! IBM RAD has motivated me to start
using Ant to more easily solve my problems but of course I am having new
problems getting things to work well together.

And this is basically where I am now. I have something working but there has
to be a better way. So I thought I would find out what others are doing
here.

Samer Kanjo


-----Original Message-----
From: Anderson, Rob (Global Trade) [mailto:Rob.Anderson@nike.com]
Sent: Thursday, June 01, 2006 11:28 AM
To: Ant Users List
Subject: RE: Targeting Multiple Environments


Comments below... 

> -----Original Message-----
> From: Kanjo, Samer [mailto:SKanjo@tribune.com] 
> 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) [mailto:Rob.Anderson@nike.com]
> 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 [mailto:SKanjo@tribune.com]
> > 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.dev", "myprops.xml.test", "myprops.xml.train", 
> > "myprops.xml.prod". 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-unsubscribe@ant.apache.org For 
> additional 
> > commands, e-mail: user-help@ant.apache.org
> > 
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org For 
> additional commands, e-mail: user-help@ant.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org For 
> additional commands, e-mail: user-help@ant.apache.org
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Mime
View raw message