Stephen McConnell wrote: ...
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)
+1
- classloader building (maybe)
IMHO yes as classloading is artifact loading, and we manage artifacts (in this case inside the VM)
- automated factory and criteria management (maybe)
please expand on this
- repository tools (yes)
+1
Basically the repository package is a fundamental building
blocks that is used across a bunch of avalon systems.
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.
Sorry but I don't get the above. I'm not accustomed to most of the terminology used above, could you please clarify?
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
I think that (b) is the best thing to do. Going in small reversible steps seems slower but favors stability.
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.
If Avalon Repository decides to use Depot, after the 2.0 release of Avalon Repository we can start using depot as a backend, and contextually exit incubation. What we still lack a bit is community, but if Avalon uses Depot we should be ok with it.
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.
Good :-)
Things are in no way set in stone, so changes can be easily made. The idea is that he packages are as focused as possible. So the Avalon Repository extra parts would be additional packages giving extra functionality on top of the other packages.
I think it's time to merge efforts :-)
Yep.
:-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
