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 //service/main/src instead of main/src. We commit these to files at the app root so everyone gets their path setup automatically. 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. Andy "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 <132A2233DD61A44DA1F1BC326DC2C8CF03B985CC@erd-chi-exmb3.corp.trb>, "Kanjo, Samer" wrote: > 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. The application root is outside the scope of the > Eclipse projects that are contained within the application root. The generic > application directory structure looks like this: > > / > /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 select > 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 stored > 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 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. > > 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. > > 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: > > You must specify TARGET_ENV on the command > line. For example... > ant - DTARGET_ENV=dev deploy > > Or: > > > ... > > 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