geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prasad Kashyap" <>
Subject Re: Splitting up the server into a few more chunks
Date Wed, 29 Aug 2007 17:12:43 GMT
I'm trying to understand what we have discussed/decided so far. Please
let me know if my summary is on track and help me correct course.

We haven't discussed the actual maven groupIds/artifactIds/directory
names yet. So all names used in this summary are just as examples.

1. Our basic objective is to deliver a framework and a large set of
components with which our users can build their own Geronimo server.
The primary goal of our build restructuring exercise should be to help
us meet this objective.  The next goal should be to help us build
smoothly and release efficiently.

2. We have to split the current build tree into support, framework,
and plugins sub-trees. Other than support and framework, everything
else should be plugins. This includes jee5, non-jee5, samples etc.
which could go in their own subtrees or be together.

Scenario 1:
    server/plugins/trunk/      <--- jee5, non-jee5, samples etc are
all here together.

Scenario 2:

Scenario 3:
    server/plugins/trunk    <-- jee5 plugins
    server/opt/trunk          <-- opt plugins
    server/samples/trunk  <-- samples plugins

  Can we please pick a scenario here and move on ?

3. We have to restructure the build tree to make it feature-oriented
rather than type-oriented like present. To take Jencks example, jetty
runtime, jetty deployer and jetty admin should be kept together (as a
plugin group) instead of keeping module jars and config cars separate.

                                           jetty-runtime    (1)
                                           jetty-deployer   (2)
                                           jetty-admin       (3)

  "I think you should be able to install (1), (1 and 3) (1 and 2) or
(1, 2 and 3)." - Jencks.

Further discussion:
Currently the plugins tree is structured as plugins/<component>/trunk.
IMO, this is not feasible in the long run, esp. when we want to
convert most of everything we have into plugins,  b'coz -

1. svn checkout of a complete Geronimo server (framework + all
plugins) for a given version now becomes a nightmare.
2. building all plugins for a given version becomes difficult.
3. inheritance from a common parent becomes difficult. Many things
will be duplicated across all the poms for all the plugins. Longer
poms causes larger maintenance issues.
4. Even maven plugins whom we want to emulate for their independent
release cycles are not structured this way. Trunk, branches, tags form
the top tier.


On 8/8/07, Jason Dillon <> wrote:
> On Aug 6, 2007, at 8:03 PM, David Blevins wrote:
> > On Aug 6, 2007, at 8:12 AM, David Jencks wrote:
> >
> >> I certainly agree with your goal but am less sure about your
> >> proposed naming and organization.  Also from looking at your list
> >> it took me a couple minutes to figure out what is removed from
> >> "server"
> >>
> >> I've been thinking that we could proceed by turning bits of the
> >> server into plugins.  For instance I was planning to turn the
> >> directory bits I commented out recently into a plugin this week.
> >> I think we could fairly easiiy turn jetty, tomcat, and openejb
> >> into plugins.  I wonder if, after turning the "easy stuff" into
> >> plugins what we will think about reorganizing the remaining stuff.
> >>
> >> So then the question might be how to organize the plugins?
> >
> > Haven't read the rest of the thread yet, but I'd like to backup the
> > idea of pulling things out one at a time, like we did with
> > connector and transaction, making them plugins if possible.  It
> > would be really great if people do things like upgrade OpenEJB when
> > a new release came out -- which we're hoping is often.
> I'd still like to see the plugin mangement in the console work
> something like the Confluence Plugin Repository Client ( http://
> )
> Which has a sex UI to show whats installed (version, urls, notes,
> etc), whats not (with simple buttons to install) and when stuff is
> out of date (with simple buttons to upgrade).  This would be *hugely*
> powerful for administrators managing a Geronimo instance.
> :-)

View raw message