On Tuesday, Aug 19, 2003, at 04:27 Europe/London, Dain Sundstrom wrote:

On Monday, August 18, 2003, at 09:40 PM, Aaron Mulder wrote:

The enterprise.deploy package is currently the JSR-88 area. We
used enterprise.deploy to distinguish from "deployment", which seems to be
server component deployment instead of application deployment.

I disagree. We will only have one deployment system, and it will support 88. If what we have doesn't work with 88, we need to change it.

Is this based on an analysis of what is there, or is it just a feeling? JSR88 is aimed at a very specific sense of 'deployment' which may not be compatible with other meanings of the word 'deployment'.


As for "provider", it's to distinguish it from the tool side,
which will be used for management consoles, etc. and from the objects
(generated by Castor into "common" in the pending patch) that represent
that actual J2EE component metadata (the object representation of the DDs,
in other words) and from the stuff (currently not implemented) that will
actually do the work of deployment on the server side.

I agree. We should have org.apache.geronimo.provider. This all needs to work like a seamless unit, and not a bolt on. Having them in the same package is just the first step.

'provider' is too generic a name. Would this mean 'mail provider'? 'session replication provider?' A package without a definite definition isn't going to solve the problems.


The reason why the 'enterprise', and indeed, 'deploy' were part of the package name were to say that these were relating to the deployment of enterprise code, as opposed to a generic provider.

I think the provider stuff should remain separate from
"deployment" because its only a JSR-88 implementation -- it's the GUI
logic (and potentially widgets) that a tool will use. It's full of
JavaBeans (particularly if you look at the xxxBeanInfo classes in the
pending patch), and they all have to be packaged together and separately
from most everything else in order to be distributed to tools (the patch
also creates a JAR out of these classes, with a manifest full of bean
declarations and so on).

These are all fine to have in deployment. For the actual tools, like a deployment GUI, console or ant task those should go into a deployment tools module. Now come to think of it, I think this stuff should go in with the rest of our management tools. Every type of management tool I think of I also want a deployment tool. I'm thinking of web, GUI, console, and ant.

Perhaps a common packaging convention is called for, then:

org.apache.geronimo.X.management
org.apache.geronimo.X.deployment

where X is mail, ejb, jca etc.

Alex.



Reply via email to