>> 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
