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 Sat, 20 Mar 2004 05:07:59 GMT
Markus M. May wrote:
> Hello,
> so you are storing a .meta file for each component and in this file you 
> basically describe the dependencies and some other stuff like the used 
> factory and the criterias used to initialize the factory?

Just to be clear (because component is a loaded work in Avalon) - within 
Avalon (and other Apache projects) - the Avalon Repository package is 
typically use this to load "systems" as opposed to "components".  For 
example, the Avalon Logging system provides a container side logging 
management api and uses the Avalon Repository to load the implementation 
(e.g. Log4J, LogKit, etc.).  Dig down deeper inside something like the 
LogKit implementation for Avalon Logging and you will see several 
examples of log target loading using Avalon Repository (for example an 
SMTP log target includes javamail in its classloader description).

In each case - the system implementation that is loaded has an 
associated .meta file that describes its classloading requirements and 
factory management criteria.

> Right now we are just storing the dependencies for each project 
> (component?) in an xml-file. Is the Meta-file just a .properties file or 
> could it be a .xml-file as well?

Currently the implementation is exclusively based on properties.  But 
this is largely a result of the collaboration between Avalon and the 
Directory Project in getting a small and efficient bootstrap system in 
place.  The Avalon Repository bootstrap is a 64k (or there abouts) jar 
file with no XML dependencies - which actually uses itself to load a 
repository implementation.  The repository implementation could provide 
a lot more - such as XML based "system" descriptors - but for the moment 
its doing this using properties (but I also think that XML descriptors 
is the way to go).

> Like I said, we are storing the dependencies in an .xml-file and also we 
> are using a kind of directory structure for the definition of the 
> domain, etc. Basically right now we are supporting two kinds of 
> repositories
> 1) Maven-like repos (
> 2) Flat file structure (local, ...)

Under the avalon repo stuff we don't have anything in the flat file 
space - but - there are are couple of related things.  Inside the Avalon 
Composition framework (the real component meta model) there is a bunch 
of stuff dealing with classloader management that fully supports Sun's 
optional extensions spec - and this is all XML based (ie. XML into 
management object model).  Longer term - I would like to see this 
content m oved down to the repository package.

> Here is the question, if Apache Repository decides on a different 
> structure. It is clear that we need probably more meta-data and that we 
> should use therefor another .meta file. This is not decided yet, but we 
> are pretty open on this one. Right now, nearly no information from the 
> project/component (like dependencies) are stored on the server. This 
> information is only stored in the project specific file basically on the 
> client (like maven does).
> I definitly like the idea of Avalon Repository concerning the Factory 
> loading as well as the classloading stuff.

Going beyond here is something I'm interesting in gaging.  Irrespective 
of individual opinions about Avalon - there is immutable interest in 
moving forward with back-office component technology - things like 
service registration and discovery (think intelligent server side 
repository technology).  This is intrinsically linked to the Avalon 
Repository development.

Is there an existing back-office strategy for depot? Is there interest 
in this area?

Cheers, Stephen.


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

View raw message