What about: keep them excluded in the build target for tomcat, but add a separate target to build only javamail-dependent classes, and package them in a separate jar.
That would keep 'core' tomcat clean, and would work for other kind of modules that have external deps. It would be even better if we could just move them in a separate package - for example org.apache.tomcat.modules.mail, and exclude o.a.t.modules from the core build. Everything that will have external deps, and maybe things that are not essential could go there. Costin On 4/10/06, Remy Maucherat <[EMAIL PROTECTED]> wrote: > Bill Barker wrote: > > My patch does nothing, unless you specify the jars specifically in the > > build.properties file. There was a good reason that I didn't patch > > build.properties.default as well. > > > > I'm +1 to use the Geronimo implementations of JavaMail, +0 to using the > > optional configuration that I just put in, -1 to removing any ability to > > build Tomcat without even optional JavaMail support. > > Is it really urgent to restore the compilation of these components ? > Personally, I would like to avoid restoring the mess that was the old > build scripts, so I don't see a problem with keeping these off for now. > I think API files that won't be shipped with the binary or used anywhere > else will be needed in our repositories (for example, for supporting the > EJB and JPA related annotations, while avoiding to run into conflicts or > advertising support we don't actually have). > > Rémy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
