On Tue, 18 Sep 2001, Craig R. McClanahan wrote:
> Today, if you download (say) the 3.2 source tree and build it, in an
> environment that doesn't have JSSE installed, the build script will
> silently create a incomplete distribution for you, because it will
> silently exclude building SSLServerSocketFactory. Thus, even though you
> *think* you just built a complete binary distribution, you didn't -- you
> cannot take your distribution and deploy it on a machine that does have
> JSSE installed and run SSL connections, without going back and building
> from source yet again.
>
> Now multiply this same sort of problem by all the options people might
> want to not require in Tomcat 4.
>
> If the build system does not provide at least the option to guarantee a
> functionally complete build (i.e. fail if something "optional" is actually
> missing), I'm going to be -1 on it. Without this, people building
> distributions (including the release manager building the official ones)
> has no automated means to validate success.
I disagree with this - in tomcat3.x we do the build using only components
that are redistributable under apache license - jaxp included ( we use
xml.apache.org code for crimson, jaxp and xalan ).
The result is functionally complete - it is true it does not include
components that depend on other licenses, but I don't think you can
require people to download and accept other licenses in order to build
tomcat or redistribute.
The release manager - on the other side - or people who want to build that
functionality - can get the extra code and build the components that
would enable it, for the release or for their own use.
I believe the build system for 3.x is the right one - and it's consistent
with what Apache does - you are not required to download an SSL
implementation to build apache httpd.
( as a matter of fact, in some countries it is illegal to use encryption -
I think even France has some interesting laws - or used to have, so that
would make building tomcat quite difficult ).
It may be inconvenient for people - but if a jar is included in an apache
product that means ASF gives people who get that package the right to
redistribute it without restrictions ( assuming they give credit to
apache, etc ).
Costin
