Hi Adam:
First off - yes there is a lot of interest in pooling efforts in this area. I've included a brief summary of what we have in place and how we are using it. Biggest fuzzy area just at the moment is understanding where interests overlap. My general hunch is that the Avalon Repository stuff is focused on a higher level of abstraction than Depot and the missing ingredient right now is understanding where Depot and Avalon Repository connect.
Here is the quick overview of Avalon Repository:
|------------------------------------------------------| | App Builder | | (parameterized construction of | | new instances using a factory/criteria | | pattern) | |------------------------------------------------------| | ClassLoader Builder | | (creation of classloader hierarchies using | | meta data generated with tagged project | | descriptors - with support for api, spi and | | impl classloader stages) | |------------------------------------------------------| | Repository | | (local cache of artifacts and general artifact | | retrieval relative to remote hosts - were a remote | | can be accessed by http or file urls) | |------------------------------------------------------|
Main usage of the repository package in avalon is with respect to plugin loading. For example in the merlin application the system creates a logging system from an initial artifact reference:
artifact:avalon-logging/avalon-logkit-impl?version=1.0-SNAPSHOT
This string is resolved to an Artifact reference which basically translates to:
[host]/avalon-logging/jars/avalon-logkit-impl-1.0-SNAPSHOT.jar
The classloader service looks for a repository resource containing the meta data for a classloader definition. This is located using the above url appended with the .meta mime type.
avalon-logkit-impl-1.0-SNAPSHOT.jar.meta
This contains the description of the api, spi and impl classloader entries. A classloader is typically constructed by the app builder and this is either handled automatically as a Factory, or in an application specific fashion. In the above example its a factory and merlin simply requests from the factory an instance and get back a ready to run LoggingManager. This pattern is repeated inside the logging system - for example - custom log target factories can be loaded in the same way. In the Merlin system the same approach is used by the CLI loader to load merlin, the merlin system then uses the same approach to load the active runtime, and runtime can use system to load internal subsystems.
Looking forward, the next big step is providing intelligent back-end support so that we are doing much more interesting requests to the remote repository and getting back much more interesting (and dynamically constructed) artifacts.
Cheers, Steve.
Adam R. B. Jack wrote:
Hi,
I suspect folks here recall that the Depot project in Incubator (spawned from Ruper/Version out @ Krysalis) wants to provide tools for Repositories. When Depot was create it was intended that we'd invite Avalon developers in, because interest was expressed in this on the repo@ list. [I'll find the archived threads if folks wish.]
Well, we are still open to that -- if anything makes sense -- we are basically just getting our stuff together. If Avalon folks working here makes more sense, then great -- no pressure, no objections, I just wanted to ensure that folks knew the offer was open.
We've not failed to ask for any reason other than not having much to offer you, and not being ready...
regards,
Adam
----- Original Message ----- From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, February 12, 2004 1:55 PM
Subject: [jira] Created: (AREPO-3) Repository Verification Tool
Message:
A new issue has been created in JIRA.
--------------------------------------------------------------------- View the issue: http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=AREPO-3
Here is an overview of the issue: --------------------------------------------------------------------- Key: AREPO-3 Summary: Repository Verification Tool Type: New Feature
Status: Open Priority: Major
Project: Avalon Repository Components: Implementation Fix Fors: 1.3 Versions: 1.3 1.2
Assignee: Stephen McConnell Reporter: Stephen McConnell
Created: Thu, 12 Feb 2004 12:54 PM Updated: Thu, 12 Feb 2004 12:54 PM
Description: Requirement for tools that check integrity of repository content. Tool
support would cover assessment of the file integrity (MD5), authenticity (ASC and signed jars), and equality with remote repository content.
--------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
