On Wed, 19 Sep 2001, Remy Maucherat wrote:
> Date: Wed, 19 Sep 2001 22:20:08 -0700
> From: Remy Maucherat <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Updated build scripts for Tomcat 4 HEAD
>
> Hi,
>
> The overhaul of the build system should be almost complete. I restricted the
> change to the HEAD branch. I don't see any particular need to roll this back
> into the 4.0.x branch.
>
On the other hand, it's useful to have consistency. I'd like to see this
committed on the 4.0.x branch as well, since it meets my fundamental
requirement for being able to build a full release.
Nice job, Remy!
(One little nit -- could you please document the "full.dist" property in
the BUILDING.txt file?)
> There are two main build options, toggled by the "full.dist" property.
>
> - If the value of the property is "on", then Tomcat will be built as the
> current 4.0 branch is. This target will generate a complete distribution
> with all the modules, and useable on JDK 1.2.
>
> - If the property is not defined or has a value which is not "on", then the
> modules will be built conditionally, and JARs will be copied according to
> which ones are available. This option is best when used in conjunction with
> a recent JDK, because the requirements to build Tomcat will become very low.
> The recommended platform is JDK 1.3, where only servlet.jar and regexp.jar
> (version 1.2) are needed.
> We could consider committing those two binaries in the CVS repository to
> make it a breeze to build Tomcat (except for the problems with the Ant
> <style> task of course), but I assume Craig is still against that practice.
> The generated build will run on your computer, but is not guranteed to run
> on JDK 1.2, among other things. Also, some optional modules may be left out
> during the build, like SSL or JMX support.
>
I believe the ClassLoaderFactory changes I recently checked in should deal
with the issue of stuff that's already been integrated into the JDK. It
checks for the existence of such packages (jndi, ldap, jsse, javax.sql,
...) being already present in the class loader, and refuses to add that
particular JAR file to the class loader repositories if they are not
needed. The check is now independent of the filename you actually use for
the JARs (our previous hack was checking specifically for "jndi.jar" and
"ldap.jar").
> Hopefully this new build script will be easy enough for the casual developer
> to use.
> (Since I think this meets the needs of both sides, I hope I won't get vetoed
> ;-))
>
No veto from me ... +1 instead :-)
> Remy
>
>
Craig
