RE: EARs and Jars continued -- WDSCI-L

> From: Phil Coulthard
>
> Joe, I might be missing something here, but if you don't want to include
> the jars in the ear, then
> its ok, it just means you are ready, willing and able to handle getting
> those jars into the production
> server, which it sounds like you are. In the ear, gets published. Out of
> ear, not published.

Yes, Phil, I've so far been unable to communicate my point.  I'll try again.
Let's say that I have a typical real world application development
environment with dozens of projects.  These have their own projects and are
distributed as EAR files.  However, they all share common JAR files - like
JTOpen, or the Xerces parser, or a PDF creation jar, or any of the hundreds
of JAR files out there that make Java development so wonderful.

In this environment, I probably don't want to have to have dozens of copies
of JAR files in individual project folders.  These should truly be shared,
external JAR files - probably on a central network drive where they can be
easily maintained and updated.  However, when I package a project for
delivery, I may want to include one or more of those JAR files (in fact, due
to rather simplistic deployment mechanism J2EE uses, I probably have to do
this).

With WDSC, I have to have copies of all those JAR files locally in every one
of my enterprise applications.  This is a dubious practice, if nothing else
from a maintenance standpoint - every time I get a new version of a JAR
file, I have to go through every project and update it.  Not the best
development environment.

Instead, I would like the option to have the EAR packager automatically
include selected external files AS IF they were located locally on my hard
drive.  This is not an unreasonable request - in fact, it would bring the
J2EE model a little closer to something usable for enterprise-level
development.

Now, if I were to design the installation process, I'd go a step further.
I'd allow the package developer to specify which JARs are required, and then
the tool would include them in the JAR.  At deployment time, the install
process would determine whether each of those JAR files are available on the
production server and if so, to use the existing JAR, and if not, would use
the file included in the EAR.  But that would require effort beyond simply
decompressing a ZIP file, and thus I fear unlikely to appear in the J2EE
specification which is, after all, merely a specification, not an
implementation standard.  Although that particular nuance seems to be
overlooked quite often these days.


> So, to do this, just set your project's build path to put directly to the
> jar files where they live on your
> disk, as did before I think. Then, to get Run On Server to work, you have
> to set the  ws.ext.dirs
> classpath, which can be set for each server via the Path tab in the server
> configuration editor.
> That'll handle compiling in the IDE, and running in the IDE. For
> running on
> the server you deploy
> to, you'll just have to set this ws.ext.dirs classpath yourself.

If you want this tool to be widely successful for enterprise application
devlopment, you may want to have a more automated deployment mechanism.  Any
manual step in the process introduces an error factor that might well be
unacceptable in a production environment.

"Remember to set set this switch here after installing" works fine for
software that changes only rarely and where you can afford someone whose job
it is to keep track of arcane configuration files.  Things like mail servers
come to mind here.  But in a mission critical application environment where
software changes are applied on a daily basis under extreme time pressures,
making sure your programmers tweak the right switch is often impossible.

Just an observation.

Joe