Well, I would have prefered to not have this subject opened up...
My understanding of the "Apache License" is that a product/build
distributed by ASF should contain only code and libraries that have Apache
license or something that is compatible.
I agree with most of Craig's argument, as long as we are sure we can
indeed distribute those files in the first place ( somone more familiar
with apache licensing can answer this ).
And I'm not sure I agree with having compile-time dependencies on code
that we can't distribute - that's the reason 3.x doesn't depend on JSSE
nor J2EE ( even if it includes modules that would enable this
functionality ).
Also, I believe pieces of code that depend on non-distributable code
should be optional - the release should be built to include them, but the
code should work fine if they are not present.
Costin
On Thu, 13 Sep 2001, Remy Maucherat wrote:
> > "Craig R. McClanahan" wrote:
>
> > I am not talking about what API's/jar files are required to build Tomcat
> 4.
> > The only place my tests were used was to determine if the jar file should
> > get copied into $CATALINA_HOME/common/lib when I do a build. The official
> > distribution you build will still contain all the jar files you want.
> > And if someone is building Tomcat 4 from source and follow your directions
> > for building they to will get those jar files copied into common/lib.
> > If they fail to follow your directions for configuring the
> build.properties file
> > either the build will break or the required jars will not be available at
> runtime.
> > Hopefully someone building from source is clueful enough to figure that
> out.
> >
> > This doesn't affect the binary distribution, which is where the support
> > questions come from.
> >
> > I don't see anything wrong with making the _build_ a bit flexible instead
> > of forcing all who build Tomcat 4 into a one size fits all mode.
>
> I think that it's very good for big projects, because it will force you to
> test everything (instead of leaving out parts of the code which may be
> broken).
> Example: There was a bug in Catalina with JDK 1.3 and JNDI which was caused
> by having 'jndi.jar' loaded in the commonCL, which was causing a conflict
> with the JNDI classes loaded by the system CL. Now, if you allow developers
> to not have jndi.jar with JDK 1.3, that pretty much guarantees that the bug
> will be found out much later.
>
> Of course, there are a extreme cases, like IMO the JAF and JavaMail. I say
> it's time to create that 'modules' repository and put these factories there
> (but that can wait for the next release) :)
>
> Remy
>
