On Aug 22, 2008, at 7:35 AM, Joe Bohn wrote:
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.
My main reason for thinking it might be a good idea is that it makes
it more plausible as a standalone artifact. Everyone seems to be
thinking in terms of generating or publishing them with the c-m-p
which means I think that they will have an associated moduleID from
the maven project.
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've thought about this in the past and decided that this is a nearly
unsolvable problem and that it is much better to start over and
assemble a new server containing what you want.
The problems come when you try to figure out what should be in config-
substitutions and artifact-aliases after removing a plugin that
changed them. The plugin might have overwritten some other values.
The user might or might not have changed them by hand. WIthout a
complete history of each file I don't see how to uninstall a plugin
and come up with something plausible. I don't think the utility of
beinga able to remove plugins is worth the uncertainty and complexity
of maintaining this history. So, for now I don't want to support
removing plugins.
thanks
david jencks
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
