Return-Path: 
 <tomcat-dev-return-27534-apmail-jakarta-tomcat-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org
Received: (qmail 97191 invoked by uid 500); 13 Sep 2001 16:21:21 -0000
Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:tomcat-dev-help@jakarta.apache.org>
list-unsubscribe: <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
list-post: <mailto:tomcat-dev@jakarta.apache.org>
Reply-To: tomcat-dev@jakarta.apache.org
Delivered-To: mailing list tomcat-dev@jakarta.apache.org
Received: (qmail 97175 invoked from network); 13 Sep 2001 16:21:21 -0000
Message-ID: <D84B43C5F94DD511877400609457497C01C9C6@css4.cs>
From: GOMEZ Henri <hgomez@slib.fr>
To: tomcat-dev@jakarta.apache.org
Subject: RE: [PATCH] TC 4.0 build patch - not a joke
Date: Thu, 13 Sep 2001 18:21:20 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

>How does the RPM packaging deal with the fact that different JAR files
>need to be loaded into different class loaders?  If they are all under
>"/usr/share/java", I don't see how that can work.

The /usr/share/java is in our case only usefull when building
the RPM (.spec file). It's a BuildRequires Tag.

>How does the RPM packaging deal with the fact that you might 
>want to use
>different XML parsers inside Catalina (i.e. from serverl/lib) or in
>webapps (from lib)?

A great pain here since we try to avoid installing too lib
allready present in system. In this case the RPM will 
mark the libs as Required (Require Tag) and will do symlink
at install time 

ln -s /usr/share/java/regexp.jar /var/tomcat4/server/lib/


to 
>> >* 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.
>>
>
>OK, I will go ahead and modify the build scripts to follow 
>this pattern.
>
>> >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, .....)
>>
>
>I did a separate patch to catalina.bat/catalina.sh that 
>specifically adds
>the JSSE classes.
>
>For Regexp, if Jon would remove the version number from the JAR file I
>wouldn't have to do that :-).  Of all the dependencies in 
>Tomcat, this is
>the *only* project that does versioning in the JAR file name.

We use it often on RPM packaging. I'm working on a Java Packaging
project where all jar have version inside :

-rw-r--r--    1 root     root       298756 Jun 11 12:10 ant-1.3.jar
lrwxrwxrwx    1 root     root           11 Jun 11 12:15 ant.jar ->
ant-1.3.jar
-rw-r--r--    1 root     root       331767 Jun 11 11:40 antlr-2.7.1.jar
lrwxrwxrwx    1 root     root           15 Jun 11 11:50 antlr.jar ->
antlr-2.7.1.jar
-rw-r--r--    1 root     root       379658 Jan 11  2001 ecs-1.4.1.jar
lrwxrwxrwx    1 root     root           13 Jan 18  2001 ecs.jar ->
ecs-1.4.1.jar
-rw-r--r--    1 root     root        66350 Jun  4 16:41
jakarta-oro-2.0.3.jar
lrwxrwxrwx    1 root     root           21 Jun  4 16:42 jakarta-oro.jar ->
jakarta-oro-2.0.3.jar
-rw-r--r--    1 root     root        25079 Jun  7 12:04
jakarta-regexp-1.2.jar
lrwxrwxrwx    1 root     root           22 Jan 18  2001 jakarta-regexp.jar
-> jakarta-regexp-1.2.jar
-rw-r--r--    1 root     root        92056 Jul 20 12:31 jdom-1.0b7.jar
lrwxrwxrwx    1 root     root           14 Jul 20 12:32 jdom.jar ->
jdom-1.0b7.jar
-rw-r--r--    1 root     root       491517 Aug 29 16:30 jswat-1.3.3.jar
lrwxrwxrwx    1 root     root           15 Aug 29 17:44 jswat.jar ->
jswat-1.3.3.jar
-rw-r--r--    1 root     root       108419 Jun  7 12:12 junit-3.7.jar
lrwxrwxrwx    1 root     root           13 Jun  7 11:43 junit.jar ->
junit-3.7.jar
-rw-r--r--    1 root     root       226870 Feb  6  2001 mm.mysql-2.0.4.jar
lrwxrwxrwx    1 root     root           18 Feb  6  2001 mm.mysql.jar ->
mm.mysql-2.0.4.jar
lrwxrwxrwx    1 root     root            9 May 28 13:21 xalan-2.1.0.jar ->
xalan.jar
-rw-r--r--    1 root     root       732330 May 28 18:23 xalan.jar
-rw-r--r--    1 root     root      1770662 Aug 23 16:02 xerces-1.4.3.jar
lrwxrwxrwx    1 root     root           16 Aug 23 16:03 xerces.jar ->
xerces-1.4.3.jar

>> A another addon, be naming the name :
>>
>>  <property name="regexp.name"          
>value="jakarta-regexp-1.2.jar"/>
>>
>
>I'll make sure I cover that one too.

Thanks