Hi all,
I coud also have sent this question to the maven user list, but as this
is more related to user proxy configuration, I guess archiva ML will
find more people already having tackled this question.
Having said that, here's my question.
Here's the output of mvn -U
...\workspace2\CGA - Service>mvn -U clean
[INFO] Scanning for projects...
[INFO]
------------------------------------------------------------------------
[INFO] Building CGA - Services
[INFO] task-segment: [clean]
[INFO]
------------------------------------------------------------------------
[INFO] artifact org.apache.maven.plugins:maven-clean-plugin:
checking for updates from plugins-central-proxy
[INFO] artifact org.apache.maven.plugins:maven-clean-plugin:
checking for updates from central
We've got two repositories managed by archiva. The first line you see is
hitting one of our archiva repo "plugins-central-proxy", which is merely
proxying many public repositories on the net (repo1.maven.org, codehaus,
java.net, jboss and so on).
And here's the pluginRepositories part of our current maven settings.xml
<pluginRepositories>
<pluginRepository>
<id>plugins-central-proxy</id>
<url>http://mvnrepo.mipih.fr:4000/archiva/repository/public/</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
My problem is that, because of the super-pom, the "central" repository
is always looked up. We set up archiva so that everybody would go
through it (without even speaking about the corporate web proxy
policies). But here everyone ends up trying repo1.maven.org directly
(line in bold above). This is quite unsatisfying IMO.
One solution I already tried is to use "central" for our repo id. It
seems like it effectively redefines the super-pom repository definition
(which seems logical when thinking about maven object oriented
philosophy).
So, finally, my question is quite simple : is using "central" as the id
for custom repository a good or even acceptable practice? If not, what's
the best solution to prevent anyone that has the right settings.xml (and
no repo conf in their pom.xml) to directly access some external
repository?
Is there any documentation existing about those principles?
Thanks for your answers, guys.
Cheers.
-- Baptiste
P Sauvez un arbre,
Mangez un castor !
