I've attached a patch http://issues.apache.org/jira/browse/
GERONIMO-2638 that provides the changes from our builders use of
JarFile to a new interface DeployableModule. Since 1.2 is currently
less disruptive, I've created a patch that can be applied to 1.2 and
eventually I'll port it to trunk. I did the changes in a way so that
all the builders don't have to change at once and the migration can
be done incrementally. Thus the use of the "temporary" classes,
ModuleBuilder2, ConfigurationBuilder2, and their abstract impls. The
current patch only changes the EARConfigBuilder and the
WebModuleBuilders (minus WebServices). I want to go ahead and get
this out so I can get input prior to migrating the rest of the
builders. So please provide your comments, concerns, feedback.
In a nutshell, the basic flow behind this change is the following..
(1) A deployableModuleType (gbean) can be set now in the
DeploymentManager by the client (eclipse for example)
(2) Given the artifact to deploy, (previously a JarFile), a new
DeployableModule instance will be created through the
DeployableModuleFactory class, passing the the artifact, where its a
JarFile or in the eclipse case, an xml file describing the
application and where all of its resources, jars, classes reside.
(3) Now the builders will now be passed around this instance of
DeployableModule, rather then the JarFile and the builders will
process the artifact, when possible, using the DeployableModule
interface.
And basically thats it. This allows Geronimo to build the
configuration from any directory structure, and no longer has to
conform to a J2EE archive structure and the copy of a resource in an
IDE is the copy that is running. It is completley pluggable and you
can easily provide support for an IDE or even a Maven project structure.
The only thing I don't like is when you're dealing with a JarFile
(the primary case outside of an IDE). I'm creating a wrapper around
the Jar using the DeployableModule implementation JarDeployable. The
problem is that whenever you're processing the JarEntries, you can't
use the interface and have to call..
if(deployable.isArchive()) {
JarFile jar = deployable.getJarFile()
//process the jar
} else {
//use the interface
}
There are only a few cases where we're travesing through the entries
of a Jar, so I'm not sure if people think this is a big deal or a
huge annoyance having to deal with 2 cases.
Please review as it would be nice to get this into M1. If you have
any suggestions on how we can improve the interface, I would love to
hear your input as I just threw this interface together a while ago
and I'm sure we can improve on it.
Thanks.
-sachin
