geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: micro-G modules(configs)
Date Fri, 06 Oct 2006 03:37:24 GMT
Yes, we need to keep enough to be able to run the command line deployer. 
  When I pulled j2ee-deployer I was unable to run the command line 
deploy.

more comments/questions below

David Jencks wrote:
> 
> On Oct 5, 2006, at 3:52 PM, Aaron Mulder wrote:
> 
>> I think we need to keep enough in there that the command-line deploy
>> tool still works.  It looks like online-deployer is empty (or else I
>> would have said to keep that), but I think j2ee-security is required
>> for the JMX remoting used by the deploy tool.  Without this, I think
>> you'll have to mangle the repository contents and config.xml by hand
>> in order to ever have more than "Micro G" (ick).
>>
>> Anyway, I would also be in favor of separating the specs from RMI  
>> naming.
So let me see if I understand the idea here.  I can pull the spec 
dependencies from RMI naming and create a new config with just those 
dependencies.  I suspect that I will need to make rmi-naming dependent 
on the new spec config but then I think that limits the ability to 
easily switch between 1.4 and 1.5 specs.  Are the specs not really 
required for rmi-naming and currently included just as a way to get the 
specs in the image?

>>
>> Thanks,
>>     Aaron
>>
>> P.S. Maybe we should whack the online-deployer module and rename
>> "j2ee-security" to just "security" or something.
> 
> 
> Online-deployer is empty just like the rest of the configs that are  
> servers.  It relies on manifest classpath and the configuration it  
> contains.  IIRC online-deployer.car is the same file as  deployer.jar.  
I was under the impression that this was required for the command line 
deploy as well but I'll pull it and see what happens.

> I guess you're right that a little more might be  good.  I was figuring 
> that being able to add plugins might be  enough.  What connects to the 
> plugin installer?
> 
> thanks
> david jencks
> 
>>
>> On 10/5/06, David Jencks <david_jencks@yahoo.com> wrote:
>>
>>> I marked the ones to remove IMO  with an X
>>>
>>> I seem to have a more extreme view of "micro" than you :-)
I'm all for getting micro-G as small as possible so long as we can grow 
it easily.  I guess if the dependencies are all correct (which is not 
the case right now) then installing the higher level plugins should pull 
everything else along for the ride.

>>> I'd also prefer to pull the specs out of rmi-naming into a separate
>>> config so we can swap in the jee5 ones more easily.
>>>
>>> thanks
>>> david jencks
>>>
>>> On Oct 5, 2006, at 2:59 PM, Joe Bohn wrote:
>>>
>>> >
>>> > The following modules are currently included in micro-G.
>>> > What of these should we attempt to remove yet from micro-G?
>>> >
>>> > X connector-deployer
OK, I'll attempt to pull this one.

>>> > geronimo-gbean-deployer
>>> > X hot-deployer
I'll pull this one too.

>>> > X j2ee-deployer
So I assume that we really need to keep this for plugin deployment 
unless we rework that code some more.

>>> > X j2ee-security
If this isn't really j2ee specific then I can rename it but based upon 
Aaron's comments it looks like this is still required in micro-G.

>>> > X j2ee-server
Is it true j2ee-server can be removed?  I was under the impress that 
this was necessary for some of the management capabilities.

>>> > j2ee-system
>>> > X online-deployer
Is this not necessary for command-line deployement as well?

>>> > rmi-naming
>>> > X sharedlib
Isn't sharelib of value even without the web containers?  I didn't think 
there was a lot of value in removing this but it's an easy one to pull.

>>> > shutdown
>>> > X transaction
I can look at removing this as well but I was under the impression that 
the transaction capability was general purpose and not tied directly to 
j2ee.

>>> > X unavailable-client-deployer
>>> > X unavailable-ejb-deployer
>>> > X unavailable-webservices-deployer
I think these three unavailable* configs are necessary so long as we 
keep the j2ee-deployer.

>>> >
>>> > I'd like to be able to remove the unavailable* deployers but at the
>>> > moment I think they are pretty tightly tied to the j2ee-deployer
>>> > which IIUC we need to keep since it is really not just for j2ee
>>> > deployments. IIRC I attempted to remove j2ee-deployer earlier and
>>> > discovered that I needed this to be able to deploy plugins into
>>> > micro-G.  I think the other j2ee* modules are likewise required for
>>> > more than just j2ee content.  Is this true?
>>> >
>>> > I think we might be able to remove hot-deployer ... any thoughts?
>>> > My only concern is that if we get too fine grained then it gets
>>> > difficult to build up the image to be equivalent for little-G or
>>> > higher.  Right now to get from micro-G to little-G you need to
>>> > deploy both the tomcat or jetty plugin and the corresponding
>>> > deployer.  Removing hot-deployer will add another item to the
>>> > list.  Thoughts?
>>> >
>>> > Joe
>>> >
>>> >
>>>
>>>
> 
> 
> 

Mime
View raw message