Thoughts on splitting out "core" from, well, products & other stuff

[Aaron Mulder <am...@alumni.princeton.edu>]

What would folks think of (in principle, not right now) splitting out
the core Geronimo components from anything that wraps a 3rd-party
product/project?  So have one area for modules like kernel, security,
core, system, etc. and a separate area for modules like Jetty, Tomcat,
ActiveMQ, Directory, jUDDI, etc.  I guess mainly to draw the
distinction between what's really part of the infrastructure and
what's really "optional packages" that can be added on top (and I'm
talking about "optional" in a non-J2EE-server sense where you start
with literally nothing but the infrastructure and add only waht you
want, or something like that).  So we'd still pull a lot of that in
for our "J2EE" builds, but it would make a clearer distinction for
anyone who wanted a more custom build.

Thanks,
    Aaron

Re: Thoughts on splitting out "core" from, well, products & other stuff

[Sachin Patel <sp...@gmail.com>]

+1

- sachin



On Feb 13, 2006, at 10:15 PM, Aaron Mulder wrote:

> What would folks think of (in principle, not right now) splitting out
> the core Geronimo components from anything that wraps a 3rd-party
> product/project?  So have one area for modules like kernel, security,
> core, system, etc. and a separate area for modules like Jetty, Tomcat,
> ActiveMQ, Directory, jUDDI, etc.  I guess mainly to draw the
> distinction between what's really part of the infrastructure and
> what's really "optional packages" that can be added on top (and I'm
> talking about "optional" in a non-J2EE-server sense where you start
> with literally nothing but the infrastructure and add only waht you
> want, or something like that).  So we'd still pull a lot of that in
> for our "J2EE" builds, but it would make a clearer distinction for
> anyone who wanted a more custom build.
>
> Thanks,
>     Aaron

Re: Thoughts on splitting out "core" from, well, products & other stuff

[David Blevins <da...@visi.com>]

On Feb 13, 2006, at 7:15 PM, Aaron Mulder wrote:

> What would folks think of (in principle, not right now) splitting out
> the core Geronimo components from anything that wraps a 3rd-party
> product/project?  So have one area for modules like kernel, security,
> core, system, etc. and a separate area for modules like Jetty, Tomcat,
> ActiveMQ, Directory, jUDDI, etc.  I guess mainly to draw the
> distinction between what's really part of the infrastructure and
> what's really "optional packages" that can be added on top (and I'm
> talking about "optional" in a non-J2EE-server sense where you start
> with literally nothing but the infrastructure and add only waht you
> want, or something like that).  So we'd still pull a lot of that in
> for our "J2EE" builds, but it would make a clearer distinction for
> anyone who wanted a more custom build.
>

I've got the current openejb 3 tree setup somewhat like this and it's  
really nice.  Makes it really easy to say, things in this area cannot  
depend on things in that area.. and so on.

Otherwise things tend to spider together and become coupled.

Obviously the "devil is in the details" as Dain says.

-David

Re: Thoughts on splitting out "core" from, well, products & other stuff

["Alan D. Cabrera" <li...@toolazydogs.com>]

On 2/13/2006 7:15 PM, Aaron Mulder wrote:

>What would folks think of (in principle, not right now) splitting out
>the core Geronimo components from anything that wraps a 3rd-party
>product/project?  So have one area for modules like kernel, security,
>core, system, etc. and a separate area for modules like Jetty, Tomcat,
>ActiveMQ, Directory, jUDDI, etc.  I guess mainly to draw the
>distinction between what's really part of the infrastructure and
>what's really "optional packages" that can be added on top (and I'm
>talking about "optional" in a non-J2EE-server sense where you start
>with literally nothing but the infrastructure and add only waht you
>want, or something like that).  So we'd still pull a lot of that in
>for our "J2EE" builds, but it would make a clearer distinction for
>anyone who wanted a more custom build.
>  
>

I am shocked that this is not going into a patch release.  ;)

Sounds cool to me.


Regards,
Alan

Re: Thoughts on splitting out "core" from, well, products & other stuff

[Bruce Snyder <br...@gmail.com>]

On 2/13/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> What would folks think of (in principle, not right now) splitting out
> the core Geronimo components from anything that wraps a 3rd-party
> product/project?  So have one area for modules like kernel, security,
> core, system, etc. and a separate area for modules like Jetty, Tomcat,
> ActiveMQ, Directory, jUDDI, etc.  I guess mainly to draw the
> distinction between what's really part of the infrastructure and
> what's really "optional packages" that can be added on top (and I'm
> talking about "optional" in a non-J2EE-server sense where you start
> with literally nothing but the infrastructure and add only waht you
> want, or something like that).  So we'd still pull a lot of that in
> for our "J2EE" builds, but it would make a clearer distinction for
> anyone who wanted a more custom build.

And 1.1 continues to grow even bigger ;-).

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/)

Re: Thoughts on splitting out "core" from, well, products & other stuff

[Bruce Snyder <br...@gmail.com>]

On 2/14/06, David Jencks <da...@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/)

Re: Thoughts on splitting out "core" from, well, products & other stuff

[David Jencks <da...@yahoo.com>]

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.

thanks
david jencks

>
> -dain
>
> On Feb 13, 2006, at 7:15 PM, Aaron Mulder wrote:
>
>> What would folks think of (in principle, not right now) splitting out
>> the core Geronimo components from anything that wraps a 3rd-party
>> product/project?  So have one area for modules like kernel, security,
>> core, system, etc. and a separate area for modules like Jetty,  
>> Tomcat,
>> ActiveMQ, Directory, jUDDI, etc.  I guess mainly to draw the
>> distinction between what's really part of the infrastructure and
>> what's really "optional packages" that can be added on top (and I'm
>> talking about "optional" in a non-J2EE-server sense where you start
>> with literally nothing but the infrastructure and add only waht you
>> want, or something like that).  So we'd still pull a lot of that in
>> for our "J2EE" builds, but it would make a clearer distinction for
>> anyone who wanted a more custom build.
>>
>> Thanks,
>>     Aaron
>

Re: Thoughts on splitting out "core" from, well, products & other stuff

[Dain Sundstrom <da...@iq80.com>]

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.

-dain

On Feb 13, 2006, at 7:15 PM, Aaron Mulder wrote:

> What would folks think of (in principle, not right now) splitting out
> the core Geronimo components from anything that wraps a 3rd-party
> product/project?  So have one area for modules like kernel, security,
> core, system, etc. and a separate area for modules like Jetty, Tomcat,
> ActiveMQ, Directory, jUDDI, etc.  I guess mainly to draw the
> distinction between what's really part of the infrastructure and
> what's really "optional packages" that can be added on top (and I'm
> talking about "optional" in a non-J2EE-server sense where you start
> with literally nothing but the infrastructure and add only waht you
> want, or something like that).  So we'd still pull a lot of that in
> for our "J2EE" builds, but it would make a clearer distinction for
> anyone who wanted a more custom build.
>
> Thanks,
>     Aaron

Re: Thoughts on splitting out "core" from, well, products & other stuff

[Rajith Attapattu <ra...@gmail.com>]

Nice idea !! , especially considering all the things we are putting inside
Geronimo and the list keeps growing.

If there is a way to do a build with only what you want in a less painful
way then it's great !!!

Thanks,

Rajith


On 2/13/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
>
> What would folks think of (in principle, not right now) splitting out
> the core Geronimo components from anything that wraps a 3rd-party
> product/project?  So have one area for modules like kernel, security,
> core, system, etc. and a separate area for modules like Jetty, Tomcat,
> ActiveMQ, Directory, jUDDI, etc.  I guess mainly to draw the
> distinction between what's really part of the infrastructure and
> what's really "optional packages" that can be added on top (and I'm
> talking about "optional" in a non-J2EE-server sense where you start
> with literally nothing but the infrastructure and add only waht you
> want, or something like that).  So we'd still pull a lot of that in
> for our "J2EE" builds, but it would make a clearer distinction for
> anyone who wanted a more custom build.
>
> Thanks,
>    Aaron
>