[PATCH] TC 4.0 build patch - not a joke

[GOMEZ Henri <hg...@slib.fr>]

Hey hey boys, I've got a patch for you :))

I'm working on the RPM for Tomcat 4.0-RC1
and have noticed some jars, jndi for examples,
are awaited in JNDI_HOME/lib/jndi.jar.

In RPM packaging, and to follow FHS and
Debian, Mandrake, Redhat policies, all 
system jars are now installed in 
/usr/share/java/

Here is a patch which will help RPM
packagers have a successfull build 
process.

No change in that actual build, just add
some properties like jndi.lib which could
be overrided at ant build time.

Thanks to give me you feed-back and may be 
some gentleman will commit it ;)


-
Henri Gomez                 ___[_]____
EMAIL : hgomez@slib.fr        (. .)                     
PGP KEY : 697ECEDD    ...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

Re: [PATCH] TC 4.0 build patch - not a joke

["Craig R. McClanahan" <cr...@apache.org>]

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?

* 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"/>

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?

Craig


On Tue, 11 Sep 2001, GOMEZ Henri wrote:

> Date: Tue, 11 Sep 2001 14:24:47 +0200
> From: GOMEZ Henri <hg...@slib.fr>
> Reply-To: tomcat-dev@jakarta.apache.org
> To: tomcat-dev@jakarta.apache.org
> Subject: [PATCH] TC 4.0 build patch - not a joke
>
> Hey hey boys, I've got a patch for you :))
>
> I'm working on the RPM for Tomcat 4.0-RC1
> and have noticed some jars, jndi for examples,
> are awaited in JNDI_HOME/lib/jndi.jar.
>
> In RPM packaging, and to follow FHS and
> Debian, Mandrake, Redhat policies, all
> system jars are now installed in
> /usr/share/java/
>
> Here is a patch which will help RPM
> packagers have a successfull build
> process.
>
> No change in that actual build, just add
> some properties like jndi.lib which could
> be overrided at ant build time.
>
> Thanks to give me you feed-back and may be
> some gentleman will commit it ;)
>
>
> -
> Henri Gomez                 ___[_]____
> EMAIL : hgomez@slib.fr        (. .)
> PGP KEY : 697ECEDD    ...oOOo..(_)..oOOo...
> PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>
>