Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <468A7DC2.6040509@joyfulnoisewebdesign.com>
Date: Tue, 03 Jul 2007 11:48:02 -0500
From: "Jay D. McHugh" <jay@joyfulnoisewebdesign.com>
User-Agent: Thunderbird 1.5 (X11/20060204)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: [DISCUSS] Geronimo 2.1 - what's next?
References: <4283E004-1345-4353-94F3-09B05949354B@hogstrom.org>
In-Reply-To: <4283E004-1345-4353-94F3-09B05949354B@hogstrom.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I was also thinking about the delivered server (since we have been 
discussing footprint).

Perhaps we could deliver Geronimo as two pieces:
1) A minimal server that provides a console for adding plugins or plugin 
'packages' (ie: certified jee5 tomcat server)
2) An archived plugin repository.

If someone knows that they will be able to access the online plugin 
repository, then they would only need to download the basic server (nice 
and small) and add plugins as needed.

Hopefully, that will avoid all of the transitive dependency and unneeded 
module issues.

We could decide what combinations we wanted to certify on and provide 
those as templates (or profiles or packages or whatever name we came up 
with for them) for easy installation.

And, if users put together combinations that they thought might be 
useful for others - they could possibly upload them as a package profile 
(or at least email them around).

That would add a step for someone who wanted to just download a JEE5 
server - but it would emphasize that Geronimo is more than just a JEE 
server.

Jay

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?
>
>
>
>
>