RE: Major problem with Sun External Jar : RE: [Tomcat 4.0.2-b2] Javabinaries uploaded

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

>> I'd like to clarify. I could have activation, javamail, jdbc-ext,
>> jndi, jta, which are Sun products, included in a Tomcat tarball
>> but couldn't have them included in a separate tarball ?
>>
>
>Yes.

And couldn't they be included in the application source tarball ?

It's unclear in the licences I read (jta/javamail/jts).
Notice I'm french and may be some terms of the english licence
are too subtil for me (and probably many others non-english readers)

>Because that's what the "Redistribution" paragraph of the 
>license that you
>had to click through says you can do and not do.  (See why it's a good
>idea to actually *read* these things?  :-)

You're joking. I allways get these sensible jars from tomcat 4.0 binary
and there was nothing to click there ;)

If you take a look at my previous RPM I included a TC 4.0.1 binary
tarball
(4Mb) just to get +/- 150 Kb of mandatory jars.

A general packaging rule (RPM & DEBIAN) is to never use or include in
build stage 
binaries which could and should be in a common repository.  

That's why we started to works on jpackage project on providing many
java tools
in RPM packages. They live in a common location /usr/share/java,
location also
used now by Debian people.

The goal was to help java developpers get easy and ready to use dev &
prod
environnement.

Sadly, only 100% OSS will be available that way and developpers will
have to
exact and put jar by hand in the common java dir and loose time when
they
want to duplicate their configurations. And don't speak about making
tarballs
since of the goal of RPM packaging is to garanty that there is no
conflict or
miss between different packages via dependencies/require rules.

>> The question is, should Apache host projects which depend
>> on non OSS APIs which are entirely under Sun control (Jon/Pier ?)
>>
>> We should feel much more confortable with projects like
>> puretls/cryptix and openjmx. Hope to see an OSS alternative
>> to javamail and jta....
>>
>
>I'm sure Tomcat would be happy to ship with such alternatives (as we
>already do for openjmx on the HEAD branch).

So what about pushing puretls/cryptix as the principal SSL
implementation
for both Tomcat 3.3 and 4.x ? 

Eric is now commiter and will certainly be more than happy to contribute
some 
works on TC 4.0 and so fix definitively the dependencies for these
majors jakarta
projects on hidden technology which is never safe in
cryptography/security.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Major problem with Sun External Jar : RE: [Tomcat 4.0.2-b2] Javabinaries uploaded

[jean-frederic clere <jf...@fujitsu-siemens.com>]

GOMEZ Henri wrote:
> 
> >> I'd like to clarify. I could have activation, javamail, jdbc-ext,
> >> jndi, jta, which are Sun products, included in a Tomcat tarball
> >> but couldn't have them included in a separate tarball ?
> >>
> >
> >Yes.
> 
> And couldn't they be included in the application source tarball ?
> 
> It's unclear in the licences I read (jta/javamail/jts).
> Notice I'm french and may be some terms of the english licence
> are too subtil for me (and probably many others non-english readers)
> 
> >Because that's what the "Redistribution" paragraph of the
> >license that you
> >had to click through says you can do and not do.  (See why it's a good
> >idea to actually *read* these things?  :-)
> 
> You're joking. I allways get these sensible jars from tomcat 4.0 binary
> and there was nothing to click there ;)
> 
> If you take a look at my previous RPM I included a TC 4.0.1 binary
> tarball
> (4Mb) just to get +/- 150 Kb of mandatory jars.
> 
> A general packaging rule (RPM & DEBIAN) is to never use or include in
> build stage
> binaries which could and should be in a common repository.
> 
> That's why we started to works on jpackage project on providing many
> java tools
> in RPM packages. They live in a common location /usr/share/java,
> location also
> used now by Debian people.
> 
> The goal was to help java developpers get easy and ready to use dev &
> prod
> environnement.
> 
> Sadly, only 100% OSS will be available that way and developpers will
> have to
> exact and put jar by hand in the common java dir and loose time when
> they
> want to duplicate their configurations. And don't speak about making
> tarballs
> since of the goal of RPM packaging is to garanty that there is no
> conflict or
> miss between different packages via dependencies/require rules.
> 
> >> The question is, should Apache host projects which depend
> >> on non OSS APIs which are entirely under Sun control (Jon/Pier ?)
> >>
> >> We should feel much more confortable with projects like
> >> puretls/cryptix and openjmx. Hope to see an OSS alternative
> >> to javamail and jta....
> >>
> >
> >I'm sure Tomcat would be happy to ship with such alternatives (as we
> >already do for openjmx on the HEAD branch).
> 
> So what about pushing puretls/cryptix as the principal SSL
> implementation
> for both Tomcat 3.3 and 4.x ?
> 
> Eric is now commiter and will certainly be more than happy to contribute
> some
> works on TC 4.0 and so fix definitively the dependencies for these
> majors jakarta
> projects on hidden technology which is never safe in
> cryptography/security.

For sure!!!

> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>