Comments below... > -----Original Message----- > From: Kanjo, Samer [mailto:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] For > additional > > commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
