Custom Assembly, Micro-G, Flexible Server, choose your favorite name

[Joe Bohn <jo...@earthlink.net>]

We've had a lot of discussions about user capabilities to build custom 
assemblies in the past (see the links at [1], [2], [3] and [4] below) 
and it seems we're launching into another one again.  This most recent 
discussion started when Lin was considering ways to improve the assemble 
a server portlet.  This discussion has now moved beyond just the console 
to bigger ideas (as it must since the portlet is exposing some core 
feature we want in Geronimo).

I thought it might make sense to pause and reflect on ideas expressed in 
the past to see if they have some bearing on where we go next.  To that 
end, I've included links to the old discussions as a way to help bridge 
the gaps, explain how we got to where we are, and communicate where we 
thought we wanted to end up.  We obviously haven't gotten to the end 
game yet, but I think we're getting closer.  Plugins are beginning to be 
more appreciated by our users and the vision is starting to catch on ... 
so perhaps we're at a point where we can finally achieve some of the 
more lofty goals (or make new ones).

Some of the original discussions were perhaps best summarized by Matt in 
[5] which was part of thread [2].  Matt has a great summary of the types 
of users and their goals in that note.


references:
[1] http://www.nabble.com/Micro-G-td6490485s134.html#a6490485
[2] http://www.nabble.com/micro-G-modules(configs)-td6669533s134.html
[3] 
http://www.nabble.com/-DISCUSS--to-plugin-or-not-to-plugin%2C-that-is-the-question-td12410749s134.html
[4] 
http://www.nabble.com/Re%3A-svn-commit%3A-r568632----geronimo-server-trunk-assemblies-geronimo-framework-pom.xml-td12276842s134.html
[5] 
http://www.nabble.com/Re%3A-micro-G-modules%28configs%29-p6721792s134.html


My take on all of this:

For Geronimo I think this translates into these goals:
1) Provide users with the ability to generate assemblies that include 
only what they want (including user created plugins).  The process 
should be repeatable across future Geronimo releases with consistent 
results.
2) Continue to provide users with assemblies that match what we certify 
for completeness.
3) Provide some "out of the box" definitions of features that can be 
leveraged as complete solutions or modified to create new solutions. 
Such "features" might include the function currently represented in 
little-G and therefore could eliminate the need to ship little-G assemblies.
4) Provide an easy to use toolkit to make all of this possible.
5) If possible, reduce the number of assemblies that we currently provide.



To accomplish these goals I think we need the following functions in 
Geronimo:
A) The capability to generate any assembly starting from a default core 
assembly.
B) A core framework assembly that can act as the foundation for building 
any more complex assembly.
C) A plugin catalog where the actual plugins to be used in the assembly 
process will reside.  This could be either shipped with an installation 
kit or made available via remote repositories.  It would not be the only 
collection of plugins but would minimally contain all of the plugins 
used to make our certified assemblies.
D) A mechanism to group sets of plugins together into logical functions 
that make sense at a user level.
E) A mechanism to further group these logical functions together into 
possible assemblies.
F) A command line or batch mechanism to consume definitions of plugins, 
groupings of plugins, and possible assemblies to produce the actual 
assembly.  If this capability remains integrated with the server it 
should be possible to run this from our smallest server assembly, 
framework.  Given that our administration console is our primary admin 
vehicle in the full javaee5 assembly we should provide equivalent (and 
hopefully more user friendly) function there.

Items B-F would most likely compose a server assembly kit that could be 
one possible deliverable from Geronimo.  So, we might end up delivering 
just the certified javaee5 assemblies and the server assembly toolkit to 
cover all other cases.

Joe

Re: Custom Assembly, Micro-G, Flexible Server, choose your favorite name

[Donald Woods <dw...@apache.org>]

Still not sold on #4 (server toolkit), given all the plugins should be 
published to the maven snapshot or release repos.  I could see providing 
the framework assembly from our distribution website with docs and 
samples of how to use it or c-m-p to create custom server or application 
centric assemblies.  If we created a repository assembly, then I could 
see that as being a separate download that could be used for local 
builds, but using the hosted maven repos would still be the preferred 
solution.

I think we need to decide in the next couple weeks how much of this we 
want to achieve for 2.2, given B,E,F will require restructuring the 
source tree and fixing some interdependencies, like -
1) framework assembly can be built from plugins and not have to include 
a separate boilerplate jarfile as today.  The Framework assembly should 
be able to start and provide a cmdline for installing other plugins to 
create a web or full jee5 runtime from the maven repos (or a local dir 
if supplied)
2) restructuring depends under the current minimal-assembly to not 
include all of the JEE5 specs and yoko files.  The specs should only be 
installed by the plugins that need them and yoko should only be pulled 
in when needed.
3) can we decouple openejb and axis/cxf support so you can have one w/o 
the other?  believe we have some deployer/builder cross depends in this 
area today.



-Donald



Joe Bohn wrote:
> 
> We've had a lot of discussions about user capabilities to build custom 
> assemblies in the past (see the links at [1], [2], [3] and [4] below) 
> and it seems we're launching into another one again.  This most recent 
> discussion started when Lin was considering ways to improve the assemble 
> a server portlet.  This discussion has now moved beyond just the console 
> to bigger ideas (as it must since the portlet is exposing some core 
> feature we want in Geronimo).
> 
> I thought it might make sense to pause and reflect on ideas expressed in 
> the past to see if they have some bearing on where we go next.  To that 
> end, I've included links to the old discussions as a way to help bridge 
> the gaps, explain how we got to where we are, and communicate where we 
> thought we wanted to end up.  We obviously haven't gotten to the end 
> game yet, but I think we're getting closer.  Plugins are beginning to be 
> more appreciated by our users and the vision is starting to catch on ... 
> so perhaps we're at a point where we can finally achieve some of the 
> more lofty goals (or make new ones).
> 
> Some of the original discussions were perhaps best summarized by Matt in 
> [5] which was part of thread [2].  Matt has a great summary of the types 
> of users and their goals in that note.
> 
> 
> references:
> [1] http://www.nabble.com/Micro-G-td6490485s134.html#a6490485
> [2] http://www.nabble.com/micro-G-modules(configs)-td6669533s134.html
> [3] 
> http://www.nabble.com/-DISCUSS--to-plugin-or-not-to-plugin%2C-that-is-the-question-td12410749s134.html 
> 
> [4] 
> http://www.nabble.com/Re%3A-svn-commit%3A-r568632----geronimo-server-trunk-assemblies-geronimo-framework-pom.xml-td12276842s134.html 
> 
> [5] 
> http://www.nabble.com/Re%3A-micro-G-modules%28configs%29-p6721792s134.html
> 
> 
> My take on all of this:
> 
> For Geronimo I think this translates into these goals:
> 1) Provide users with the ability to generate assemblies that include 
> only what they want (including user created plugins).  The process 
> should be repeatable across future Geronimo releases with consistent 
> results.
> 2) Continue to provide users with assemblies that match what we certify 
> for completeness.
> 3) Provide some "out of the box" definitions of features that can be 
> leveraged as complete solutions or modified to create new solutions. 
> Such "features" might include the function currently represented in 
> little-G and therefore could eliminate the need to ship little-G 
> assemblies.
> 4) Provide an easy to use toolkit to make all of this possible.
> 5) If possible, reduce the number of assemblies that we currently provide.
> 
> 
> 
> To accomplish these goals I think we need the following functions in 
> Geronimo:
> A) The capability to generate any assembly starting from a default core 
> assembly.
> B) A core framework assembly that can act as the foundation for building 
> any more complex assembly.
> C) A plugin catalog where the actual plugins to be used in the assembly 
> process will reside.  This could be either shipped with an installation 
> kit or made available via remote repositories.  It would not be the only 
> collection of plugins but would minimally contain all of the plugins 
> used to make our certified assemblies.
> D) A mechanism to group sets of plugins together into logical functions 
> that make sense at a user level.
> E) A mechanism to further group these logical functions together into 
> possible assemblies.
> F) A command line or batch mechanism to consume definitions of plugins, 
> groupings of plugins, and possible assemblies to produce the actual 
> assembly.  If this capability remains integrated with the server it 
> should be possible to run this from our smallest server assembly, 
> framework.  Given that our administration console is our primary admin 
> vehicle in the full javaee5 assembly we should provide equivalent (and 
> hopefully more user friendly) function there.
> 
> Items B-F would most likely compose a server assembly kit that could be 
> one possible deliverable from Geronimo.  So, we might end up delivering 
> just the certified javaee5 assemblies and the server assembly toolkit to 
> cover all other cases.
> 
> Joe
>