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