Now that Eddie has checked in his build system changes, I would like to propose we do the following in order to make BEEHIVE work with various app servers and also have various distributions.


4.1 Beehive Libraries

Beehive libraries would consist of just jars of Beehive code and nothing
else.  This distribution would be for users who have no intention of
developing with Beehive--they just need it as a dependency.  Also, it
would benefit packagers who want to re-distribute Beehive with other
software.

This would be shipped in a file like apache-beehive-lib-[VERSION].zip

It would have all the contents under lib/ in the current distribution as well as the NOTICE and LICENSE files.


4.2 Beehive Developer Tools

The Beehive Developer Tools would come with a set of scripts to setup
and support development environments for working with Beehive.  This
environment would be similar to the current Beehive distribution
environment.  However, it would have several differences:
- It would not include jars in itself.  Rather it would depend upon the
  Beehive Libraries distribution for providing Beehive jars and require
  installation of third-party software (just like the current Beehive
  distribution requires the user to install ant, Tomcat and Java).
- It could be installed in multiple places on the same machine.  It
  would have configuration files pointing to where canonical Beehive and
  other third-party libraries are located
- It would build and deploy wars of Beehive-based applications.
  Currently, deploying is contained in application-server-specific build
  files.  The new developer tools would have an
  application-server-neutral deploy task that builds a war and copies it
  to a user-specified location.  Extra, application-server-specific
  build files would add further functionality for popular servers
- It would provide tools to verify that the development environment is
  properly setup and that necessary libraries are present

We wouldn't include app-server-specific files. But, we do need a way to avoid having a hard-coded dependency on Tomcat for the servlet api jars. I propose that we
- document the need for the servlet api jars to be added to the user's CLASSPATH environment variable. Add documentation pointing to where to obtain the servlet api jars if the user doesn't have them already. This is what other projects like Struts or Byline do.
- modify the build files to add CLASSPATH to the path
- add an ant task to verify that that the servlet api is on the CLASSPATH. If it isn't, fail with an error telling the user to install the servlet api




4.3 Beehive Documentation

Comprehensive Beehive documentation would be available as its own
download.

4.4 Full Beehive

A full Beehive download would include all the other Beehive
distributions: the libraries, developer tools, and documentation.

5 Proposed New Beehive Source Tree Development Environment

The new Beehive source tree development environment would remain similar
to the current one.  However, it would have the following changes:
- The build files would be refactored to support multiple application
  servers rather than just Tomcat.  The end product would be similar to
  the build files in the current (not new) Beehive distribution build
  files: there would be application-server-specific files for
  running/deploying servers and a configuration switch for changing
  between application servers.  Since Beehive is an open-source project,
  it could rely to some extent on its community to contribute
  application-server files for servers that people want to see supported
- The tree would not include Tomcat or Ant and would also remove other
  third-party libraries that are common and easy to obtain.  The build
  scripts would be updated to verify that this software is present
- The source tree build tools would be able to build the various types
  of new Beehive distributions


To support multiple app servers, we would modify all the build files so that all app-server-specific stuff would come from ${servlet.runtime}-imports.xml. Right now, there are still lots of places where tomcat or catalina are directly referenced.


We would also get the servlet api from a CLASSPATH environment var instead of from TOMCAT_HOME/common/lib/

Comments?

Bryan

--
Bryan Che
Red Hat, Inc.
10 Technology Park
Westford, MA 01886
978-392-3107
[EMAIL PROTECTED]

Reply via email to