What is an ArtifactDatabase?

[ao...@bellsouth.net]

Guys,

ANSWER: I don't know yet but time will tell.

All I want to do is be able to read and query a repository full of artifacts based on the attributes of those artifacts.  Right now I created this little interface in the sandbox's repository project to experiment and play.

This interface for the time being has a single method whose signature is below:

    Attributes getArtifactAttributes( ArtifactDescriptor a_descriptor ) 
        throws RepositoryException ;

You give it a descriptor (group id, name, type, version) and it gives you back a javax.naming.directory.Attributes object.  I created a simple intermediate ArtifactDatabase implementation for the time being.  

WARNING: have not tested it yet! 

This simple implementation is designed to pull down a properties file from a remote repository without needing a Repository instance itself.  It presumes that a properties file artifact exists within the repo for every artifact with a '.properties' appended to the full name of the artifact.

NOTE: '.properties' is appended after the extention or type of the artifact.  So a avalon-repository-api-1.1-dev.jar will have a avalon-repository-api-1.1-dev.jar.properties file within the 'propertiess' (note the double 's' at the end) directory under the artifact group directory.

Presently I'm toying with what I need in it and possibly devising an extra artifact group catelog for the repository.

Why return an javax.naming.directory.Attributes object instead of a Properties object?

First Attributes are better for handing potentially multi-valued objects.  Secondly Attributes will allow me to use LDAP or another JNDI accessible directory to backend these attributes.  Today we can use properties files without violating the repository layout defined by Maven.  Ultimately we may even be able to roll this stuff back into maven so it becomes directory aware.  

When we switch to a formal directory for more advanced functionality we can just swap out the implementation for these interfaces to read the attributes form the directory rather than property file artifacts.  The switch will just mean much faster performance and more robust features.  You still use http for the content download but you use LDAP for the database queries.

This current path I have chosen seems to keep us in line with the present day setup of Avalon Merlin, and Maven.  It also keeps us set for the future.  

Now with a generalized queriable database for artifact attributes we have the freedom to define application specific attributes.  Avalon based attributes dealing with components and containers can blossom from this general functionality.  Integration with Maven could make for a richer plugin development environment where build, and deployment aspects are concerned.  The potential is vast and only limited by the minds of those using the feature: like meta.

Comments? Thoughts?

Alex
  







---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org