geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
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 Thu, 09 Oct 2008 03:15:27 GMT
David Jencks 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.
> 
> 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.

I provided a use case in an earlier thread ... though probably not an 
extremely convincing one ;-)  (see http://tinyurl.com/3jqfzk ).  That 
discussion trailed off into a debate over when a plugin should call out 
the dependencies it actually needs or when it should call out the 
dependencies on specific deployers and let the deployers add in the 
dependencies via default environments.  I personally think that is a 
non-intuitive approach for the user and isn't very general purpose since 
not all dependencies will be added via a deployer default environment 
... but that may be a discussion for another thread.

However, I think we have to do something given that plugingroups are 
really just special purpose plugins.   We either need to let them be 
treated as plugins when called out as dependencies (and therefore handle 
the classloaders correctly) .... OR we need to insert code to prevent 
the groups from being added as dependencies (or at least flag them).  I 
still see a lot of value in allowing the groups wherever plugins can be 
used ... now if I can just think of an example that will convince 
everyone else :-) .


> 
> 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.

Agreed ... if the group includes just one plugin then it is unnecessary.

The other question here is how general purpose do we think plugingroups 
will be?  Is this primarily just a tool when building our own server 
assemblies (and custom versions of them) ... or is it a general purpose 
utility such that users can create their own plugingroups and leverage 
those when building custom assemblies as well.

I still can imagine scenarios where a user creates several application 
utilities that they want to leverage.  Each utility is created as an 
independent plugin so that various packages can be built.  They can then 
be bundled as appropriate into plulgingroups and used to build custom 
assemblies along with their applications.  If we extend the classloaders 
as mentioned in #2 the user can also add the plugingroups as 
dependencies of their applications rather than adding dependencies on 
all the individual utility plugins.

If we support the general purpose use of plugingroups then we shouldn't 
eliminate the concept just because we don't generate a lot of them for 
our assemble a server scenarios.

> 
> 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.

By definition there should always be fewer plugingroups than plugins if 
they really aggregate plugins that have some affinity. So, while the 
number of plugingroups may also grow it should still be easier to 
navigate than the individual plugins.

> 
> 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 the idea of tagging makes sense independent of the plugingroup 
discussion.  However, I'm not yet convinced that it can replace the 
plugingroup concept completely.  It can certainly be used to replace the 
attribute of plugingroup that we now have (so "plugingroup" could be 
just another tag on a plugin whose only purpose is to aggregate the 
content of other plugins).  However, I think we will still want the 
predictability of plugingroups to define the content rather than letting 
a query of tags at a particular point in time and to a particular set of 
repositories determine the set of plugins that are installed.

> 
> 6. It might be worth displaying plugin dependencies in the 
> select-a-plugin functionality.
> 
> 
> thanks
> 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 <joe.bohn@earthlink.net> 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
> 
> 


Mime
View raw message