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
