On Saturday 08 November 2003 08:45, Alex Karasulu wrote:
> What methods do you foresee needing? Perhaps I can add them into this
> interface and u can use an implementation of it. The first implementation
> will use properties file on the repo server to get meta data on artifacts.
Since I don't have commit rights (yet), you won't find my code in the CVS.
I had a look at the repository stuff in the sandbox, and perhaps I am not
capable of appreciating the effort to the full... :o(
My impression is that it is not very well abstracted and boiled down the the
bare essentials from the "use-case" point of view, and I feel that it is
looking too much towards a foreign repository (Maven I presume).
Here is the rough draft (Stephen, I have made quite a lot of changes since
yesterday, as my abstract is much clearer after some JDs);
First of all I have a very simple Resource defintion, extremely generic at the
moment. This is composed by the 4 interfaces below; ResourceInfo,
ReourceGroupInfo, Version and Compliance. (I am right now considering generic
Attributes on the resource as well, but have not put that in yet.)
I then have a RepositoryAgent interface, which knows how to communicate with a
particular repository type, to retrieve the resource metainfo and the
resource itself. One RepositoryAgent instance per actual repository.
Since the RepositoryAgent can be of different types (such as Maven, Niclas,
Alex, HyperDuper, etc) I need a factory class for each RepositoryAgent type,
simply called RepositoryAgentFactory.
The RepositoryAgentFactory is registered with the RepositoryTypeRegistry. For
each URN type, the implementation registers (somehow) with the
RepositoryTypeRegistry (now an interface, and would need to get instantiated
as well somehow).
A repository has (from my POV) the form like;
urn:[type]:[location]
for instance,
urn:plain-url:file:///opt/avalon/repository/
To use this, as client, you do
String urn = urn:plain-url:file:///opt/avalon/repository/;
RepositoryTypeRegistry reg = ... // Some way to find the registry.
RepositoryAgentFactory factory = reg.getRepositoryAgentFactory( urn );
RepositoryAgent agent = factory.create( urn );
// load root resource group ("").
ResourceInfo[] infos = agent.loadResourceInfo( "" );
for( int i=0 ; i < infos.length ; i++ )
{
String name = infos[i].getName();
String descr = infos[i].getDescription();
:
InputStream in = agent.openInputStream( infos[i] );
:
}
(It is arguable if the openInputStream() should be within the ResourceInfo
instead, but I think that by putting it in the agent, the ResourceInfo
implementation can possibly be very generic, and not re-implemented for each
repository type.)
And so on...
ResourceGroup is an interesting concept, that I have promoted to first class
citizens over the day. It is a type of Resource that can contains other
Resources. That means that
"MyComponent" is a ResourceGroup, where as
"MyComponent Ver 1.0.0" is a "leaf" Resource.
One could possibly even imagine that
"MyComponent-1.0.0.jar" is a ResourceGroup containing other resources
internally.
And I can also categorize my resources in any imaginable way.
To me this design looks pretty solid and well abstracted, and it should be
possible;
1. Provide implementations (RepositoryAgent + RepositoryAgentFactory) for just
about any remote or local repository or some form of library.
2. Specialize the functionality for more Avalon specific stuff on top of it.
Also, I have introduced listeners on RepositoryTypeRegistry,
RepositoryAgentFactory and RepositoryAgent, which are notified about any
changes loaded or detected. This will drive a UI, for instance, very well.
What do you think?
"This doesn't belong in Avalon!" - Yes, this has struck me too, but let's
iron it out here before we decide what to do with it.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
