A couple of really neat features, regardless of whether guids or some other identifying mechanism is used, would be 1) ability to use zeroconf (/bonjour) style networking to automatically configure your mirror settings 2) for repositories themselves to contain a bit more metadata about the repository itself - what it does and doesn't contain for example. In one of our large builds, we have quite a lot of repositories, and the daily 'ask every repo if it has a new SNAPSHOT' was sped up considerably by configuring proximity to say 'no' to most paths.
On 01/09/07, Stephen Connolly <[EMAIL PROTECTED]> wrote: > > 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] > >
