geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
Date Wed, 08 Oct 2008 22:41:58 GMT
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.

2. IIUC Joe's idea was to make it so a dependency on a classloader- 
free plugin turned into dependencies on all its dependencies.  I would  
like to see an extremely convincing and specific use case for this  
before we consider implementing it.  I could easily be wrong but fear  
this would introduce hard-to-understand complexity with little gain.

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  

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.

6. It might be worth displaying plugin dependencies in the select-a- 
plugin functionality.

david jencks

On Oct 8, 2008, at 2:13 PM, Lin Sun wrote:

> See in-line below...
> On Wed, Oct 8, 2008 at 4:37 PM, Joe Bohn <>  
> 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
> Lin

View raw message