tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jean-frederic clere <jfrederic.cl...@fujitsu-siemens.com>
Subject Re: Major problem with Sun External Jar : RE: [Tomcat 4.0.2-b2] Javabinaries uploaded
Date Fri, 25 Jan 2002 07:44:10 GMT
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:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message