> On Mon, 17 Sep 2001, Jon Stevens wrote:
>
> > Date: Mon, 17 Sep 2001 21:25:33 -0700
> > From: Jon Stevens <[EMAIL PROTECTED]>
> > Reply-To: [EMAIL PROTECTED]
> > To: tomcat-dev <[EMAIL PROTECTED]>
> > 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
