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