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.
Ahh, then I suggest we rename the path, "appserver.build.classpath" to something like "servlet.api.path" and point specifically to ${os.CATALINA_HOME}/common/lib/servlet-api.jar. That would make it much clearer where the user is supposed to add in the servlet api jar.
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.
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.
OK, so then we can just have a "servlet.api.path" property in each {servlet.runtime}-imports.xml file for running tests.
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.
Yeah, I would envision abstracting out stuff to macros so that we could use different app servers.
Bryan
-- Bryan Che Red Hat, Inc. 10 Technology Park Westford, MA 01886 978-392-3107 [EMAIL PROTECTED]
