Re: Antwort: RE: Antwort: RE: Proxy settings

2006-12-05 Thread Carlos Sanchez

On 12/4/06, Mohni, Daniel <[EMAIL PROTECTED]> wrote:


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]

> My position is that the POMs which come from the main sites
> can (and will)
> contain anything (even illegal XML, broken checksums, etc).
> The proxy has
> to handle all these case gracefully or at least to support
> the admin in
> doing so.
>
> I'm missing these functions in archiva:
>
> - Generic proxy (so the POMs can't mess with your mirror settings).

from my point of view this has nothing to do with archiva, this is a
maven problem.
I don't know if you can setup a generic proxy in your settings.xml as I
didn't
find anyhing in the documentation, but maybe there is a hidden option
;-)

checkout http://maven.apache.org/settings.html



You can use * as mirror id to mactch all servers since maven 2.0.5
(not yet released) or Maestro 1.1 that you can get from
http://www.mergere.com/





> - Regenerate checksum (for all downloads which I needed to fix)

As far as I know this is one of the features that will be implemented
into archiva,
maybe it's already in the daily builds but I didn't tested them the last
few days...

> - Lock down file (so Archiva will not try to download it
> again even if the
> remote site says "but I have new version" or the user says "get the
> newest, hottest snapshots!").

this can be done be done on user site with the usePluginRegistry
property set to true,
but this is not realy nice as you will have to confirm every plugin
version...

loking files in the proxy is only usefull if this is used for all users,
is this
realy what you want ?
What will you do if another team use another version

>
> I can live without the last two but the first one is a must, IMHO.

-> fill an issue on the maven project, maybe it's already in jira...

just my two cents

Daniel




--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride


Antwort: RE: Antwort: RE: Proxy settings

2006-12-04 Thread Aaron . Digulla
"Mohni, Daniel" <[EMAIL PROTECTED]> schrieb am 04.12.2006 
15:15:13:

> A released plugin should not have a repository entry in his pom.xml !!!
> that's my opinion, but maybe it's wrong... 

My position is that the POMs which come from the main sites can (and will) 
contain anything (even illegal XML, broken checksums, etc). The proxy has 
to handle all these case gracefully or at least to support the admin in 
doing so.

I'm missing these functions in archiva:

- Generic proxy (so the POMs can't mess with your mirror settings).
- Regenerate checksum (for all downloads which I needed to fix)
- Lock down file (so Archiva will not try to download it again even if the 
remote site says "but I have new version" or the user says "get the 
newest, hottest snapshots!").

I can live without the last two but the first one is a must, IMHO.

Regards,

-- 
Aaron Digulla



RE: Antwort: RE: Proxy settings

2006-12-04 Thread Sam Wilson
I completely agree with both statements:

1) snapshot dependency that you can not control is a mess, in 
a customer project ... build the plugin from source with your custom
artifactId and deploy it to your repository

and

2) A released plugin should not have a repository entry in his pom.xml

I ran into this recently when people.apache.org was down during a data
center move. I was just setting up my repository the day before so I got
caught in the maelstrom before I could take corrective action. 

However, a fair number of released plugins had references to
people.apache.org that should not have been there. This tends to be a
real problem with codehaus projects.

At the very least, snapshot and release repositories should be properly
labeled as such if they are going to be included.

sw

-Original Message-
From: Mohni, Daniel [mailto:[EMAIL PROTECTED] 
Sent: Monday, December 04, 2006 9:15 AM
To: archiva-users@maven.apache.org
Subject: RE: Antwort: RE: Proxy settings

Hello again

all I can say about this is that a lot of the current maven2 plugins
are still in development and not in release state. this is
also why they have this snapshot repositories in their pom...

but they are going to be stable quite soon, hopefully...

using snapshot dependency that you can not control is a mess, in 
a customer project.

If you realy need a snapshot version for your project, then the
workaround is to build the plugin from source with your custom
artifactId and deploy it to your repository. it's not very nice
but in this case you have control over the used version in your project
until the plugin is stable.

A released plugin should not have a repository entry in his pom.xml !!!
that's my opinion, but maybe it's wrong... 

Maybe someone else can help you out

sorry

Daniel
 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: Monday, December 04, 2006 2:51 PM
> To: archiva-users@maven.apache.org
> Subject: Antwort: RE: Proxy settings
> 
> Hi Daniel,
> 
> What do I do if POM.xml of a plugin says this:
> 
> 
> 
> apache-snapshots
> Snapshot repository
> http://people.apache.org/maven-snapshot-repository/
> 
> 
> 
> but the plugin cannot be found in this repository? Like in the JSP 
> compiler maven plugin from codehaus.
> 
> My problem is the . Every project defines their own id. 
> For some, it's 
> "codehaus", for others it's "codehaus.org". For another 
> group, "codehaus" 
> is for releases, while "codehaus.org" is for snapshots.
> 
> This means the id *cannot* be used to map mirrors to URLs.
> 
> Therefore, I need a solution in archiva which I can feed with 
> arbitrary 
> URLs and which either goes to a stable inhouse repository or 
> downloads the 
> resource from the URL and caches it.
> 
> Having users define proxied repositories manually and map 
> them to managed 
> repositories is not the solution, it's another layer of 
> problems. Archia 
> should support a generic proxy/cache which just stores a 
> resource under an 
> URL. So when I ask for apache.org/.../plugin-1.3.pom and for 
> codehaus.org/.../plugin-1.3.pom, I should get two different 
> files if they 
> are different on the respective servers.
> 
> On disk, you can just use the hostname as the first item in 
> the path to 
> distinguish between the different artefacts.
> 
> In the webapp, it should be possible to "freeze" certain URLs (for 
> example, if the files on the web are broken or I'm using a 
> patched version 
> inhouse).
> 
> With this solution, I could use the Maven proxy settings 
> (instead of the 
> broken mirror stuff) to download artefacts for my development 
> team *once*.
> 
> Regards,
> 
> -- 
> Aaron Digulla
> 
> "Mohni, Daniel" <[EMAIL PROTECTED]> schrieb am 04.12.2006 
> 11:31:28:
> 
> > Hello Aaron
> > 
> > this can be done setting the mirror in settings.xml
> > 
> >  
> >
> >  proxy.central
> >central
> > Internal Mirror of central.
> >http://archiva/proxy/maven_release
> > 
> >   
> > 
> > -> if you use proxy in the url then archiva will try to download
> >missing artefacts from the proxied repo setup in archiva
> > 
> >http://archiva/proxy/maven_release
> > 
> > -> if you use repository in the url then archiva will only be
> >a cache provider for your already downloaded artefacts
> > 
> >http://archiva/repository/maven_release
> > 
> > maven_release is our internal proxy repository...
> > 
> > I don't know if this is still like t

RE: Antwort: RE: Proxy settings

2006-12-04 Thread Mohni, Daniel
Hello again

all I can say about this is that a lot of the current maven2 plugins
are still in development and not in release state. this is
also why they have this snapshot repositories in their pom...

but they are going to be stable quite soon, hopefully...

using snapshot dependency that you can not control is a mess, in 
a customer project.

If you realy need a snapshot version for your project, then the
workaround is to build the plugin from source with your custom
artifactId and deploy it to your repository. it's not very nice
but in this case you have control over the used version in your project
until the plugin is stable.

A released plugin should not have a repository entry in his pom.xml !!!
that's my opinion, but maybe it's wrong... 

Maybe someone else can help you out

sorry

Daniel
 

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: Monday, December 04, 2006 2:51 PM
> To: archiva-users@maven.apache.org
> Subject: Antwort: RE: Proxy settings
> 
> Hi Daniel,
> 
> What do I do if POM.xml of a plugin says this:
> 
> 
> 
> apache-snapshots
> Snapshot repository
> http://people.apache.org/maven-snapshot-repository/
> 
> 
> 
> but the plugin cannot be found in this repository? Like in the JSP 
> compiler maven plugin from codehaus.
> 
> My problem is the . Every project defines their own id. 
> For some, it's 
> "codehaus", for others it's "codehaus.org". For another 
> group, "codehaus" 
> is for releases, while "codehaus.org" is for snapshots.
> 
> This means the id *cannot* be used to map mirrors to URLs.
> 
> Therefore, I need a solution in archiva which I can feed with 
> arbitrary 
> URLs and which either goes to a stable inhouse repository or 
> downloads the 
> resource from the URL and caches it.
> 
> Having users define proxied repositories manually and map 
> them to managed 
> repositories is not the solution, it's another layer of 
> problems. Archia 
> should support a generic proxy/cache which just stores a 
> resource under an 
> URL. So when I ask for apache.org/.../plugin-1.3.pom and for 
> codehaus.org/.../plugin-1.3.pom, I should get two different 
> files if they 
> are different on the respective servers.
> 
> On disk, you can just use the hostname as the first item in 
> the path to 
> distinguish between the different artefacts.
> 
> In the webapp, it should be possible to "freeze" certain URLs (for 
> example, if the files on the web are broken or I'm using a 
> patched version 
> inhouse).
> 
> With this solution, I could use the Maven proxy settings 
> (instead of the 
> broken mirror stuff) to download artefacts for my development 
> team *once*.
> 
> Regards,
> 
> -- 
> Aaron Digulla
> 
> "Mohni, Daniel" <[EMAIL PROTECTED]> schrieb am 04.12.2006 
> 11:31:28:
> 
> > Hello Aaron
> > 
> > this can be done setting the mirror in settings.xml
> > 
> >  
> >
> >  proxy.central
> >central
> > Internal Mirror of central.
> >http://archiva/proxy/maven_release
> > 
> >   
> > 
> > -> if you use proxy in the url then archiva will try to download
> >missing artefacts from the proxied repo setup in archiva
> > 
> >http://archiva/proxy/maven_release
> > 
> > -> if you use repository in the url then archiva will only be
> >a cache provider for your already downloaded artefacts
> > 
> >http://archiva/repository/maven_release
> > 
> > maven_release is our internal proxy repository...
> > 
> > I don't know if this is still like this in the current daily build
> > as I didn't tried it...
> > 
> > hth
> > 
> > Daniel
> > 
> > > -Original Message-
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> > > Sent: Monday, December 04, 2006 11:19 AM
> > > To: archiva-users@maven.apache.org
> > > Subject: Proxy settings
> > > 
> > > Hello,
> > > 
> > > We're using maven for internal development. Since the 
> > > internet as a whole 
> > > and our connection to it especially are not always reliable 
> > > (for example, 
> > > a new version of a virus checker sometimes starts to 
> block out maven 
> > > downloads), we wanted to use Archiva as a local cache of the 
> > > central maven 
> > > repositories.
> > > 
> > > As it is right now, I have to configure each repository 
> > > individually. What 
> > > we would prefer is a setting which makes Archiva the default 
> > > proxy for 
> > > maven so all external connections are made over it.
> > > 
> > > This would allow us to keep local copies of all artefacts 
> so internet 
> > > outages wouldn't affect us anymore. Also, we could fix broken 
> > > packages 
> > > locally. Ideally, there should be two caches: One with stable 
> > > version for 
> > > development and one which can update itself with the current 
> > > versions from 
> > > the internet.
> > > 
> > > Is this possible?
> > > 
> > > Regards,
> > > 
> > > -- 
> > > Aaron Digulla
> > > 
> > > 
> 
>