On Thu, 13 Sep 2001, Glenn Nielsen wrote:
> Date: Thu, 13 Sep 2001 20:33:02 -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,
>
> I have no problem with the binary distribution provided on the jakarta site
> containing all the jar files. And the default build and directions for building
> to do that also. All I added was the flexibility to *NOT* require that.
> This is not a major change before release, the build was just recently changed
> to distribute these jar files in $CATALINA_HOME/common/lib.
>
> If we can not agree, it can be put to a vote.
>
Sounds like a vote is in order, then.
My thinking for the current approach is as follows:
* If a JAR file is included in the official binary distribution of Tomcat,
it needs to be put there by the standard build script. Otherwise, you
end up with duplicate build scripts or targets (guaranteed to get out
of sync over time) or manual intervention when creating a distribution
(tedious, error-prone, and not repeatable).
* If a JAR file is part of the official binary distribution of Tomcat,
the build process should fail if it's not present. Otherwise, you run
into the current situation with Tomcat 3.2 -- if you build 3.2 without
the JSSE jar files, the build silently succeeds -- but the
SSLSocketFactory you need is not built, and you cannot use this distro
to run https connections even if you *do* install the JSSE jar files.
* If a JAR file is used in the core of Tomcat, or used in example
applications included with Tomcat, it must be part of the official
distribution, and therefore fall under the purview of the previous
two rules. Otherwise, you cannot have a "install and run right away"
user experience, and you make your users have to do the integration.
Thus, it all comes down to which JAR files do we consider essential? This
should not be too controversial in most cases. External libraries we
require include:
* JSSE - These are required to build (to avoid the 3.2 syndrome
described above, but are not included solely because of legal
requirements)
* JNDI - The "jndi.jar" file is required to compile or run on a 1.2
platform at all. Therefore, it is essential until we decide to
desupport 1.2, after which it could be removed.
* Servlet API - Pretty obvious that we need servlet.jar for a
servlet container.
* Regular Expressions Library - Required to implement the request filters
that are a standard feature.
* XML Parser - Required to function, so must be included. Replaceable
by any parser compatible with JAXP/1.1, however.
* Mail and Activation - Required for the JNDI resource factories and
the corresponding example application. IMHO, these things should not be
optional (see the 3.2 syndrome, above), so I removed the conditional
compile stuff (and updated the BUILDING.txt to document the revised
requirements).
A few conditional compilation cases remain in the current build scripts.
I plan to get rid of as many of them as possible before final release.
Do other developers have different opinions/votes on this issue?
> Regards,
>
> Glenn
>
Craig
> "Craig R. McClanahan" wrote:
> >
> > 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 | */ |
> > > ----------------------------------------------------------------------
> > >
>
> --
> ----------------------------------------------------------------------
> Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder |
> MOREnet System Programming | * if iz ina coment. |
> Missouri Research and Education Network | */ |
> ----------------------------------------------------------------------
>
