You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jerome Lacoste <je...@gmail.com> on 2007/09/01 07:18:23 UTC
Re: [PROPOSAL] Local Repository Separation
On 8/31/07, Brett Porter <br...@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
Re: [PROPOSAL] Local Repository Separation
Posted by Andrew Williams <an...@handyande.co.uk>.
It will most likely work in small development environments.
What jason is saying is that it is not so likely to in corporate
environments with more than one subnet.
Andy
On 1 Sep 2007, at 17:59, Nigel Magnay wrote:
> 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 <ja...@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 <st...@one-dash.com> wrote:
>>>>
>>>> Jerome Lacoste wrote:
>>>>> On 8/31/07, Brett Porter <br...@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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [PROPOSAL] Local Repository Separation
Posted by Nigel Magnay <ni...@gmail.com>.
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 <ja...@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 <st...@one-dash.com> wrote:
> >>
> >> Jerome Lacoste wrote:
> >>> On 8/31/07, Brett Porter <br...@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
>
>
Re: [PROPOSAL] Local Repository Separation
Posted by Jason van Zyl <ja...@maven.org>.
On 2 Sep 07, at 6:35 PM 2 Sep 07, Brett Porter wrote:
>
> On 02/09/2007, at 11:37 PM, Brian E. Fox wrote:
>
>>> I know its another directory, but the following might be more
>>> straightforward:
>>
>>> .
>>> |-- metadata
>>> | |-- apache.snapshots
>>> | |-- central
>>> | |-- codehaus.snapshots
>>> | `-- ...
>>> |-- release-cache
>>> |-- snapshot-cache
>>> `-- workspace
>>> |-- default
>>> |-- workspace1
>>> `-- ...
>>
>> I'm not sure why the metadata should be separate, but I can see the
>> release-cache, snapshot-cache and workspaces being useful. I like
>> this
>> suggestion better than the original. The locking would be nice too.
>>
>
> the metadata separation is a bit of a toss up for me - it would
> have the benefit of being able to interchange a local and remote
> repository instead of the metadata format being separate. I added
> it in here as a related change because of that benefit, but it
> isn't really related to the initial requirements.
>
If we're not using repository ids, how are you going to designate the
source. If you are going to use URLs and someone changes it, how are
you going to guarantee consistency?
I don't think there's any value in separating the metadata. If you're
going to use transactions now you need two instead of one to lay down
the files.
> - Brett
>
> --
> Brett Porter - brett@apache.org
> Blog: http://www.devzuz.org/blogs/bporter/
>
> ---------------------------------------------------------------------
> 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
Re: [PROPOSAL] Local Repository Separation
Posted by Brett Porter <br...@apache.org>.
On 02/09/2007, at 11:37 PM, Brian E. Fox wrote:
>> I know its another directory, but the following might be more
>> straightforward:
>
>> .
>> |-- metadata
>> | |-- apache.snapshots
>> | |-- central
>> | |-- codehaus.snapshots
>> | `-- ...
>> |-- release-cache
>> |-- snapshot-cache
>> `-- workspace
>> |-- default
>> |-- workspace1
>> `-- ...
>
> I'm not sure why the metadata should be separate, but I can see the
> release-cache, snapshot-cache and workspaces being useful. I like this
> suggestion better than the original. The locking would be nice too.
>
the metadata separation is a bit of a toss up for me - it would have
the benefit of being able to interchange a local and remote
repository instead of the metadata format being separate. I added it
in here as a related change because of that benefit, but it isn't
really related to the initial requirements.
- Brett
--
Brett Porter - brett@apache.org
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [PROPOSAL] Local Repository Separation
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>I know its another directory, but the following might be more
>straightforward:
>.
>|-- metadata
>| |-- apache.snapshots
>| |-- central
>| |-- codehaus.snapshots
>| `-- ...
>|-- release-cache
>|-- snapshot-cache
>`-- workspace
> |-- default
> |-- workspace1
> `-- ...
I'm not sure why the metadata should be separate, but I can see the
release-cache, snapshot-cache and workspaces being useful. I like this
suggestion better than the original. The locking would be nice too.
--Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [PROPOSAL] Local Repository Separation
Posted by Brett Porter <br...@apache.org>.
On 02/09/2007, at 2:44 PM, Jason van Zyl wrote:
>
> On 1 Sep 07, at 7:04 PM 1 Sep 07, Brett Porter wrote:
>
>>
>> On 02/09/2007, at 1:33 AM, Jason van Zyl wrote:
>>
>>> 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.
>>>
>>
>> Are you talking about my proposal, or the settings zeroconf stuff?
>>
>
> I'm talking about your proposal being too complicated.
I believe this would actually simplify the current artifact handling
code since there are dodgy bits related to dealing with local
metadata. It has no effect on the user in terms of their Maven
usage. The only affect is "finding something" if they go digging
around in the local repository - which you pointed out at the end so
I'll come back to it.
> An option to use a separate local repository goes a long way and
> with a cached remote using Proximity this is not loathsome.
My local repository is currently 2.5Gb.
For every one you create, you duplicate a significant portion of that
data on the local disk, even if you avoid the network traffic by
using a proxy.
> I don't think using a shared local repository is a particularly
> bright idea.
This wasn't a proposal to facilitate sharing a local repository other
than on the same machine. It's not unheard of this even in a normal
dev machine setup. I've burned myself trying to build Maven and some
plugin at the same time.
> But creating any layered structure should be reduced for the need
> at hand. It seems to be people want to just separate between what
> their projects produce and what is fixed. Trying to break things
> down into the repository they came from isn't going to help anyone.
Is this the only part you are really objecting to, or the whole
proposal? I don't want to throw the baby out with the bathwater.
I started out with just the locking and the separation of a single
local repository, as came up on the list.
I then split the remote repositories out because I saw the
opportunity to simplify the code, make it more accurately reflect a
remote repository (they would now be identical and you could just
sync them straight down), and because it would correct some other
related bugs I saw.
I then split the local repository into workspaces as I anticipated
that was easier to deal with than swapping the entire local
repository path and having to have separate configuration for where
the cache is to share (to address a spiraling disk space usage if you
start switching local repos).
which parts do you like, and which don't you like?
> Something like telling Maven to cache by a groupId is one approach.
> Could be a project within an organization or an entire organization
> and this is probably only in the context of a build server. The
> complexity added for developers being able to shared a single local
> repository is just not worth it.
Sorry, I could really parse this. What would maven cache by group id,
and where? Do you view this as complexity in the code (which I don't
think will be the case) or for the user?
> To go from one place for the local cache to N where N is the number
> of repositories would be overwhelmingly confusing.
This seems to be the only user complexity issue you are highlighting.
I don't think users digging in their local repository is a
particularly common case, but I would rule this out as an issue on
releases downloaded by maven (they are in the cache directory) and
stuff they install (it's in the workspace they used). I can see why
it might be an issue for finding snapshots from a remote repository.
But that change is totally negotiable in the proposal, I just felt
that under the current set up the ability to use a remote repository
as a local repository and simplify the handling was worth it.
I know its another directory, but the following might be more
straightforward:
.
|-- metadata
| |-- apache.snapshots
| |-- central
| |-- codehaus.snapshots
| `-- ...
|-- release-cache
|-- snapshot-cache
`-- workspace
|-- default
|-- workspace1
`-- ...
So you have one place that caches releases, one that caches snapshots
(that can be nuked more easily), workspaces for your local
installation, and optionally the metadata separated out to make it
possible to rsync full remote repositories (since Maven could honour
jars in here, but by default just store in the cache instead).
- Brett
--
Brett Porter - brett@apache.org
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [PROPOSAL] Local Repository Separation
Posted by Jason van Zyl <ja...@maven.org>.
On 1 Sep 07, at 7:04 PM 1 Sep 07, Brett Porter wrote:
>
> On 02/09/2007, at 1:33 AM, Jason van Zyl wrote:
>
>> 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.
>>
>
> Are you talking about my proposal, or the settings zeroconf stuff?
>
I'm talking about your proposal being too complicated. An option to
use a separate local repository goes a long way and with a cached
remote using Proximity this is not loathsome. I don't think using a
shared local repository is a particularly bright idea. But creating
any layered structure should be reduced for the need at hand. It
seems to be people want to just separate between what their projects
produce and what is fixed. Trying to break things down into the
repository they came from isn't going to help anyone. Something like
telling Maven to cache by a groupId is one approach. Could be a
project within an organization or an entire organization and this is
probably only in the context of a build server. The complexity added
for developers being able to shared a single local repository is just
not worth it. To go from one place for the local cache to N where N
is the number of repositories would be overwhelmingly confusing.
> If it's for my proposal... let's hear the easier way, please.
>
> - Brett
>
> ---------------------------------------------------------------------
> 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
Re: [PROPOSAL] Local Repository Separation
Posted by Brett Porter <br...@apache.org>.
On 02/09/2007, at 1:33 AM, Jason van Zyl wrote:
> 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.
>
Are you talking about my proposal, or the settings zeroconf stuff?
If it's for my proposal... let's hear the easier way, please.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [PROPOSAL] Local Repository Separation
Posted by Jason van Zyl <ja...@maven.org>.
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 <st...@one-dash.com> wrote:
>>
>> Jerome Lacoste wrote:
>>> On 8/31/07, Brett Porter <br...@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
Re: [PROPOSAL] Local Repository Separation
Posted by Nigel Magnay <ni...@gmail.com>.
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 <st...@one-dash.com> wrote:
>
> Jerome Lacoste wrote:
> > On 8/31/07, Brett Porter <br...@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
>
>
Re: [PROPOSAL] Local Repository Separation
Posted by Brett Porter <br...@apache.org>.
On 01/09/2007, at 6:22 PM, Stephen Connolly wrote:
> 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.
Stephen - did you want to drop this into the user proposals section?
I agree we need repository GUIDs and repository metadata, but I think
it's a different thing to what I was proposing (apart from naming the
directories) so we should track it separately and include all the
settings and POM references as well.
Thanks,
Brett
>
> 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
--
Brett Porter - brett@apache.org
Blog: http://www.devzuz.org/blogs/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [PROPOSAL] Local Repository Separation
Posted by Stephen Connolly <st...@one-dash.com>.
Jerome Lacoste wrote:
> On 8/31/07, Brett Porter <br...@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