questions about the catalog descriptor

[Alex Karasulu <ao...@bellsouth.net>]

Steve,

 

You referred to this avalon-repository-1.1-dev.properties file as a release
catalog for a single implementation.  It contains the following:

 

#

# Catalog descriptor.

#

 

project = avalon-repository

implementation = avalon-repository:avalon-repository-impl;1.1-dev

 

#

# Implementation dependencies

#

 

artifact.0 = avalon-repository:avalon-repository-spi;1.1-dev

artifact.1 = avalon-util:avalon-util-defaults;1.0-dev

(END)

 

 

First of all if we can have multiple implementations we need to
differentiate this file based on an implementation right.  What about
keeping this file in the ${base}/avalon-repository/propertiess directory
mirroring the base name of the implementation.  So the full path would be:

 

${base}/avalon-repository/properties/avalon-repository-impl-1.1-dev.properti
es

 

Basically this is a good mechanism to associate any number of attributes
with an artifact until we start using LDAP.  We are now creating a makeshift
directory database by keying off of the artifact file's base name.  We can
do this for all jars in the directory as a consistent standard.  Now for the
release group itself we need another descriptor or properties file.  Here we
can keep the catalog information for all the artifacts in the release group.
The general strategy might be to access this group file first then drill
down.

 

Here's what I could see going into the release group file
(avalon-repository-1.1-dev.properties):

 

group = avalon-repository

api.0 = avalon-repository-api

spi.0 = avalon-repository-spi

implementation.0 = avalon-repository:avalon-file-repository-impl;1.1-dev

implementation.1 = avalon-repository:avalon-db-repository-impl;1.1-dev

 

There may be more than one api, spi and implementation within the release
group.  Multiple implementations are obvious.  Multiple API's and SPI's may
come about by a need to fragment interfaces based on functionality.  We must
account for this.  Your POM dependency work with api, spi and impl tags
would be used to generate this file.  Basically the catalog serves as an
index so we don't have to read every artifact descriptor for the group.  It
can also contain additional information for a release that applied for the
group.  

 

Then again we can embed all the info into a single descriptor: meaning take
all the artifact properties an put them into the group properties.  Probably
not a good idea.   We need to decide.  I like the idea of keeping things
separate and clean for now.  If we can find a way to host a directory
somewhere we can eventually experiment with moving these properties into it
as entry attributes.

 

Ok I need to think about this one a little more.  Just wanted to write out
and send my thoughts for now.  Any comments?

 

Alex