On 1 Sep 07, at 5:43 AM 1 Sep 07, Nigel Magnay wrote:
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
In practice from experience I know that this doesn't often work very
well as multi-cast is often suppressed on corporate networks, and
multi-case DNS doesn't really work well across subnets. What does
work well is DNSSD as you just need to make the DNS server browse-
able, push SRV records into the system and then any tooling can find
your configuration mechanism. This works very well, but so does just
checking in a copy of Maven that a team uses and sharing the m2_home/
conf/settings.xml. But the DNSSD is very handy but we had to hack up
the existing implementations to make it work probably.
For this proposal I think it boils down to the ephemeral versus non.
I think there is an easier way to do what is proposed.
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]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
