I think I'd be fine either way but I would need this plugin group function to enhance the existing custom assembly UI.
1. use no module-id to indicate the geronimo plugin is a plugin group. In this case, each assembly we ship will include geronimo plugin group catalog file to keep track of what plugin groups it has. When a user selects to install such a plugin, it would only install the plugin's dependencies. So we won't see this type of plugin in the repository. 2. with module-id but has some properties such as <PluginGroup>true</PluginGroup> or <module-id pluginGroup="true">. In this case, when a user selects to install such a plugin, we'll install the plugin and its dependencies, except that we won't register the plugin's configId in server's config.xml. I imagine this type of plugin exists in the repository (sort of like an empty geronimo plugin but with geronimo-plugin.xml in it). I was learning towards No. 1 because we already have lots of code to handle the cases where module-id is NULL and it makes sense to me that we don't leave anything in the repository for this type of plugin group, but I can go with whatever the community wants to go. Lin On Fri, Aug 22, 2008 at 12:15 PM, David Jencks <[EMAIL PROTECTED]> wrote: > > 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 >> > >
