You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jon Stevens <jo...@latchkey.com> on 2001/09/18 06:25:33 UTC
Compile errors
I'm trying to build off the tomcat-4.0 branch and it isn't working...
It seems that for some reason, the copying of the files over to the build
directory is commented out. Why is that? It says that one cannot
re-distribute the JSSE stuff, but this is for BUILDING, not distribution.
The distribution build process should remove those files if they exist...
-jon
build-main:
[javac] Compiling 4 source files to
/Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/classes
[javac] Compiling 16 source files to
/Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/classes
[javac]
[javac] Found 14 semantic errors compiling
"/Users/jon/checkout/jakarta-tomcat-4.0/catalina/src/share/org/apache/catali
na/net/SSLServerSocketFactory.java":
[javac]
[javac] 71. import javax.net.ServerSocketFactory;
[javac] <--------------------------->
[javac] *** Error: "javax/net/ServerSocketFactory" is either a misplaced
package name or a non-existent entity.
[javac]
[javac]
[javac] 72. import javax.net.ssl.SSLServerSocket;
[javac] <--------------------------->
[javac] *** Error: "javax/net/ssl/SSLServerSocket" is either a misplaced
package name or a non-existent entity.
[javac]
[javac]
[javac] 73. import javax.net.ssl.SSLSocket;
[javac] <--------------------->
[javac] *** Error: "javax/net/ssl/SSLSocket" is either a misplaced
package name or a non-existent entity.
Re: Compile errors
Posted by Remy Maucherat <Re...@sun.com>.
> On Mon, 17 Sep 2001, Jon Stevens wrote:
>
> > Date: Mon, 17 Sep 2001 21:25:33 -0700
> > From: Jon Stevens <jo...@latchkey.com>
> > Reply-To: tomcat-dev@jakarta.apache.org
> > To: tomcat-dev <to...@jakarta.apache.org>
> > Subject: Compile errors
> >
> > I'm trying to build off the tomcat-4.0 branch and it isn't working...
> >
> > It seems that for some reason, the copying of the files over to the
build
> > directory is commented out. Why is that? It says that one cannot
> > re-distribute the JSSE stuff, but this is for BUILDING, not
distribution.
> > The distribution build process should remove those files if they
exist...
> >
>
> And *that* is why the build system was modified to be the way that it is.
> (I haven't voted yet on the future build mechanism, but here's the
> background on the current approach.)
>
> 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.
That's cool, but my proposal included an option (the C) which would allow
people to build a version of Tomcat for their own environment (for example,
I plan to have JDK 1.4 switches where the build process wouldn't bug you
with JSSE, JAXP, among other things), while leaving in the full build, which
has indeed many advantages and should be used to build the distribution
binaries.
So I fail to see the problem.
> 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.
Fair enough, but it's only truly useful for the release manager and some of
the core contributors, while discouraging external contributors from
actually getting involved.
I think option C was an appropriate middle ground.
We can also add something which would display the status of the various
flags before starting building.
Remy
Re: Compile errors
Posted by cm...@yahoo.com.
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
Re: Compile errors
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 17 Sep 2001, Jon Stevens wrote:
> Date: Mon, 17 Sep 2001 21:25:33 -0700
> From: Jon Stevens <jo...@latchkey.com>
> Reply-To: tomcat-dev@jakarta.apache.org
> To: tomcat-dev <to...@jakarta.apache.org>
> Subject: Compile errors
>
> I'm trying to build off the tomcat-4.0 branch and it isn't working...
>
> It seems that for some reason, the copying of the files over to the build
> directory is commented out. Why is that? It says that one cannot
> re-distribute the JSSE stuff, but this is for BUILDING, not distribution.
> The distribution build process should remove those files if they exist...
>
And *that* is why the build system was modified to be the way that it is.
(I haven't voted yet on the future build mechanism, but here's the
background on the current approach.)
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.
> -jon
>
Craig
> build-main:
> [javac] Compiling 4 source files to
> /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/classes
> [javac] Compiling 16 source files to
> /Users/jon/checkout/jakarta-tomcat-4.0/catalina/build/classes
> [javac]
> [javac] Found 14 semantic errors compiling
> "/Users/jon/checkout/jakarta-tomcat-4.0/catalina/src/share/org/apache/catali
> na/net/SSLServerSocketFactory.java":
> [javac]
> [javac] 71. import javax.net.ServerSocketFactory;
> [javac] <--------------------------->
> [javac] *** Error: "javax/net/ServerSocketFactory" is either a misplaced
> package name or a non-existent entity.
> [javac]
> [javac]
> [javac] 72. import javax.net.ssl.SSLServerSocket;
> [javac] <--------------------------->
> [javac] *** Error: "javax/net/ssl/SSLServerSocket" is either a misplaced
> package name or a non-existent entity.
> [javac]
> [javac]
> [javac] 73. import javax.net.ssl.SSLSocket;
> [javac] <--------------------->
> [javac] *** Error: "javax/net/ssl/SSLSocket" is either a misplaced
> package name or a non-existent entity.
>
>