RE: Tomcat 4.0 RPMs?

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

>> Jaxp and crimson are built from xml-commons and xml-crimson 
>( both are
>> Apache packages ). We do check in binaries - which is consistent with
>> apache licence, but anyone can built them from sources as well.

In the RPM case, we use dependencies to have them included from allready
installed RPM. But it's not the case in the CURRENT version of RPM where
we install crimson which is allready present in sources. 

Should I change to make xerces/crimson (jaxp requirement) required 
for both build and runtime (easy to do) ? I'm sure that some of my
friend in RPM packaging (hello Guillaume) will prefer this method.

>> The only problem is JSSE - it's clear the official RPM
>> can't include JSSE, nor the classes that depend on it ( since that
>> would mean the source RPM couldn't be distributed ). We can
>> distribute a separate RPM with JSSE-dependent classes. That's not
>> a major problem for linux - since Henri is already building mod_jk,
>
>Yep, JSSE is of course the most restrictive license of them 
>all, because of the goofy crypto laws. :(

Why couldn't we use the today JSSE as we use OpenSSL. I was told that
some legals aspect on RSA has been relaxed this year. 

>> so SSL will be supported via Apache, which is the best (and fastest)
>> solution anyway.
>
>Arrggg! Why does Standalone + SSL get no respect? It performs 
>quite well, in my 
>(extensive) experience. Also, I've never hit a single "real" 
>bug in it, in 
>either tree. Whether Apache is slightly better at SSL than 
>Tomcat standalone 
>isn't even a relevant comparison. If you're running TC behind 
>another web 
>server, then that web server needs to handle it. If you're 
>running standalone, 
>then Tomcat needs to handle it. Installing Apache to run in 
>front of TC *just* 
>to handle SSL is compeltely unnecessary.

You know that my friend, crypto is a hog cpu task and having it
handled by Java code will be more expensive that the native
(even asm) code in OpenSSL for example. But you're rigth when 
you tell we could use SSL in 100% java mode...

>Anyway, I'm trying very hard to build confidence in standalone 
>SSL, write 
>extensive docs for it, enhance it, patch it, and work out what 
>I see as its 
>weak points. Please don't impune it :)

Never ;)

>> Regarding the jars included in 4.0 - I do have few issues.
>> 
>> First, how in the world did we got to depend on mail.jar and
>> activation.jar and the other ?
>
>Dunno, I'll let someone else answer that one.
>
>> I believe including such features could be decided by vote,
>
>I don't have a problem with that. Technically, of course, it 
>would only be a 
>vote for what kind of RPM can be officially hosted on the 
>download site. Anyone 
>can package an RPM however they like, they just have to distribute it 
>themselves.

Yes even Sun could do such packaging :) 
More seriously the problem here is all the requirement and I'll
be to have a Tomcat 4.0 ligth, with less external dependencies.
Or may be we must mark that TC 4.0 is for J2EE 1.3 only !

>> and only
>> after the PMC and ASF clearly posts the policy that allow 
>such things.
>>
>> If ASF has any rule that allow us to take any package we want that is
>> redistributable and use it - that's great news.
>> 
>> If ASF has a list of 'aproved' licences that we can include - that's
>> even
>> better ( and I hope LGPL makes it to the list - at least it 
>has source
>> code available :-).
>> 
>> It would be nice to have this posted somewhere - so we all know the
>> rules.
>
>Agreed. But in the absence of an official policy, I'll go by 
>what that one PMC 
>dude said in response to Jon's concerns: By and large, and 
>code checked into 
>the tree by Sun employees falls under the Sun-Apache 
>agreement. I don't think 
>it's unreasonable to accept that at face value until there 
>*is* an official 
>policy posted.
>
>Without a specific policy disallowing it, I operate under the 
>assumption that 
>it is left up to the discretion of the particular community, 
>and good old-
>fashioned common sense.
>
>> I'm -1 on including any non-apache binary unless the ASF/PMC
>> explicitely allows it. That's my vote in case this is put to a vote
>> on tomcat-dev

I'm -1 making anything bad for ASF in general and will wait 
for Craig validation for my packaging proposal :

- Get jar in tomcat binary
- Get source in tomcat source 

 	=> provide tomcat RPM 

>Because if Craig's interpretation of the licenses is correct, 
>then I don't see 
>a licensing problem at all. It just becomes a matter of 
>packaging philosophies.
>
>Incidentally, there are only about 500 people in here from 
>Sun. Can't somone 
>just run it down to Legal ;-)

Yes some lobbying should be nice and many people in PMC 
ask Sun to OpenSource Java. May be Sun could start by
OpenSource more external libs, as they do for servlet/JSP
API....