[merlin] cvs organization

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

[resending - this time as a reply]


The Merlin project is starting to get rather big.  While the core 
container itself is not changing so much - there is a lot of other stuff 
that is growing and the end result is that the build process for the 
core container is starting to get rather complicated.  Hence this email 
- initial thoughts about how to reorganize things.

Currently under avalon/merlin we have the following:

   activation (api, spi, impl)
   composition (api, spi, impl)
   extension (spi, impl)
   facilities (http (api, impl, listener, test))
   kernel (api, impl, cli, plugin, servlet, unit)
   logging (api, logkit (api, impl, plugins (datagram, socket)))
   platform (installer, tutorials, xdocs)

 From the above we can break out the following five sub-groups:

   merlin core technology
   merlin site and tutorial content
   merlin system extensions
   merlin packaging
   independent systems

1. Merlin Core Technologies
---------------------------

The merlin core system is made up of the composition, activation and the 
api and impl subprojects of the kernel subproject.  This collectively 
makes up the heart and sole of merlin.  It is everything that is needed 
to embed merlin into something else - but does not include any embedded 
example.

The short list of the core:

    composition api/spi/impl
    activation api/spi/impl
    kernel api/impl

Currently there is a lot of thinking going on concerning the 
relationship between the activation and composition packages.  In 
particular, there is likely to be some degree of refactoring of the 
relationship in the coming weeks to enable a completely model driven 
approach.  This will logically reposition the activation impl package as 
nothing more than a default model runtime and enable all system 
interaction to go via the model interfaces.  This in turn will make it 
easier to move forward with a reactive runtime that adapts to changes in 
the model.

Anyway, the main point here is to establish a separation of the core 
technologies from these packages that *use* the core.

2. Merlin System Extensions
---------------------------

Merlin system extensions currently fall into one of two groups:

   * facilities (system side plugins)
   * embedded solutions

The plug-in facilities currently includes an http facility which for the 
most part is providing a framework for the validation of the overall 3.3 
facilities framework.  As this moves forward I anticipate that we will 
see a much of additional facilities coming in - including jmx, remote 
adapters, alternative runtimes, etc.

The second area concerns embedded solutions - instances of a merlin 
kernel embedded in a particular environment.  Currently we have embedded 
examples for the following:

     jelly
     unit test
     cli main
     servlet

3. Merlin Site and Tutorials
----------------------------

As the title says - this covers the generated documentation and the 
tutorials.  No problems here expect perhaps on deployment in that we do 
not have a good solution for documentation linked to different versions. 
    In particular, the content related to specifications should probably 
be linked to via a version reference and maintained relative to a named 
branch.

4. Installation Packaging
------------------------

Currently this is handled by the build file building a installation zip, 
unpack, following the instructions and everything works.  However - this 
could be significantly improved with installers (a work in progress). 
This becomes increasingly important when considering the availability of 
plug-in facilities and embedding options.

5. Independent Systems
----------------------

There are two sub-projects within the merlin package that are completely 
independent of merlin.  These include the extensions package and the 
logging package.  The extensions package deals with jar file optional 
extension handler, and the logging package deals with a plug-in 
implementation neutral logging system.  With development under the 
repository package I'm rapidly getting to the point where both the 
extension and logging systems are needed at a peer-level.

General Proposal
----------------

First off - I want to propose that the logging and extension packages 
get moved up to avalon level so that they can be used by the repository 
and other packages.  Secondly, restructuring the avalon/merlin directory 
into the following:

   avalon/merlin
     /core
       /activation
       /composition
       /kernel
     /facilities
       /http
     /embeddors
       /jelly
       /unit
       /cli
       /servlet
     /site
       /xdocs
       /tutorials
     /install

Included in the proposed structure is the recommendation that we 
simplify the top-level build process to basically request the building 
of a deliverable for each major subject.  I.e. merlin build would simply 
build core, embeddors, facilities, site and install.  A project 
definition in core would be responsible for building the core - etc.

Finally - I have some additional thoughts concerning better 
synchronization between the avalon-repository environment and the merlin 
environment - in particular, how we can merge these two together (but 
that's a subject for another email).

Thoughts?

Cheers, Steve.

-- 

|------------------------------------------------|
| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
| http://avalon.apache.org/merlin                |
| http://dpml.net/merlin/distributions/latest    |
|------------------------------------------------|

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: [merlin] cvs organization

[Leo Simons <le...@apache.org>]

Stephen McConnell wrote:
> Thoughts?

maven doesn't scale very well. At some point, its not going to fit in 
memory. Like with the geronimo build. I've found myself escaping to the 
use of shell scripts several times.

-- 
cheers,

- Leo Simons

-----------------------------------------------------------------------
Weblog              -- http://leosimons.com/
IoC Component Glue  -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
  people wouldn't obey the rules."
                                                         -- Alan Bennett



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org