ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anderson, Rob (Global Trade)" <Rob.Ander...@nike.com>
Subject RE: Targeting Multiple Environments
Date Thu, 01 Jun 2006 19:00:12 GMT
You can run the ant target that loads dev.xml and replaces the
placeholders in the database.properties from within Eclipse. If the
build file is not available from within Eclipse, because it is outside
of the Eclipse project root, you can create a new build file within the
Eclipse project root and use the <ant> task to call the targets in the
other build file. Use the input task the prompt for the environment.

-Rob A

> -----Original Message-----
> From: Kanjo, Samer [mailto:SKanjo@tribune.com] 
> Sent: Thursday, June 01, 2006 11:54 AM
> To: 'Ant Users List'
> Subject: RE: Targeting Multiple Environments
> 
> "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
> 
> 
> 


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


Mime
View raw message