geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Snyder <bruce.sny...@gmail.com>
Subject Re: Thoughts on splitting out "core" from, well, products & other stuff
Date Wed, 15 Feb 2006 20:31:07 GMT
On 2/14/06, David Jencks <david_jencks@yahoo.com> wrote:
>
> On Feb 14, 2006, at 9:01 AM, Dain Sundstrom wrote:
>
> > I like the idea, but he devil is in the details.  Before we move
> > forward, I'd like to look that devil in he eyes.
>
> Indeed.  I don't understand what this would give anyone except a more
> complicated build structure.  What I think would be substantially
> more useful and not introduce any more build complexity is a
> dependency diagram so you could easily see the answer to the
> question, if I include module/configuration X what do I need to make
> it work?  Right now I think you can answer this my making an assembly
> that includes X and seeing what you get in it but a picture would be
> a lot easier to think about.
>
> Part of this is that I pretty much regard anything above the kernel
> as optional... in particular connectors, transaction manager,
> security, and naming.  We just haven't succeeded in actually making
> them optional yet.

I've been thinking about this and I see quite a lot of value in this effort.

Right now creating custom assemblies is pretty painful. There's a lot
of extra pieces that users must deal with prior to ever getting their
own custom GBeans and configs for them into the assembly. For example,
users need to be concerned with all the modules that we consider core
to the server (e.g., kernel, system, J2EE junk, naming, security,
etc.). Even worse is the situation where a user needs to slim down the
server into a custom assembly. Picking through

This could be simplified if these modules were wrapped in a larger
configuration named core so that a user only needs to make sure that
the core config is included. This would be dramatically easier than
just showing all the working parts like we have today.

Doing something like this would require some thought. Because what
we'd really be doing is creating configs that are bundled up into each
component (component in this case being the core component, but we'd
eventually have other components like ejb, corba, etc.). And then the
assemblies would need to handle components and/or configurations. Of
course, if someone needs to modify the configs in the core component
or in the ejb component they'd need to dig into the component and
concern themself with all the pieces I'm talking about hiding away.

This would make building custom assemblies much easier because it
would mean that there are less moving parts for user to worry about.

Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

Apache Geronimo (http://geronimo.apache.org/)

Castor (http://castor.org/)

Mime
View raw message