incubator-depot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <>
Subject Re: News from the Avalon front?
Date Thu, 18 Mar 2004 11:29:46 GMT
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

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


Cheers, Stephen.


| Magic by Merlin                                |
| Production by Avalon                           |
|                                                |
|                |
|    |

View raw message