On Aug 6, 2007, at 12:43 PM, Paul McMahan wrote:
On Aug 6, 2007, at 12:59 PM, Donald Woods wrote:
we should consider the more drastic changes, like moving the base
Admin Console support (via Pluto 1.2) out to /plugins
I really like that idea for a couple of reasons -
- it allows us to keep the admin console that's currently at
server/trunk/applications/console in place until the new extensible
admin console is ready and can scale up from minimal to full JEE5
functionality plus debug views, etc.
- I like the idea of streamlining server/trunk for JEE5 stuff and
moving the optional stuff elsewhere
My only reservation (and its no biggie) is that using the location /
plugins for optional stuff is misleading since there will be stuff
in server/trunk that's required for JEE5 (i.e. not optional) but
implemented as plugins like tomcat, jetty, amq, openejb, etc.
Calling something a plugin is a statement about its packaging and
deployment mechanism, and not whether it is required or optional.
So maybe "/opt" or some such would be a better place to put the
extensible admin console, tuscany (eventually), directory server,
samples, roller, etc...
Personally, I don't consider the bits in /plugins as _optional_...
simply a home for the plug-able components and features that can be
dropped into the base server to make Geronimo do something useful.
After thinking about this more, I think that probably _most_ of the
stuff under server/trunk can get converted into a plugin and moved to
its own plugins/<component>/trunk, released and managed independently
of the core server framework. If we need to update the plugin bits
to make this work for more stuff, then we should do that, though I'm
not sure that is needed atm.
Then we'd end up with relatively smaller projects per feature/
component, a medium-sized project for the core server, and then a
project for the assemblies which we deliver (ie, the javaee bits,
which aggregate the javaee components, the server framework and the
configuration required to make it all work out of the box).
The only thing we have to be careful of is to not end up with a
massive set of versions to manage, so perhaps components need to have
some detail that indicates which version of the server they are
compatible with or something like that. I dunno... anyways, its
going to take some more discussion and planning before we can get to
making this a reality, but I really trully do believe that we *must*
do this to scale the management and development of Geronimo.
and start moving the Portlets into the actual modules/configs that
they administer....
I like this idea from a conceptual point of view since it keeps
things neat and well organized. But I am not sure how to implement
it since the main geronimo components are typically packaged in
JARs, and the admin portlets for a component have to be packaged in
a WAR (that's just the way that pluto works). i.e. a JAR can't
contain a WAR.
Some options I can think of:
- use EAR as the packaging format for all geronimo components and
package the admin WARs inside them
- maintain geronimo components and their admin WARs separately.
bind them at deployment time via the plugin installer's dependency
resolution or by some enhancement to the maven car plugin
- package the geronimo components as WARs so the admin portlets
can be merged with them. (seems like the tail wagging the dog)
- follow some organizational structure like in your previous email
where each geronimo component has a module, config, and (now) WAR
subdirectory
Just brainstorming here...
Um, I dunno... maybe some of the new magical console stuff that is
going on can help. But my guess is we might have to implement a
dynamic portlet, which can be given an artifact from the repository,
and then load the real impl from that artifact and display it. Then
the portlet bits per component can be bundled into a jar and tossed
into the repo, and then the console can be configured with a list of
artifacts to load into portlets. Seems like that might work out
well, if the dynamic portlet impl simply handles the bridge to the
portlet impl in the artifact and once loaded, basically proxies
everything over to it.
'm just brainstorming too... and having *never* written a portlet in
my life... maybe it will work, maybe it won't...
Though, this is one area where I think a full portal impl like
jetspeed2 might be of help since its already got all the juice to do
this kinda dynamic portlet muck... or at least I'm hoping it does.
I'm just generalizing my experience with php portals like phpnuke and
postnuke which have this kinda plugabiliity built in.
I really do think though that this is really positive direction... as
right now the console is a horrible coupling point with all of the
bits inside of the server... and if we are going to start pulling
things apart into smaller more manageable chunks, this is certainly
one key component that will need to be re-factored to allow it to
happen.
Cheers,
--jason
