ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pawanraj Sadhwani" <>
Subject RE: deployments...
Date Sat, 22 May 2004 05:00:55 GMT

In our organization, we make wars for testing and prod versions. EJB's are
packaged in a different ear. At the developer level we allow an exploded
War... although ejb's still stay in a jar.

This way, only one <make-war> target changes from deployment to developer...

We have an integration project also, where 2 diff projects are being
combined.. Due to xdoclet quirks (or so i think :-)).. we need the source
files of the core project also. We also need to take care of the fact that
the developer might be working with a version of core to finish his job.

What we've done therefore is .. at developer level, we use local copy of the
core project source files (on dev machine).. this source is taken from the
VSS in case of prod build.

I feel that separate dev and prod builds are a good idea. Now with the
import task in 1.6.1, maintaining two builds should not be a problem... It
would be easy to refactor the common bits into a build file and import that
both places.


-----Original Message-----
From: Artemis Ozten []
Sent: Saturday, May 22, 2004 3:05 AM
To: Ant Users List;
Subject: RE: deployments...

In our organization, we have one build file that handles 3 different types
of deployments based on one command line argument:

1. Development
2. QA
3. Production

And one fundamental decision:

"While build scripts will be tuned towards developer's productivity, there
shall not be any partial deployments for Production or QA. (Partial
deployments are prone to errors and fail in the long run especially in large

In other words, developer scripts are simple enough to use "update" option
for compilation or archiving and "copy" command to update only modified
parts of the deployables. On the other hand, QA or Production deployments
are always dependent on .EAR (= xxx-ejb.jar + .WAR) file.

The default for the command line argument is "development", to make sure
that typing is minimal for the developer and when one uses any other
destination such as "production", one has to type a long parameter value
correctly to avoid accidental deployments.

-----Original Message-----
From: Stephen Nesbitt []
Sent: Friday, May 21, 2004 2:10 PM
To: Ant Users List
Subject: Re: deployments...

On Friday 21 May 2004 08:07 am, EJ Ciramella wrote:
> How are people handling deployments?  Currently, we're using exploded
> directory structures (both in dev and in prod).  I'd like to see us get
> on the ear/war boat, but the biggest complaint is that it takes too long
> to see a change to a single jsp file (putting the jsp in the war and
> then putting the war in the ear takes about 2.5 min).

In my opinion this is a fundamental problem with the whole JAR/EAR/WAR
Packaging is nice but the expense associated with the packaging can put a
real dent in developer productivity. (Don't get me started on the whole
problem of replacing a single JSP located in a WAR embedded in an EAR!)

There are a couple of routes that I know of.
1) Weblogic 8.x supports a split-directory structure which essentially
you to overlay your development sandbox onto a Weblogic server.
it is Weblogic proprietary, requires use of BEA supplied ANT tasks which are
buggy and poorly implemented and will lock your build system into BEA's
development cycle (for some inane reason BEA distributes the build related
Ant tasks into their product related JARs )

2) You can - theoretically - setup a build target which will create an
exploded EAR/WAR structure for development purposes. Let's call it a
dev-deploy target. You also have a package target which spits out an EAR.
Developer's use the dev-deploy target, build engineering/release uses the
package target. ( I say theoretically because I'm not sure how to do

3) You can do a hybrid approach in which you continue to package EJBs, but
exploded WARs with the WARs implemented as symbolic links to your
area. This of course assumes you are using UNIX and your development
structure - at least the WAR part - mimics an exploded WAR.


Stephen Nesbitt
Senior Configuration Management Engineer
The Cobalt Group

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