geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: [core] why org.apache.geronimo.enterprise.deploy.provider package?
Date Tue, 19 Aug 2003 08:09:40 GMT
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:

where X is mail, ejb, jca etc.


View raw message