See in line below. On Wed, Oct 8, 2008 at 6:41 PM, David Jencks <[EMAIL PROTECTED]> wrote: > Here are my current thoughts.... not that they necessarily mean much. > > 1. whether plugingroups are in a special svn area (rather than in framework > and plugins directly) we need the c-m-p functionality for at least the > framework plugingroup.
I agree. I think it is also agreed (from Donald and me) that besides framework, web-tomcat, web-jetty and javaee5-tomcat and javaee5-jetty are very useful. That leaves us to the few other plugin groups - clustering-tomcat/jetty ejb webservices-axis2/cxf persistence client jms jsf console-tomcat/jetty (to be removed when optional console is in place) And I don't have any intention to create any other plugin groups. I have trimmed all the irrelevant stuff out and tried to bring stuff in by transitive dependencies as much as possible. Out of these plugins, only jms and jsf contain one plugin and I did question creating them as plugin groups myself when I created them. > > 3. I have a suspicion that many of the plugingroups will turn out to only > have one plugin in them when all the irrelevant stuff is trimmed out and > stuff brought in by transitive dependencies is not listed explicitly. If > this turns out to be true then having more than the framework plugingroup > may not add much usefulness. We'll have to see. > > 4. As soon as we have numerous plugin groups, we'll have the same problem we > do now in that it will be hard to find the plugingroups you want. I don't plan to add any more plugin groups. > 5. I think I argued against it in the past but I'm starting to think that > perhaps including a list of tags with a plugin and having the > select-a-plugin functionality organized by queries on these tags might be > worth investigating. You'd pick say "ejb" and see all the ejb related > plugins -- openejb, openejb-builder, openejb-console-jetty/tomcat, cxf-ejb, > etc etc. I think this is similar as what Joe has been proposed, a filter function to allow you to see a subset of plugins (for example, tag stuff via categories). I agree this is worthy investigating and I can see both admin console and command tool benefit this. I'll take this as a TODO. > 6. It might be worth displaying plugin dependencies in the select-a-plugin > functionality. I think this is already there today in server assembly portlet. If you select a plugin to see the detail, you will get to see all its dependencies, along with name, desp, category, license. I use this a lot to figure out which plugins I can trim in a plugin group. Or are you suggesting something different? > > thanks > david jencks
