RE: EARs and Jars continued

Joe,

The functionality you describe is provided by Maven, which is open
source 
and free. Most of the Jakarta projects are moving to Maven which uses 
a project description to define the relationships between various
project 
files. You can find out more at: http://maven.apache.org/

David Morris


>>> joepluta@xxxxxxxxxxxxxxxxx 5/29/2003 9:21:13 PM >>>
> 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