> > Kyle, we'd spoken about abstracting the container stuff out so you can > test on Tomcat, Geronimo, Jetty, etc, base upon a property > setting, so I'd > appreciate your concrete thoughts on that matter now. >
I think the key part here is to recognize and structure the build w/ the notion that there are some aspects of the build process which are container-agnostic and other parts that are going to need container-specific customization. Examples of things that might need container-specific customization are: - starting/stopping servers - lots of the test infrastructure does this, and it would nice if this infrastructure could be leveraged across multiple containers w/out touching the internals of the test infrastructure - building/deploying apps - there may be minor-to-major differences in how you go from beehive source artifacts to binary artifacts depending upon the target platform. At one end of the spectrum are pageflows, where the build output and app structure are relatively constant across servlet containers. At the other end of the spectrum is WSM, where there would be substantive differences in build process/output if targeting Axis vs. a JSR-109-based web services platform. Physical mechanisms for deploying and for having a running server see the changes are likely to vary as well. - building container-specific runtime code - we don't have a significant amount of this right now outside of WSM (which has a fair amount of Axis-specific code), but its likely that in the long run aspects of container integration for even controls and pageflows will include some small body of code that integrates a generic capability like async events to container-specific implementations. The source for this type of code should be kept physically separate from code that is portable across all containers, and the top-level build should make it possible to 'target' the build to a container, building both generic and container-specific portions. - distribution-building - we should probably product a 'clean' distribution which contains only container-neutral bits/jars, but also have the ability to build 'integrated' bits that target specific containers (ex. tomcat + axis) It seems like a lot of the above could be handle by some combination of generic build.xml files + imported container-specific supporting files driven by variable(s) that control the import process. As a final thought, I think we also have to consider the cases where the container integration support might live inside the Beehive source tree / depot (like it will/does for Tomcat/Axis) or potentially outside the Beehive source tree (where it would need to if targeting non-Apache containers, where committership becomes an issue). I know this is a lot to bite off, but we can work towards this over time. Probably the best thing we can do near term is to make sure that we don't 'burn in' too many Tomcat/Axis-isms in ways that make it more difficult to disentangle later. We also need to be careful to make sure that Beehive app developer experience remains as simple and clean as possible if just using the initial/default target platform of Tomcat/Axis while doing the work to build in the versatility for more downstream containers. Hope this helps! -- Kyle
