Comments in line...
Bryan Che wrote:
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.
Seems right...
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
So, I think that we should avoid recommending that users put any JARs in the shell's CLASSPATH. Users can do this if they want, but our build shouldn't require this.
Today, the buildWebapp.xml file has a reference to ${os.CATALINA_HOME} setup by default, but the expectation is that a Beehive user would change this to reference the JAR containing the servelet API for a given container.
I believe that this is how Struts ships their samples.
Agreed that we should ensure that some servlet class is available. Ant's <available> task can do this; great idea.
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/
At build time, we actually reference the Servlet API from the JARs that are checked into ${beehive.home}/external/servlet. So, the compile and test time dependencies are decoupled.
JARs from Tomcat are only used during testing. There are some things that still need to be done like externalizing the URLs used to ping the server. These could be implemented as <server-ping> macros or something that could pull container specific propertyes from the ${servlet.runtime}-imports.xml files.
Comments?
Bryan
