Big Project Reorg Underway
So tonight I started a fairly radical restructuring of OpenQabal
, relative to how things are packaged. Up until now we've been packing everything into one big honkin' EAR file... all the webapps, all utility jars needed by all the webapps, the MDB for single-sign-out, etc. Truth be told this was always just a convenience thing, since it's quick and easy to deploy one EAR file while you're in development mode... but there has always been a thought that the eventual model would bundle things in a more granular fashion, to allow for separating components across servers, to make it possible to cluster individual modules, etc.
Well, as it turns out a weird glitch in the J2EE packaging spec is forcing this issue to be dealt with sooner than later. The issue is, when you bundle dependencies into the EAR as utility jars and reference them through the Class-Path: entry of the WAR file's MANIFEST.MF, you would intuitively expect (well, I would anyway) that a given WAR will only be able to access resources from a JAR which is explicitly has a reference too. Unfortunately, it turns out that this is a gray area in the spec, and some app servers (such as JBoss AS 4.0.5, which is my default dev/test environment) allow a WAR to "touch" things from other JARs. This becomes an issue when, for example, you have two webapps, one of which uses WebWork1 and the other of which uses Struts 2. What winds up happening (intermittently of course) is that the Struts 2 app picks up the Freemarker templates which are bundled into the WebWork1 distro. Or vice versa. And needless to say, the files aren't compatible. And if this problem didn't expose itself as a conflict over Freemarker templates, it would crop up sooner or alter as a class version conflict or something similar.
So, starting tonight I'm reworking all of the OQ projects so that each webapp is it's own deployable bundle (an EAR if needed, a WAR otherwise).
At the same time, I've also cut everything over to use the "new" build system by default, which temporarily renders
all the the build and deploy documentation obsolete. The new build system is a big improvement over the old one
though, and once all of the documentation is in place, it should make development on OQ ever so slightly easier.
Also, don't bother looking at the CruiseControl reports for the next day or two as well, since I haven't even started to tackle re-jiggering that stuff. Probably by the end of the week at latest everything should be stable again.
And then some real work can start on getting new features and functionality implemented.
And yes, I will eventually be posting more documentation, specifically use-cases and capability-cases, etc. that help elaborate on what OQ is, what scenarios it is meant to be useful in, etc. No, really, I promise. <smile>
Syndicated 2008-03-10 09:01:01 (Updated 2008-03-10 09:02:12) from openqabal