Ok give me a little while to read my email and this one a couple times more. I'll get
back to you soon.
>
> From: Niclas Hedhman <[EMAIL PROTECTED]>
> Date: 2003/11/08 Sat AM 07:21:03 EST
> To: "Avalon Developers List" <[EMAIL PROTECTED]>
> Subject: Re: Eclipse Plug-in
>
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
