This is getting a bit tricky. I agree that we want something like a
moduleID for the group of plugins so that it can be named in the catalog.
It would also be nice if we could persist this knowledge in the server
image.
So, if you created a server using the Tomcat group, the JMS group, and
the Axis2 group you could choose to later remove the Axis2 group rather
than being required to "know" that it contained Axis2 & Axis2-deployer.
This lack of persistence has also been a problem with plugins. They are
install time entities that are not manageable in the server after
installation (there's no uninstall for a plugin per se but you could
certainly uninstall a car). We're just seeing the same issue now at a
higher level as we discuss groups of plugins.
I'm not proposing that we have to solve this bigger issue right now. I
think it makes sense to find someway to deal with groups of plugins just
at the install level just as Lin is already doing. This is necessary to
make the server assembly more user friendly. However, at some point
(possibly soon) I think we are going to have to start rethinking what
the manageable entities are for a Geronimo server and the lifecycle of
these entities.
BTW, I like the idea of distributing the geronimo-plugin.xml files ...
it definitely gives us something to hang-on-to for possible
manageability and might be all that we need.
Joe
David Jencks wrote:
On Aug 21, 2008, at 7:26 PM, Lin Sun wrote:
Hi,
I have been looking at c-m-p plugin and geronimo plugin with no
module-id today, as David reminded me in the other thread about this
function. I'd like to use this function for the custom server
assembly stuff I am working on, as it is similar as groups of plugins
I was initially proposing.
It looks like we do have code to handle module-id = null in plugin
metadata, but i have not been successful in creating a geronimo plugin
that doesn't have a module-id using c-m-p. is this possible w/ the
current c-m-p? Anyone has an example on this type of geronimo
plugin? Would this type of plugin just contain a META-INF directory
with geronimo-plugin.xml in the directory?
I'm not sure how much sense it makes to use the c-m-p to generate a
geronimo-plugin.xml with no moduleId. IIRC the original idea (from
Aaron) was to just have the entry in the plugin catalog. Without a
moduleId you can't put it in the maven repo (IMO). So, maybe we do want
a moduleId but make it so nothing gets into any config.xml???
I've started to wonder if we should distribute the geronimo-plugin.xml
files as attached artifacts with a geronimo-plugin classifier so they
are more readily available as plain files.
still thinking.....
david jencks
Thanks,
Lin
