Do you see the virtual repository as a replacement for all such get
requests, or an additional feature?
I agree with the need for it, I just think we should have both GET (r/
o) per repo, WebDAV (r/w) per repo, and virtual repos (r/o), so it's
a separate feature (and separate discussion :).
I'm most keen on figuring out the URL structure for the get/webdav
since IMO those originally proposed are not friendly enough as a
default.
Cheers,
Brett
On 11/07/2007, at 4:53 PM, Arnaud HERITIER wrote:
I agree that it's not a problem to have different urls to get
artifacts and to upload them. Settings for those two operations are
differents in maven (1&2) thus it doesn't save some lines of settings
if we have the same.
The more important is to provide a mechanism to separate physical
(managed) repositories and developers end-points urls.
In a corporate environment (for example) we often want to have several
physical repositories to have different rules for backup, snapshots
cleaning, ... :
- inhouse repos for releases and snapshots
- 3rd party editors
- external repos proxy
And all of those data have to be accessed or uploaded from maven 1
or 2.
From the developer point of view, this one just need to have a repo
which tries to resolves itself artifacts from a given list of physical
repository (it's important when you have a slow network, you don't
want to do too many requests to the server).
Thus, I think that we have to propose upload settings for each managed
repo, but we have to add a feature to create a virtual repository url
that we can configure to search artifacts on a list of managed and
proxy repos.
Arnaud
On 11/07/07, Brett Porter <[EMAIL PROTECTED]> wrote:
What does everyone think about this?
On 04/07/2007, at 11:28 AM, Brett Porter wrote:
> So, last time this topic came up, there was disagreement on the /
> get/ interface.
>
> Regarding using /get/ instead of just /repository/ URL as is, I
> said (<[EMAIL PROTECTED]>)...
> "Ok, while I'd definitely prefer to make it work, if it can't then
> I'd prefer we made the change in the other direction (the default
> repository URL is get only, we have /repository-id/webdav/ as the
> webdav exposure point)."
> to which Nicolas agreed.
>
> We then diverged into discussing auto-discovery of the getId from
> the path which there were technical reasons to not do.
>
> However, I do not want all repositories to look like /archiva/
> repository/releases/get/maven2/. Yikes.
>
> Cheers,
> Brett
>
> On 04/07/2007, at 12:32 AM, Joakim Erdfelt wrote:
>
>> Design.
>>
>> 1) Create DynamicGetServlet which parses ....
>> /get/${getId}/${getResource}
>> 2) Create Maven1GetProvider which has an id "maven1", and serves
>> artifacts / poms to it.
>> 3) Create Maven2GetProvider which has an id "maven2", and serves
>> artifacts / poms / metadata to it.
>> 4) Test
>> 5) Done.
>>
>> - Joakim
>>
>> Brett Porter wrote:
>>> Sounds good. With the M1 client support, can you post a small
>>> design proposal first since last I remember we didn't reach
>>> consensus on how it should be implemented?
>>>
>>> - Brett
>>>
>>> On 03/07/2007, at 8:15 AM, Joakim Erdfelt wrote:
>>>
>>>> I agree.
>>>>
>>>> I view 1.0-beta-1 as feature complete.
>>>>
>>>> The current missing features ...
>>>> * Reporting (about 80% there right now, just some UI pieces left
>>>> to hook up)
>>>> * Maven 1 Client Support (about 40% complete. need to hook up
>>>> DynamicGetServlet)
>>>> * Live documentation. (present in archiva.war)
>>>>
>>>> - Joakim
>>>>
>>>> Brett Porter wrote:
>>>>>
>>>>> On 03/07/2007, at 3:28 AM, Wendy Smoak wrote:
>>>>>
>>>>>> Archiva 1.0-alpha-2 is out in the wild... what's next? 1.0-
>>>>>> beta-1
>>>>>> seems reasonable, but /topic in #archiva says "coming soon,
the
>>>>>> Archiva 1.0 (the "Ship It" release)".
>>>>>
>>>>> I was kidding (but that should be the focus from now on. Get it
>>>>> done.) I agree 1.0-beta-1 is next - it should be feature
complete.
>>>>>
>>>>>> - Brett
>>>>>
>>>>
>>>>
>>>> --
>>>> - Joakim Erdfelt
>>>> [EMAIL PROTECTED]
>>>> Open Source Software (OSS) Developer
>>>
>>
>>
>> --
>> - Joakim Erdfelt
>> [EMAIL PROTECTED]
>> Open Source Software (OSS) Developer
--
..........................................................
Arnaud HERITIER
..........................................................
OCTO Technology - [EMAIL PROTECTED]
www.octo.com | blog.octo.com
..........................................................
ASF - [EMAIL PROTECTED]
www.apache.org | maven.apache.org
...........................................................
