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 <[EMAIL PROTECTED]> 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
>
>
