geronimo-dev mailing list archives

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

> 	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.

> 	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.

> 	Finally, if you repackage everything without looking at my patch
> first, I'll...  I'll...  I'll send it a fourth time!  But if you are 
> going
> to repackage it, some of it probably ought to go in a different module,
> not just a different package.

Agree.  I'm not going to repackage it without figuring out what works 
best for all of us.  I'll look at you patch tomorrow morning.


  * Dain Sundstrom
  * Partner
  * Core Developers Network

View raw message