You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@archiva.apache.org by Wendy Smoak <ws...@gmail.com> on 2006/11/24 19:48:05 UTC
Proxy vs. Repository URLs
Consider the following managed repository:
My Managed Repository
Identifier MYREPO
Directory E:\svn\maven\archiva\archiva-webapp\target\my-managed-repository
WebDAV URL http://localhost:9091/repository/myrepo
Type Maven 2.x Repository
Snapshots Included true
Indexed true
To use it as a normal repository, the url is
http://localhost:9091/repository/myrepo
To use that same repo as a proxy, (as far as I can tell, with maxb's
help on IRC,) it's
http://localhost:9091/proxy/MYREPO
Is this correct? If so, why do we use the 'URL Name' in one place and
the 'Identifier' in another?
--
Wendy
Re: Proxy vs. Repository URLs
Posted by Max Bowsher <ma...@mxtelecom.com>.
Joakim Erdfelt wrote:
> One future feature for archiva is to manage the pom internal
> repositories to point to itself.
> In other words, if archiva is told to proxy central, and a pom gets
> pulled down pointing to a new repository of say ...
> <repository>
> <id>sf.net</id>
> <url>http://projfoo.sourceforge.net/maven2/</url>
> </repository>
>
> then archiva should replace that entry with itself so that the requests
> at the maven client continue to hit the corporate repository.
I have some doubt that such a thing would be a good idea.
First, there's the issue of whether archiva ought to be modifying the
content it serves, and how this will break checksums.
However, more importantly, this would mean that knowledge about proxy
specific URLs was being embedded into POMs in the local repository. This
would be a severe problem for laptop users who use a variety of
different profiles to vary mirror settings dependent on location. It
would also make things unnecessarily difficult for people in any
situation to cleanly and simply change their proxy configuration in any way.
Perhaps instead, this could be handled by linked improvements in maven
and archiva, allowing maven to autodiscover the list of repositories an
archiva instance is proxying, given only the base url of the archiva
instance.
Or, alternatively, a maven could operate some simple encoding scheme,
contacting archiva passing on the full upstream URL that it is
interested, and archiva could either serve it, or decline.
Either option would avoid the mirror configuration becoming entangled in
the local repository, which I think is a very important thing.
Max.
Re: Proxy vs. Repository URLs
Posted by Barrie Treloar <ba...@gmail.com>.
> One future feature for archiva is to manage the pom internal
> repositories to point to itself.
> In other words, if archiva is told to proxy central, and a pom gets
> pulled down pointing to a new repository of say ...
> <repository>
> <id>sf.net</id>
> <url>http://projfoo.sourceforge.net/maven2/</url>
> </repository>
>
> then archiva should replace that entry with itself so that the requests
> at the maven client continue to hit the corporate repository.
>
> We need to have a more sane / verbose id field, as that is what is used
> in maven client for log messages and the like.
> But having a more verbose id field for the url make no sense. hence the
> split.
This is a great example of why id or name is of no value.
Consider another project:
<repository>
<id>sf.net</id>
<url>http://another_project.sourceforge.net/maven2/</url>
</repository>
Since there can be no enforcement of the content of id/name it is too
easy to get shadowed. It is impossible to shadow the url.
The other problem is displaying information messages that include the id.
Since a repository can be defined in ANY pom in the transitive
dependency list there is no easy way for the user to find out what the
definition of "sf.net" actually points to.
This only affects people with firewalls, as it does me, because I need
to put in a security request to get the url of "sf.net" opened up as
an unauthenticated proxy. At least until either maven or archive can
support NTLM authentication (or I convince people here to ditch NTLM
and use LDAP).
Yes the information messages will be longer by pointing to URLs but it
may be better from a useability point of view.
RE: Proxy vs. Repository URLs
Posted by Pe...@ubs.com.
> -----Original Message-----
> From: Joakim Erdfelt [mailto:joakim@erdfelt.com]
> Sent: 27 November 2006 13:32
> To: archiva-users@maven.apache.org
> Subject: Re: Proxy vs. Repository URLs
>
> URL Name was introduced to make the repository snippets make sense.
>
> consider the following
>
> <repository>
> <id>snapshots</id>
> <url>http://archiva.corporate.com/repository/snapshots</url>
> </repository>
>
(1)
> vs
>
> <repository>
> <id>corporate.snapshots</id>
> <url>http://archiva.corporate.com/repository/snapshots</url>
> </repository>
>
(2)
And your point is? What is different then apart from the identifier
name? Is (1) is supposed to
better than (2) or is it vice versa?
> One future feature for archiva is to manage the pom internal
> repositories to point to itself.
> In other words, if archiva is told to proxy central, and a
> pom gets pulled down pointing to a new repository of say ...
> <repository>
> <id>sf.net</id>
> <url>http://projfoo.sourceforge.net/maven2/</url>
> </repository>
>
> then archiva should replace that entry with itself so that
> the requests at the maven client continue to hit the
> corporate repository.
>
==////==
--
Peter Pilgrim
UBS Investment Bank,
PTS Portal / IT FIRC OPS LDN,
100 Liverpool Street, London EC2M 2RH, United Kingdom
+44 (0) 20 75 75692
:: Java EE / E-Commerce / Enterprise Integration / Development ::
Visit our website at http://www.ubs.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
Re: Proxy vs. Repository URLs
Posted by Joakim Erdfelt <jo...@erdfelt.com>.
URL Name was introduced to make the repository snippets make sense.
consider the following
<repository>
<id>snapshots</id>
<url>http://archiva.corporate.com/repository/snapshots</url>
</repository>
vs
<repository>
<id>corporate.snapshots</id>
<url>http://archiva.corporate.com/repository/snapshots</url>
</repository>
One future feature for archiva is to manage the pom internal
repositories to point to itself.
In other words, if archiva is told to proxy central, and a pom gets
pulled down pointing to a new repository of say ...
<repository>
<id>sf.net</id>
<url>http://projfoo.sourceforge.net/maven2/</url>
</repository>
then archiva should replace that entry with itself so that the requests
at the maven client continue to hit the corporate repository.
We need to have a more sane / verbose id field, as that is what is used
in maven client for log messages and the like.
But having a more verbose id field for the url make no sense. hence the
split.
For the record, I don't like the /proxy/ servlet in archiva.
It has no security!!
It will be removed.
And the /repository/${urlname}/ will have the proxy abilities (with
security)
- Joakim Erdfelt
Henri Yandell wrote:
> On 11/24/06, Wendy Smoak <ws...@gmail.com> wrote:
>> Consider the following managed repository:
>>
>> My Managed Repository
>> Identifier MYREPO
>> Directory
>> E:\svn\maven\archiva\archiva-webapp\target\my-managed-repository
>> WebDAV URL http://localhost:9091/repository/myrepo
>> Type Maven 2.x Repository
>> Snapshots Included true
>> Indexed true
>>
>> To use it as a normal repository, the url is
>> http://localhost:9091/repository/myrepo
>>
>> To use that same repo as a proxy, (as far as I can tell, with maxb's
>> help on IRC,) it's
>> http://localhost:9091/proxy/MYREPO
>>
>> Is this correct? If so, why do we use the 'URL Name' in one place and
>> the 'Identifier' in another?
>
> +1 to using the identifier in both.
>
> Hen
>
Re: Proxy vs. Repository URLs
Posted by Barrie Treloar <ba...@gmail.com>.
On 11/25/06, Wendy Smoak <ws...@gmail.com> wrote:
> On 11/24/06, Henri Yandell <fl...@gmail.com> wrote:
>
> > > Is this correct? If so, why do we use the 'URL Name' in one place and
> > > the 'Identifier' in another?
> >
> > +1 to using the identifier in both.
>
> Then why have the "URL Name" at all?
Actually this was my problem with maven-proxy.
I'd prefer to drop the identifier completely.
The URL is unique and should be used as the identifier.
At least that way it stops having so many synonyms in pom files, which
is damn annoying.
Re: Proxy vs. Repository URLs
Posted by Wendy Smoak <ws...@gmail.com>.
On 11/24/06, Henri Yandell <fl...@gmail.com> wrote:
> > Is this correct? If so, why do we use the 'URL Name' in one place and
> > the 'Identifier' in another?
>
> +1 to using the identifier in both.
Then why have the "URL Name" at all?
--
Wendy
Re: Proxy vs. Repository URLs
Posted by Henri Yandell <fl...@gmail.com>.
On 11/24/06, Wendy Smoak <ws...@gmail.com> wrote:
> Consider the following managed repository:
>
> My Managed Repository
> Identifier MYREPO
> Directory E:\svn\maven\archiva\archiva-webapp\target\my-managed-repository
> WebDAV URL http://localhost:9091/repository/myrepo
> Type Maven 2.x Repository
> Snapshots Included true
> Indexed true
>
> To use it as a normal repository, the url is
> http://localhost:9091/repository/myrepo
>
> To use that same repo as a proxy, (as far as I can tell, with maxb's
> help on IRC,) it's
> http://localhost:9091/proxy/MYREPO
>
> Is this correct? If so, why do we use the 'URL Name' in one place and
> the 'Identifier' in another?
+1 to using the identifier in both.
Hen