> 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
Could you be more specific pointing to the classes/interfaces.
I know it has a long way to go.
> 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).
Yes it does look towards using a foreign repository that uses Maven's layout ATM ;).
> 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.)
Could you send me a copy of the interfaces?
> 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.
Actually the Repository really is an agent that works on behalf of
the user. The Repository does not represent the remote repository
but the functional unit that interfaces with it. I would tend to
agree with you on the Agent notion here it fits.
> 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.
Right the RepositoryFactory/Repository is synonymous I think.
>
> 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 );
I'm embarrassed to admit that I have never used this urn concept before.
What other [type] fields exist?
>
> // 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] );
> :
> }
>
You're going to need a repo with a database for this. Pulling all this
info as artifacts from a large repo like the ibiblio one could be a massive
undertaking taking on the order of seconds to pull every descriptor
artifcat. Just thinking to myself here. I don't know if you're privy to
it but I'm very bent towards enabling the conventional (maven) repo with
a queriable interface. This way we can ask complex questions about the
artifacts (Resources) contained therein.
> (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.)
Right keep the content access mechanism separate from the data.
ResourceInfo sounds like a simple bean to me analogous to the
ArtifactDescriptor bean in the sandbox now.
> 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.
Awesome you're getting into resource composition and heirarchy is
creeping into the picture. I like the resource nesting principal
by association using groups. It may be a logical resourse (artifact)
rather than a physical one and the containment can nest indefiniately.
> 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.
Right but you want to avoid the jar in a jar concept. If you model
you grouping based on a physical mechanism then you limit yourself
to particular artifact types that support physical containment.
>
> To me this design looks pretty solid and well abstracted, and it should be
> possible;
Perhaps if we take the time to point out the faults in the CVS code
we can agree on a direction and march together.
> 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.
Like the way infobus works I guess. But the RespositoryAgent also needs
to get notification from the remote repository no? You can do this with
LDAP asynchronous notifaction if a LDAP/Http based repo was built for the
relational/content access respectively.
> What do you think?
I generally tend to agree with you but I don't think we're that far
off in our points of view. I think getting to a common ground is
very easy if we commit the time and patience to it. We'll be better
off considering the other POV for it and we always need someone or
two to bounce ideas off of who are intimate with the code.
> "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.
Yes I think the entire ASF is discussing that on the [EMAIL PROTECTED]
list at the present moment including the folks on the incubator list. It's
a horizontal concept that is relavent across several projects and I think it
should be centralized for the entire ASF somewhere. Then we can build on
it for our needs however I feel very strongly about makeing the remote
repository a directory for relational queries as well as a webserver for
artifact content download.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
