geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rex Wang <>
Subject Re: some console issues.
Date Mon, 01 Feb 2010 09:30:32 GMT
2010/2/1 David Jencks <>

> On Jan 31, 2010, at 11:47 PM, Rex Wang wrote:
> Currently, I am trying to make some console portlets re-work.  But firstly,
> I hope the following issues can be addressed:
> I found the "pluto-support" don't have a groupId as
> "org.apache.geronimo.configs", which likes the other plugins convention.
> Instead, it inherits the parent's groupId "org.apache.geronimo.plugins". I
> think that might be a typo, right?
> I think there have been suggestions to make the groupId of all the plugins,
> o.a.g.plugins.  I'd like to do this eventually.  I think pluto-support and a
> couple others are the only ones this happened to yet.

So the result we will finally move all the plugin cars' groupId to
"o.a.g.plugins"? My impression on the convention is, for instance, in axis2:
  L axis2
  L geronimo-axis2
  L ..
because the parent & child have the same artifactId "axis2", so the groupId
must be different..
Will you plan to change all the subprojects of axis2 to "o.a.g.plugins" no
matter they are modules or configs?

> Secondly, I plan to move the dojo-war into console-ear instead being an
> individual plugin. Since we has modified the navigation tree to base on
> dojo, it should be a basic war, not a plugable component, for web console.
> The original thinking was that dojo would be useful to other projects, so
> we should make it available separately from the web console.

> Also, I hope to merge the plugin portlets into console-base-portlets.
> Because the plugin is a core feature to geronimo, I am not comfortable to
> separate it from the base portlests and also make 3 more sub-project folders
> under console.
> I'd prefer to keep it separate.  IIRC if you don't install the plugin
> console plugin, you can't install any new apps or plugins into the geronimo
> server.  IMO being able to have a console without this capability is
> important.
I see what's you concern.  If the deployment is so important, maybe the
undeployment functions should be separated from the current portlets too?


> The changes should be easy and relatively independent so that it won't
> disturb the works on the other plugins. Any comments?
> Sorry to be negative, but I'd prefer to avoid all these changes.  If you
> think they are important, please explain why in more detail.
> thanks
> david jencks
> Thanks
> --
> Lei Wang (Rex)
> rwonly AT

Lei Wang (Rex)
rwonly AT

View raw message