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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
