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 (ibiblio.com)
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 | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
