On 11/07/07, Brett Porter <[EMAIL PROTECTED]> wrote:
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 think that the GET by repo could be the default setting. When you
create a managed repo, you have a GET access to it. But you can also
add another access accross several repos.
It could be considered as a new feature
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
> ...........................................................
--
..........................................................
Arnaud HERITIER
..........................................................
OCTO Technology - [EMAIL PROTECTED]
www.octo.com | blog.octo.com
..........................................................
ASF - [EMAIL PROTECTED]
www.apache.org | maven.apache.org
...........................................................
