geronimo-dev mailing list archives

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