See in-line below... On Wed, Oct 8, 2008 at 4:37 PM, Joe Bohn <[EMAIL PROTECTED]> wrote:
>>> Thanks for making the suggestions. It is always good to hear >>> feedback and challenge our thinking! :) >> >> Yep, I wish we had more than 4 people actively looking/discussing this :-( > > Ok ... you asked for it ;-) ... Also see my response on the other branch of > this thread. We had over 4 people in the past... I am sure :) >>> My initial thought of grouping the plugins together was by category, >>> however I think it has the following limitations - >>> >>> 1. A user can specify his module to any category he likes too, thus it >>> could interfere with the resulting tree. For example, a user has a >>> module that is also categorized as console or development tools or >>> administration. >>> >> >> Don't see this as an issue, since we control the default repository-list >> and what goes into the geronimo-plugins.xml for the server and samples. If >> a user created their own repo (like Liferay) then their plugins would be >> listed under the "Liferay Repo" instead of the "Geronimo Server Repo" and >> they could use whatever categories they want. The user can grow the repo-list easily by deploying an app onto the local G server. There isn't a geronimo-plugins.xml for the local geronimo server repo, but the server is capable to build one on the fly. > > I see both points here. As Donald mentions, the repository should be in > control of the namespace for the categories. However, that only works with > an external repository. However, at the moment the assemble a server > functions only work with the local, server repository which can include > plugins from multiple external repositories. To have the assembly function > with correctly to build up a server it will eventually have to let the user > choose plugins and plugingroups from multiple external repositories. That > should be interesting. I agree currently it is local server only, and the prob still exists with local server, as a user can install the plugin onto G server, which will make the user's plugin resides in our local repo. > >> >> >>> 2. group by category doesn't offer any integration into maven. As you >>> know, we are using plugin groups for all of our G assemblies now. >>> >> >> I'm questioning if this "maven integration" is worth the added source >> complexity. I'm starting to lean heavily towards "No" and wondering if we >> should remove most of the pluginprofiles for 2.2 and only keep - framework, >> minimal and jee5. Once we get user feedback on what groupings "are missing" >> then we can consider adding more. I am missing the added source complexity here. We only added very little code to support plugin group as David reminded me the function is already there. In fact, having functions divided by plugin groups allow me to clean up our long list of little G assemblies & javaee5 assemblies (there are lots of unnecessary dependencies) and only use what is really needed (others can be pulled via transitive dependencies). I think we should keep most of them as they are today and revise them upon users' request. The only ones I had debating myself if I should create them are jms, jsf and console. jms and jsf plugin groups each contain only one plugin as the other plugins can be pulled via transitive dependencies. However, that doesn't mean users know which ones to pick easily. About console plugin group, I'd be totally ok removing it when we switch to optional console. > > I think this can be worth the effort if we keep things simple. Only create > plugingroups when they are really necessary and leverage the groups > consistently. I personally like the idea of the groups so that a user can > incrementally grow function in a new or existing server in logical chunks > without having to understand all of the detailed plugins that we generate. Me too. >> >> >>> 3. group by category doesn't help with command line install-plugin >>> command. Currently you can install a plugin group by using "deploy >>> install-plugin <plugingroup id>" >>> >> >> It would have to be enhanced, which it greatly needs IMO. >>> 4. group by category doesn't help with "gshell deploy/assemble" >>> command. A user is unlikely to have some fancy GUI like tree in a >>> command line env. >> >> If a user is trying to assemble from cmdline, then they will suffer and >> should either write a gsh script, use c-m-p or the console. > > Alternatively, part of the enhancement of the command line could be to allow > the user to filter the list of plugins returned by category. That is possible to enhance, IMO. >> >>> >>> With plugin groups, you can still group plugins by category. In fact, >>> in the install plugin portlet that we allow users to sort plugins by >>> category, name, etc. I disabled the sort function in assemble server >>> portlet as it needs more work but the plugins are sorted by category >>> right now. >>> >>> I think I agree with you that the console-xxx plugin group are not >>> that useful and I think they can be removed after we make most of the >>> console components optional. Currently, all these console components >>> are under application plugins, and I 'm updating their names, desps, >>> and categories to enable users to select them easily. For example, >>> if a user wants little G tomcat + JMS, he can select web-tomcat, JMS >>> plugin group, and Console: JMS from application plugins if he wants >>> console support for JMS. > > I think it would make sense to have several plugingroups (or aggregate > plugins) when dealing with the console extensions. One possible pattern > would be to create a plugingroup for the core function and then another > plugingroup which includes the core function plugingroup and the console > extension. For example (PG indicates a plugingroup, P just a plugin): > > PG - JMS + Console > includes: PG - JMS > P - JMS console > > PG - JMS > includes: P - the JMS and associated plugins that are necessary. > > Here a user could choose to include the plugingroup for JMS + Console or > just the plugingroup for JMS. Joe, I had thought about this too. The other way to do things is pretty straightforward too, either pick PG -JMS + P - Console, JMS (this is only one plugin thus I don't feel we need a group for it). or PG -JMS Lin
