maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nigel Magnay" <nigel.mag...@gmail.com>
Subject Re: [PROPOSAL] Local Repository Separation
Date Sat, 01 Sep 2007 16:59:39 GMT
I guess ymmv, but I've never had zeroconf not work in development
environments (we use the log4j zeroconf extensions all the time). Some
services deliberately set hopcounts low if they're providing something
particularly localized.

Anyway - I wouldn't suggest it as the only mechanism (and it's something you
could do as in a mojo), just something that becomes easier if you don't have
inconsistent repository IDs.

On 01/09/07, Jason van Zyl <jason@maven.org> wrote:
>
>
> 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 <stephenconnolly@one-dash.com> wrote:
> >>
> >> Jerome Lacoste wrote:
> >>> On 8/31/07, Brett Porter <brett@apache.org> 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: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
> >> 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: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder and PMC Chair, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message