[eve] builds and directory layout

[Alex Karasulu <ao...@bellsouth.net>]

Hi,

I've been giving the directory structure and the number of maven
projects in Eve a lot of thought lately.  Both Alan and Vince
(rightfully so) thought the number of projects and jars generated were
out of control.  It made it very difficult to get things settup and get
a bering so one can contribute.

I bring this up again now because the site documentation discussions are
very close at heart to these matters as well.  I'm thinking we might as
well do all this together if and when we get to it.

Right now if you look here it describes the current motives for the
directory structure and layout in the Eve subproject:

http://incubator.apache.org/directory/subprojects/eve/source-layout.html

Here's a snippet of what that looks like:

./eve               -- top component projects and subsystems
  ./frontend        -- contains frontend subsystem APIs and service projects
    ./common        -- contains shared code common to frontend subsystem
      ./api         -- API common to all projects in frontend
    ./buffer        -- frontend buffer service projects
      ./spi         -- frontend buffer service provider interface project
      ./pojo-impl   -- frontend buffer component POJO implementation project
      ./merlin-impl -- frontend buffer component Merlin implementation project
    ./event         -- frontend SEDA event dispatcher service projects
      ./spi         -- frontend event dispatcher SPI project
      ./pojo-impl   -- frontend event dispatcher POJO implementation project
      ./merlin-impl -- frontend event dispatcher Merlin wrapper impl project
      ...
  ./backend ... 

This structure is optimal if we were going to reuse these components 
all over the place and expose them as re-usable components much like
the Avalon cornerstone components.  However this is not our objective 
here at the Directory project although we don't mind making Eve itself 
a component.

What are the goals?

1). Keep it simple stupid (KISS)!
2). Minimize the learning curve and setup overhead for new commers 
    (KISS Helps)
3). Allow Eve deployment with any microkernel

#3 conflicts with both #1 and #2.  But there is a balance.  First 
we scrap the need for component level projects: meaning each component
need not have its own service provider interface maven project and pojo 
implementation maven project.  We have one eve maven project which is 
composed of the service interfaces and their default pojo 
implementations.  Next we have the various micro kernel wrappers for Eve.

So the above becomes ...

eve
  frontend
  frontend-merlin
  frontend-phoenix
  frontend-gbeans
  frontend-pico
  frontend-loom
    ...
  backend ...

In the old scheme the number of maven projects equaled:

#_of_components * ( #_of_wrappers + 2 )

Here the number of maven projects equals:

#_of_wrappers + 1

Most people can ignore the Eve wrapper projects minus the one they are 
most interested in.  So essentially their scope only applies to at most
two projects total.

What do you guys think about this approach?

Alex

Re: [eve] builds and directory layout

[Alex Karasulu <ao...@bellsouth.net>]

> This is much more a tools question that a organization question - i.e. 
> if the tools are right then its not a problem - and inverly, if the 
> tools are not thee then reorganization is a solution.

I agree it's also a way to work around classloader issues confronted by
a microkernel.

> In general I agree.  However - keep in mind that by reducing inversely 
> you reduce flexibly.  With fine-grain breakout you can easily map 
> different implementations in on-the-fly (without taking down your system).

Right dynamic reloading will eventually be a concern and #4 below is a
valid point.  However we don't know which parts of eve are going to need
this and which are not at this point.  When we get to the stage where
dymnamic loading is even on our radar screen we can follow these
tactics.  For the time being it severly limits us because of the tools
we use or don't have rather.  

So might we fall back into this layout.  Perhaps but I think the wrapper
projects are where this can be localized.  First its a nice place to
keep it because its away from the core eve code.  Secondly some
containers will be able to take advantage of this and provide hot block
swaping and others will not.  So why should we plan for all of them in
the core.  I know the Merlin kernel will evenually support hot block
swapping because of the meticulous detail to the class loading scheme. 
Others may not.  If we do have a per-component breakdown the wrapper
level is the best place for it.  WDYT?

> > What are the goals?
> > 
> > 1). Keep it simple stupid (KISS)!
> 
> +1
> 
> > 2). Minimize the learning curve and setup overhead for new commers 
> >     (KISS Helps)
> 
> +1
> 
> > 3). Allow Eve deployment with any microkernel
> 
> and (4) allow hot-block management .. i.e. natural evolution of your 
> system while maintaining a running system.  But archiving this objective 
> is in direct conflict with 1 and 2 unless your have the right tools.

Alex

Re: [eve] builds and directory layout

[Stephen McConnell <mc...@apache.org>]

Alex Karasulu wrote:

> Hi,
> 
> I've been giving the directory structure and the number of maven
> projects in Eve a lot of thought lately.  Both Alan and Vince
> (rightfully so) thought the number of projects and jars generated were
> out of control.  It made it very difficult to get things settup and get
> a bering so one can contribute.

This is much more a tools question that a organization question - i.e. 
if the tools are right then its not a problem - and inverly, if the 
tools are not thee then reorganization is a solution.

> I bring this up again now because the site documentation discussions are
> very close at heart to these matters as well.  I'm thinking we might as
> well do all this together if and when we get to it.
> 
> Right now if you look here it describes the current motives for the
> directory structure and layout in the Eve subproject:
> 
> http://incubator.apache.org/directory/subprojects/eve/source-layout.html
> 
> Here's a snippet of what that looks like:
> 
> ./eve               -- top component projects and subsystems
>   ./frontend        -- contains frontend subsystem APIs and service projects
>     ./common        -- contains shared code common to frontend subsystem
>       ./api         -- API common to all projects in frontend
>     ./buffer        -- frontend buffer service projects
>       ./spi         -- frontend buffer service provider interface project
>       ./pojo-impl   -- frontend buffer component POJO implementation project
>       ./merlin-impl -- frontend buffer component Merlin implementation project
>     ./event         -- frontend SEDA event dispatcher service projects
>       ./spi         -- frontend event dispatcher SPI project
>       ./pojo-impl   -- frontend event dispatcher POJO implementation project
>       ./merlin-impl -- frontend event dispatcher Merlin wrapper impl project
>       ...
>   ./backend ... 
> 
> This structure is optimal if we were going to reuse these components 
> all over the place and expose them as re-usable components much like
> the Avalon cornerstone components.  However this is not our objective 
> here at the Directory project although we don't mind making Eve itself 
> a component.

In general I agree.  However - keep in mind that by reducing inversely 
you reduce flexibly.  With fine-grain breakout you can easily map 
different implementations in on-the-fly (without taking down your system).

> What are the goals?
> 
> 1). Keep it simple stupid (KISS)!

+1

> 2). Minimize the learning curve and setup overhead for new commers 
>     (KISS Helps)

+1

> 3). Allow Eve deployment with any microkernel

and (4) allow hot-block management .. i.e. natural evolution of your 
system while maintaining a running system.  But archiving this objective 
is in direct conflict with 1 and 2 unless your have the right tools.

> 
> #3 conflicts with both #1 and #2.  But there is a balance.  First 
> we scrap the need for component level projects: meaning each component
> need not have its own service provider interface maven project and pojo 
> implementation maven project.  We have one eve maven project which is 
> composed of the service interfaces and their default pojo 
> implementations.  Next we have the various micro kernel wrappers for Eve.
> 
> So the above becomes ...
> 
> eve
>   frontend
>   frontend-merlin
>   frontend-phoenix
>   frontend-gbeans
>   frontend-pico
>   frontend-loom
>     ...
>   backend ...
> 
> In the old scheme the number of maven projects equaled:
> 
> #_of_components * ( #_of_wrappers + 2 )
> 
> Here the number of maven projects equals:
> 
> #_of_wrappers + 1
> 
> Most people can ignore the Eve wrapper projects minus the one they are 
> most interested in.  So essentially their scope only applies to at most
> two projects total.
> 
> What do you guys think about this approach?

I think conceptual principal is fine.  I think that the pragmatic 
overhead of supporting multiple containers sucks big time.  A much 
better solution is to generate adapters from a well defined model and 
eliminate the concern.

Cheers, Steve.

-- 

|---------------------------------------|
| Magic by Merlin                       |
| Production by Avalon                  |
|                                       |
| http://avalon.apache.org              |
|---------------------------------------|