On Aug 30, 2007, at 5:12 PM, David Jencks wrote:
Getting 2.0.1 out the door was a great step and now might be a good
time to start discussing where we want geronimo to head next. Here
are some ideas I've had or think are important. If I were to try
to write actual sentences about all of this I'd probably never send
the email so this is way too fragmentary but maybe can spark more
discussion. I'm hoping everyone will chime in with their interests
and viewpoints, this is just what I've been thinking about lately.
Modularity.
For a long time we've been on the brink of having an actually
modular server, not just a conceptually modular server. As
reflected in a lot of recent discussion on the dev list, I think we
are so close we should really work hard to make this a pleasant
reality. Some of the steps I see:
- enhance the plugin framework so bits of more config files can be
added, in particular artifact_aliases.properties and
config_substitutions.properties. IIUC Paul has some schema changes
and xml handling rewrites in the wings as well
- finish up the pluggable admin console work and actually split the
admin console into appropriate bits for the plugins
- rearrange the build so it is organized by plugin
- actually assemble the servers we ship using plugins, perhaps
using gshell scripts
- have more server-building tools. For instance, a "button" to
push that spits out a server with just what is needed for a set of
apps and nothing else.
Yay... modularity is my friend... and enemy :-P More modular server
means more build muck to assemble it :-P But IMO this is probably
the most important feature (if you can call it that) which we need to
implement to ensure the longevity and maintainability of Apache
Geronimo.
Clustering
IIUC we have a lot of partial clustering solutions. For instance
there's WADI, native tomcat clustering, a terracotta integration,
and IIUC Jeff has been working on a clustering solution (my
apologies if I left any out). I'd like to know where these efforts
are in terms of actual functionality and reliability and what they
can be extended to do. We also need some kind of cluster admin tools.
Certainly a nice to have, and almost always on user's want to have
list, though from past places I've worked we never have really made
use (fully) of any application server's clustering facilities. I'd
like to see this added, and I'm sure we will get it sooner rather
than later, but I think that the modularity (and inevitable
decoupling) work is vastly more important to the project (perhaps not
users).
Other apps
roller
jetspeed
proximity etc
It would be great to get "all popular apps" available as geronimo
plugins.
Ya, would be nice to get the main G distribution to a point where you
can *easily* (as in my eyes are closed and I'm clicking the install
some neat feature button) get a fully functional, kick ass, easy to
use and admin server ;-)
Management and troubleshooting
ARM
No LEG?
Otherwise we discared it.
server farm management (gshell?)
This is definitely on my "in my head" roadmap for the shell, though
we need those clustering bits first to give it something to work
with. One thing we might want to add before then is some kind of
reboot facility to the server, which is possible using the GShell
launcher process. So a user can install some muck, tweak some
configuration, then tell the server to reboot and basically pick up a
pristine configuration and working environment. The same basic
mechanism could be used to create a rollback configuration, or named
configurations, etc.
I've been working on simplifying the GShell framework for the past
week, and will continue for a few more me thinks as I've been re-
inspired by the positive feedback I've heard so far, as well as my
renewed desire for GShell to rule the world and make me coffee in the
morning.
So expect to see some more GShell goodies on the way soon...
Core
Better Spring application management
Investigate OSGI and figure out how it is different from what we
are doing, what it can do better, and what is missing from it.
Figure out an integration strategy whether it be "run OSGI as an
application" or "replace the kernel with OSGI" Don't break stuff
if we start using OSGI more :-)
I think some investigate is defs in order here, though I'd really
like to see the system split up into smaller manageable chunks before
this is considered for implementation. I don't think that the
current gbean framework is so inflexible to make that a non-option.
So lets split up the server, learn from that exercise, keeping in
mind how we can make it easier, require less code and perhaps even do
more... then lets do it. I'd personally like to see us using
annotations to define all those properties and operations and such on
our components... I fricken love annotations.
Figure out what to do with our "config.ser" in modules/
configurations. At least get it into real xml, maybe using
something like jaxb with schema/gbean.
OOOOH HEEEELLLL YA!!!!
I'd really like to see the configuration for a module, in plain xml,
based on some schema that is descriptive and extensible enough to
handle pretty much any kinda of configuration we want to toss at a
set of beans (or anything users want to, and they will come up with
some crazy shiz for sure).
And... I want to see those XML files deployed into the repository
ASIS... IE... not in any *ucking jar/ear/war/whatever file.
And, on a related not... those damn CAR files that are expanded...
well, they shouldn't be. The repository should contain artifact
*files* only... so if we need to unpack them on the fly, then do it.
Or if users want to use an unpacked dir for their deployment, then
use the deploy/* directory or something, but leave the repository/*
as files.
* * *
So, based on what I've just babbled about so far... I'd like to see
2.1 focused on developer improvements (for us, and plugin
developers), more application support to get users going faster, and
administration support (that includes the xml stuff in the repo and
gshell bits).
Anyways... just my comments.
--jason
