[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
servlet3. 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
/installIncluded 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
