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: > > <repositories> > <repository> > <id>apache-snapshots</id> > <name>Snapshot repository</name> > <url>http://people.apache.org/maven-snapshot-repository/</url> > </repository> > </repositories> > > but the plugin cannot be found in this repository? Like in the JSP > compiler maven plugin from codehaus. > > My problem is the <id>. 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 > > > > <mirrors> > > <mirror> > > <id>proxy.central</id> > > <mirrorOf>central</mirrorOf> > > <name>Internal Mirror of central.</name> > > <url>http://archiva/proxy/maven_release</url> > > </mirror> > > </mirrors> > > > > -> 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 > > > > > > > >
