Nicola Ken Barozzi wrote:

Stephen McConnell wrote: ...

Big picture news from the Avalon front is a decision to move to a single specification, single container, single architecture. As part of that picture the Avalon Repository package is an important sub-system. What remains open or at least foggy is where the overlap is between the work here and the activities in Avalon.

My assumptions:

  1. A lot of the internal low-level code in the Avalon Repository
     package could be replaced by content from this project.


Good.

  2. Higher level functions such as classloader construction and
     factory management should probably stay in Avalon.


Why? If they are Avalon specific, I agree, if not, and part of it surely is indipendent, there is no reason why they cannot move here under their own subsystem.

The content is not Avalon Specific - so, yes, in principal we could think about moving the entire project here. The current release is a 1.2. The CVS HEAD is targeting a 2.0 release to coincide with a Merlin 3.3 release that will be coming up soon.


If we move Avalon Repository here - there are some questions:

  1. Its the functionality it provides considered to be within
     the scope of this project - in particular:

       - artifact caching (yes)
       - classloader building (maybe)
       - automated factory and criteria management (maybe)
       - repository tools (yes)

     Basically the repository package is a fundamental building
     blocks that is used across a bunch of avalon systems.  It
     provides the bootstrapping framework for merlin (i.e. the
     core of the repository package builds a classloader and
     instantiates a full repository package impl handler, which
     in turn is used to build a classloader, instantiate and
     parameterize a factory for merlin, which in turn uses the
     repository to load and instantiate logging systems, container
     runtime environments, etc., etc.

     Concerning the Avalon road map for the repository package
     there are two main items on the agenda.  Firstly the extension
     of the factory metadata to include dependent systems (i.e. have
     the repository implementation handle the preloading of dependent
     systems which in turn are used in the parameterization of
     factories).

     Secondly - thee is the issues concerning the management of java
     optional jar extensions.  This is currently handled internally
     within the merlin container - however - the correct solution is
     to move optional extension loading out of merlin and into the
     repository classloader builder.

  2. how to manage flexibility

     As described above - the Avalon Repository platform is intrinsic
     element of several avalon facilities.  On one hand we don't want
     to break existing avalon content but on the other hand locking
     Depot down on a particular API does not sound like fun!  So perhaps
     the right approach is for Avalon to finalize 2.0 and get this out
     in line with the Merlin 3.3 release, and from there we either:

       (a) bite the bullet and move it over here and start
           pulling things together ASAP

       (b) progressively replace implementation content with
           Depot content lading to the ultimate transfer of
           the entire repository package at a later date

  3. exiting incubator

     Impressions and time line for exiting incubation are IMO an
     important aspect here.  So long as Depot is under incubation then
     we have a catch 22 - Avalon cannot use incubated content in its
     releases.  There are a number of ways we can deal with this but
     they all smell like procedural workarounds.  Clearing this off
     the agenda would eliminate the main stumbling block that I see.

I see a big duplication of functionality that can be brought in Depot.
We have an artifact called version that does advanced version resolution. One AKA Ruper and now named Updater that gets artifacts from a repository (local or remote) using version and it's resolution system.

I'm digging into version and update now to get a better idea of where things fit/etc.


I think it's time to merge efforts :-)

Yep.

Cheers, Stephen.

--

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

Reply via email to