geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hernan Cunico <hcun...@gmail.com>
Subject Re: [DISCUSS] Geronimo 2.1 - what's next?
Date Thu, 05 Jul 2007 14:31:00 GMT
Great list Matt!
Here are my thoughts based on the discussion/questions I see on the dist lists, and talking
to other users.

These bullets you mentioned I think can all be addressed via plugins

- Flexible framework for building server assemblies that include only the components needed
for an application
- Dynamically binding needed elements
- Dynamic Console for managing installed artifacts

What makes me think we need to simplify the plugin architecture and remove as many infrastructure
requirements as possible. For example, can we get away from the need of having a maven repository
for housing the plugins? ultimately, what is a plugin? can it be served and installed in an
alternative way? The infrastructure for distributing plugins should be easy to use and easy
to set up. Consuming plugins should be as easy and simple as possible as well.

If we have the alternative to install components via plugins, then we should also be able
to uninstall those very components (and dependencies when possible) the same way by removing
the plugins. Maybe we could use a tool for listing, enabling, disabling, removing and even
exporting plugins and plugin bundles (a plugin made of many other plugins already installed).
These plugin bundles may help clone servers for setting up clustering which is another big
beast to tame.

If we manage to distribute along with the plugin all the necessary administration bits (portlets
and command line option when possible) then Geronimo could be known as, quoting Jeff, "...a
pluggable lightweight container with management..."

In parallel, I also think we should pay some attention to the complexity of the deployment
plans. I would even include some configuration files in the same bag. I know annotations play
a big role in simplifying the plans however plans would still be around. I think we should
make Geronimo to assume/propose more "defaults", or to say it in a different way, less strict.
The other way might be to provide some sort of tool (a deploy wizard!?) that will ask for
additional input while installing the application. I am not a good fan of this option, quite
the opposite actually.

We've been trying to fill the deployment plans "know how" gap with the documentation, we covered
schemas, plans and provided sample applications. It is clear we are not answering all the
questions there.

Now that we passed the certification I think we should spend some time in overall flexibility
and usability.

Cheers!
Hernan

Matt Hogstrom wrote:
> Seems like the dev list has been  a bit quiet lately as I know many 
> folks have been working on getting 2.0 done and through some additional 
> testing for Axis, fit and finish stuff, etc.  Although important, its 
> not exactly the next generation so I thought I'd start this thread to 
> get some ideas formed around the next step for AG.  These are just my 
> thoughts and I'm soliciting input for ideas and discussion.
> 
> I thought I'd put my thoughts in the form of a user describing what they 
> need from Geronimo.  This is based on input I've heard from several 
> folks as well as users and includes some of my own ideas as well.  It 
> feels like we've been chasing the specs for so long that we haven't 
> fully realized some of the other awesome ideas people have had.  Aaron's 
> plugin architecture is workable but not fully consumable, Dain's 
> repository work and a host of other ideas.  I think now is the time to 
> have some fun.    To that end here is the list of requirements.
> 
> Geronimo 2.1 Punch List
> 
> *Flexible framework for building server assemblies that include only the 
> components needed for an application*
> 
> This means that a user could either build a custom assembly with only 
> the needed parts or, alternatively, could run with all parts available 
> but only start what they need.  The model is up to the user to decide 
> based on their unique requirements.
> 
> *Dynamically binding needed elements*
> 
> Using the plugin architecture and Maven repo concepts one could install 
> a needed element into the server by simply pointing to a remote 
> repository and installing the element.  Other artifacts needed for 
> execution would be obtained automagically from either the network or a 
> shared filesystem as needed and based on the policies provided by the 
> user.  The default mode of operation would provide the best user 
> experience.
> 
> *Dynamic Console for managing installed artifacts*
> 
> Improve the console framework to allow installed artifacts to register a 
> portlet for managing the configuration.  For highest level of 
> flexibility a component would provide the required portlet elemtns and 
> we would bind them into the navigation framework and security 
> infracstructure.  We'd need a good set of docs and samples to help 
> people in deploying this easy.  Ideally we would start with a minimal 
> assembly and a mgmt console so that new functions could be loaded 
> through the console.  I'm not sure that we'd need to have an assembly 
> smaller than minimal at this point since we'd need a web container for 
> the mgmt console anyway.
> 
> *Cluster Aware Mgmt Application*
> 
> For users that want to federate a number of servers together we need a 
> clustering solution that will allow for configuration of nodes as well 
> as autodiscovery.  This requires a clustering element for Geronimo that 
> takes into account multiple clustering users (services).  I think Jeff 
> has some of the foundation in GCache.
> 
> 
> *SOA Assembly*
> It would be great to have a SOA assembly (that works in a flexible way 
> :) with AMQ, ServiceMix and a Tx Manager.  A LOT of people I talk to 
> want something simple like a Tomcat and a Mule...let's give it to them.
> 
> 
> *Tooling*
> A really huge part of what people have talked about as being important 
> is tooling integration (I've heard mostly about Eclipse and NetBeans).
> 
> 
> *OSGi and Spring*
> This has been kicked around for a long time.  I was talking with someone 
> who said they needed a flexible runtime that would allow them to wire in 
> OSGi bundles (seems like the traction is increasing) and use Spring for 
> the configuration.  People smarter than I can weigh in on this area but 
> this is seems to get Independent Software Vendors (ISV's) all hot under 
> the collar.  If we could deliver this with the flexible server stuff I 
> think we'd have a huge swell of interest.
> 
> 
> Other thoughts?
> 
> 
> 

Mime
View raw message