tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GOMEZ Henri <hgo...@slib.fr>
Subject RE: [PATCH] TC 4.0 build patch - not a joke
Date Thu, 13 Sep 2001 09:44:19 GMT
Hi Craig and others in USA,

First, I make a point of presenting to you all 
my condolences for the tragedy which struck 
the USA, Tuesday last. 

>Henri,
>
>I'm not necessarily opposed to this patch -- just want to 
>understand it a
>little better.  Basically, it looks like you are trying to do the
>following (my comments interspersed in indented paragraphs):
>
>* Declare "foo.lib" properties for all of the actual directories
>  in which the JAR files would be found.
>
>    I presume this is the thing your RPM build
>    script would be customizing, right?

Exact. For your information, the consensus on Linux Boxes,
Debian, Redhat, Mandrake, Suse, is to put ALL the jar jars
in /usr/share/java/

So all the TC 4.0 required stuff is installed in 
/usr/share/java/

And when we package a RPM we indicate that to build TC 4.0
for example, we need JSSE, JAVAMAIL... which all lives in
/usr/share/java/

>* Declare the "foo.jar" properties based on "foo.lib" settings
>
>    A logical consequence of the previous goal, but ...
>
>* Remove declarations and uses of any "foo.home"
>  properties that currently exist.
>
>    This one I have some heartburn with, because
>    it breaks backwards compatibility with environments
>    that depend on this approach (which is also used in
>    several other projects at Jakarta and elsewhere).
>
>* Add support for JSSE jar files using the standard approach
>
>    I haven't caught up on the email thread and/or patches
>    about this, but agree in principle that it should follow
>    the same conventions as for other JAR dependencies.
>
>Can we think of a way to accomplish what you would like for RPMs that
>does *not* create backwards incompatibilities?  How about a three-layer
>model like this (for a package with JARs in the "home" directory):
>
>    <property name="activation.home"    value="/usr/local/jaf-1.0.1"/>
>    <property name="activation.lib"     value="${activation.home}"/>
>    <property name="activation.jar"
>       value="${activation.lib}/activation.jar"/>

Ok for me that way.

>or like this for something with a nested "lib" directory:
>
>    <property name="jsse.home"          value="/usr/local/jsse-1.0.2"/>
>    <property name="jsse.lib"           value="${jsse.home}/lib"/>
>    <property name="jcert.jar"          value="${jsse.lib}/jcert.jar"/>
>That way, you could override at *any* of the three levels, without
>breaking old scripts that rely on the "foo.home" approach.
>
>What do you think?

Ok for me also like this, since I could override jsse.lib in command
line. We want to avoid having to patch all the build.xml.
I fully agree, but we'll need also another modification since
in catalina build you grab every .jar in for regexp and when
regexp is in /usr/share/java/, you copy just ALL system jars !!!
In my case not less that 80 jar (regexp, oro, jtopen, .....)

A another addon, be naming the name :

 <property name="regexp.name"          value="jakarta-regexp-1.2.jar"/>


=>

--- catalina/build.xml.orig	Tue Sep 11 00:05:17 2001
+++ catalina/build.xml	Tue Sep 11 13:20:36 2001
@@ -25,14 +25,19 @@
   <property name="activation.jar"
value="${activation.home}/activation.jar"/>
   <property name="jaxp.jar"        value="${catalina.jaxp.home}/jaxp.jar"/>
   <property name="parser.jar"
value="${catalina.jaxp.home}/${catalina.jaxp.parser.jar}"/>
-  <property name="jcert.jar"       value="${jsse.home}/lib/jcert.jar"/>
-  <property name="jndi.jar"        value="${jndi.home}/lib/jndi.jar"/>
-  <property name="jnet.jar"        value="${jsse.home}/lib/jnet.jar"/>
-  <property name="jsse.jar"        value="${jsse.home}/lib/jsse.jar"/>
-  <property name="jmxri.jar"       value="${jmx.home}/lib/jmxri.jar"/>
+  <property name="jsse.lib"        value="${jsse.home}/lib/"/>
+  <property name="jmx.lib"         value="${jmx.home}/lib/"/>
+  <property name="jndi.lib"        value="${jndi.home}/lib/"/>
+  <property name="servletapi.lib"  value="${servletapi.home}/lib/"/>
+  <property name="jcert.jar"       value="${jsse.lib}/jcert.jar"/>
+  <property name="jndi.jar"        value="${jndi.lib}/jndi.jar"/>
+  <property name="jnet.jar"        value="${jsse.lib}/jnet.jar"/>
+  <property name="jsse.jar"        value="${jsse.lib}/jsse.jar"/>
+  <property name="jmxri.jar"       value="${jmx.lib}/jmxri.jar"/>
   <property name="mail.jar"        value="${mail.home}/mail.jar"/>
-  <property name="regexp.jar"
value="${regexp.home}/jakarta-regexp-1.2.jar"/>
-  <property name="servlet.jar"
value="${servletapi.home}/lib/servlet.jar"/>
+  <property name="regexp.name"     value="jakarta-regexp-1.2.jar"/>
+  <property name="regexp.jar"      value="${regexp.home}/${regexp.name}"/>
+  <property name="servlet.jar"     value="${servletapi.lib}/servlet.jar"/>
 
   <!-- Construct unit tests classpath -->
   <path id="test.classpath">
@@ -107,7 +112,7 @@
      tofile="${catalina.build}/server/lib/${catalina.jaxp.parser.jar}" />
     <!--   Catalina needs the regular expression library -->
     <copy todir="${catalina.build}/server/lib">
-      <fileset dir="${regexp.home}" includes="*.jar"/>
+      <fileset dir="${regexp.home}" includes="${regexp.name}"/>
     </copy>
     <!--   Catalina needs the JSSE packages -->
 <!--

<=====



Mime
View raw message