Jerome Lacoste wrote:
On 8/31/07, Brett Porter <[EMAIL PROTECTED]> wrote:
Yeah, I meant to note that - I was thinking that this should be
accompanied by a proposal to take care of the id ambiguity problems
which we've discussed a couple of times before.

I think URLs are still problematic (since you can often have
different ones for the same location), though are a bit more robust
than IDs. We could hash them to generate the directory name in the
repository.

What do others think?

How are workspaces identified ? a hash of the current directory ?
Something related to the project one is working on ? Something related
to the current process ?

Cheers,

Jerome

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Would a better option be to have the repositories store a identifying GUID in their root URL. That way mirrors would pick up the same GUID and be identified as the same repository.

Of course then there's the question, should an aggregating mirror return the GUIDs of all the repositories it aggregates or a unique hash.

My feeling is it should return a unique hash, but maybe it could return information about it aggregating other repositories...

thus:

The repository-id.xml for an aggregate repository could be something like

<repository-id>
 <name>ACME Corp's Aggregated Proxy Repository</name>
 <id>1234-663a-7766-aabbef45-3244</id>
 <aggregate-repositories>
   <id>7688-364a-a7f6-1234567-f56e</id>
   <id>bcd3-5432-8899-9876543-acbd</id>
 </aggregate-repositories>
</repository-id>

While repo1.maven.org could be:

<repository-id>
 <name>Maven Central Repository</name>
 <id>7688-364a-a7f6-1234567-f56e</id>
</repository-id>

And, say java.net2 (http://download.dev.java.net/maven/2) could be

<repository-id>
 <name>Java.net's Maven2 Repository</name>
 <id>bcd3-5432-8899-9876543-acbd</id>
</repository-id>

The advantage I see is that existing clients will not be looking for the repository-id.xml file, so they won't care. If we can't find a repository-id.xml file for the repository, we generate a GUID on the client and store a mapping of URLs to GUIDs in a file in ~/.m2/ so that a user can control the mapping of these autogenerated GUIDs

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to