On Thu, 13 Sep 2001, Glenn Nielsen wrote:
> Date: Thu, 13 Sep 2001 19:23:56 -0500
> From: Glenn Nielsen <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: cvs commit: jakarta-tomcat-4.0/catalina build.xml
>
> "Craig R. McClanahan" wrote:
> >
> > On 13 Sep 2001 [EMAIL PROTECTED] wrote:
> >
> > > Date: 13 Sep 2001 18:56:11 -0000
> > > From: [EMAIL PROTECTED]
> > > Reply-To: [EMAIL PROTECTED]
> > > To: [EMAIL PROTECTED]
> > > Subject: cvs commit: jakarta-tomcat-4.0/catalina build.xml
> > >
> > > glenn 01/09/13 11:56:11
> > >
> > > Modified: catalina build.xml
> > > Log:
> > > Update build, Copy the jndi, activation, and mail jar files only if they are
>present
> > >
> >
> > -1
> >
> > The jndi.jar file is required to run on JDK 1.2, and
> > activation.jar/mail.jar are now required by the standard resource factory
> > and corresponding example program.
> >
> > Craig
>
> Craig,
>
> JNDI comes as part of the 1.3 JVM, so there is no need for it to be included
> with Tomcat if the JVM is 1.3.
But it *is* required if you are building on 1.2. Until we decide
otherwiwe, Tomcat 4 must still be able to be compiled and run on a 1.2
platform.
Given that the Tomcat build script converts the source code into a binary
distribution that can be run on any 1.2 or later platform, the only
portable thing we can do is require jndi.jar to be available at build
time, so that it can be copied to the distribution (as well as used in the
compile, as just patched).
Note that the classloader initialization does recognize if these classes
are built in, and skips jndi.jar when creating the class loader repository
list on a 1.3 or later system.
> And the mail jar is the type of API that should
> really be installed in the $JAVA_HOME/jre/lib/ext directory.
I do *not* agree that this is a good idea.
TOMCAT-USER gets 10 or so messages a week from people who have old
versions of servlet.jar (or even j2ee.jar!) in their system extensions
directory. The symptoms that this causes are very strange to a newbie,
and are guaranteed to happen to happen the next time JavaMail is rev'd.
The current practice of including javamail.jar and activation.jar in the
place that Tomcat needs them (need vs. want is a separate issue, addressed
in your next comments), also makes Tomcat easier to install -- just unpack
it, set a couple of environment variables (optional), and go.
Finally, many environments do not allow developers or users to add
arbitrary JAR files to JAVA_HOME anyway (because it is a shared resource),
so we cannot assume that this is even possible.
> The change I made gave the build more flexibility. The jar files are
> still put in the Tomcat distributions if their properties are
> configured to a jar file that exists. Making the build flexible
> instead of one size fits all is a good thing IMHO. There is room to
> improve how that flexibility is implemented in the build. Perhaps
> testing the build environment to make sure that class's related to
> those API's are available, but only copying them if they defined
> property points to a jar file that exists.
>
I agree with you that the flexibility of the build process for Tomcat can
be improved -- especially in the light of Ant 1.4 (which suddenly became
the norm on Monday, with no discussion or vote :-). But it's too close to
final release to start ripping major things back out, now that we have
actually documented the Tomcat features available that support mail
sessions as a JNDI resource.
Remember that the build process we are talking about is for folks
developing Tomcat, not using it. In order to produce an "all in one"
binary distribution that includes these JAR files in the distribution (per
the reasoning above), they *must* be present anyway so that they can be
copied into the right places. And, if the JAR files have to be there
anyway, there is no point in making the compiles conditional.
> Regards,
>
> Glenn
>
Craig
> ----------------------------------------------------------------------
> Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder |
> MOREnet System Programming | * if iz ina coment. |
> Missouri Research and Education Network | */ |
> ----------------------------------------------------------------------
>
