Comments in line...
Bryan Che wrote:
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.
:) It's actually intended to have a broader scope than just referencing the servlet classes. For example, on Tomcat, this probably refers to $CATALINA_HOME/common/lib since all of these JARs are available in classloader for each webapp. The intention is to define any classpath that's container specific -- not just to capture a dependenc on Servlet.
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.
Yeah -- it seems right to have the "appserver.build.classpath" needs to compost down into the ${servlet.runtime}-imports.xml file.
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.
Exactly! <server-ping>, <server-scrub>, etc. We just need to doc the targets that each ${servlet.runtime}-imports.xml build file need to expose in order to plug-in.
Sounds good to me. :)
Bryan
