avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Eclipse Plug-in
Date Sat, 08 Nov 2003 12:21:03 GMT
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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message