RE: [4.0.2] [4.1] [PROPOSAL] Binaries packaging

[GOMEZ Henri]

>> For the ZIP/TGZ packaging:
>>
>> A) Full JDK 1.4: This includes everything, except the 
>libraries which are
>> already included in the JDK (including the JAXP XML parser).

I'd like to use Xerces 2.0, will it be in JDK 1.4 ?

>> B) Light JDK 1.4: This incluides a bare bones Tomcat 
>distribution which
>> would only run on JDK 1.4. Note: For Tomcat 4.0-HEAD (aka 
>4.1), this will
>> still includes the admin feature and the necessary JMX implementation
>> (OpenJMX, which has a very nice license).

What about jndi/javamail/jdbcext/jta/tyrex ? 

Did they are still mandatory to rebuild TC 4.0.2 ?

>> C) Light JDK 1.3: Essentially the same as B, with the 
>addition of an XML
>> parser.

Crimson ?

>> D) Full distrbution (same as right now).

Everything is included in binary like today ?

>I think B is ok, but we must at least try to deal with the
>common case where the user downloads/installs various
>binary packages.

A damn't problem. We (jpackage project) still wait a 
reply from Sun officials to know if we could provide
RPMs like jta, jndi, javamail, jdbc2ext in our distrib.
Nota that the debian-java guys have the same problems
which prevent them to package (yet) Tomcat 4.x

>Say /usr/lib/java, with each package beeing unziped there,
>similar with what is required for tomcat build. The same
>build.properties file could be 'reused' at runtime,
>by reading it from the shell script or starter and adding
>the classes to the loader.

The current consensus is to install the java API in
/usr/share/java/ dir, and it's used on debian and
jPackage project. Seems to meet the FHS requirement.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [4.0.2] [4.1] [PROPOSAL] Binaries packaging

[Remy Maucherat]

> On Thu, 7 Feb 2002, Remy Maucherat wrote:
> 
> I think B is ok, but we must at least try to deal with the
> common case where the user downloads/installs various
> binary packages.
> 
> Say /usr/lib/java, with each package beeing unziped there,
> similar with what is required for tomcat build. The same
> build.properties file could be 'reused' at runtime,
> by reading it from the shell script or starter and adding
> the classes to the loader.
> 
> Just an idea - I'm not volunteering :-)

Yep, that would be great.
I'm a bit short on time to be able to do work in that area, unfortunately.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [4.0.2] [4.1] [PROPOSAL] Binaries packaging

[costinm]

On Thu, 7 Feb 2002, Remy Maucherat wrote:

> For the ZIP/TGZ packaging:
>
> A) Full JDK 1.4: This includes everything, except the libraries which are
> already included in the JDK (including the JAXP XML parser).
> B) Light JDK 1.4: This incluides a bare bones Tomcat distribution which
> would only run on JDK 1.4. Note: For Tomcat 4.0-HEAD (aka 4.1), this will
> still includes the admin feature and the necessary JMX implementation
> (OpenJMX, which has a very nice license).
> C) Light JDK 1.3: Essentially the same as B, with the addition of an XML
> parser.
> D) Full distrbution (same as right now).


I think B is ok, but we must at least try to deal with the
common case where the user downloads/installs various
binary packages.

Say /usr/lib/java, with each package beeing unziped there,
similar with what is required for tomcat build. The same
build.properties file could be 'reused' at runtime,
by reading it from the shell script or starter and adding
the classes to the loader.

Just an idea - I'm not volunteering :-)

Costin
k


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [4.0.2] [4.1] [PROPOSAL] Binaries packaging

[Kevin Seguin]

> 
> 
> ZIP/TGZ packaging:
> [ ] Do A
> [X] Do B
> [ ] Do C
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: