On 16-Mar-08, at 1:25 PM, Nigel Magnay wrote:

Have you got a description of how you think it ought to work?


I will do a demo sometime this week at EclipseCon, and I'm happy to share the configuration I have. But it should be as simple as described. One place to go, at least in a corporate environment with 100+ users it's the only way that's workable.

I quite like the ability of downloading projects that rely on 3rd
party repos, and having them magically work without having to do
anything (which is why I have a distaste for having to go through a
validate-my-settings-and-proxy-don't-break-external-users step when
pushing project changes to outside users).

Most corporate IT people don't like Maven scurrying off to some unknown repository fetching stuff. I have had users walk up to me and go "what the hell is Maven doing?".

It is possible to make Maven do pure delegation (the mirrorOf is still doesn't work well for snapshots and plugin repositories) and then you can do what Tamas and I call build discovery: while a build is executing the repository manager can collect every request to a repository. The build could block while you approve, automatically adding it to the list of proxied repositories, or you could just cycle through the build, collect them all and then audit them. You could then find the pieces in each of those repositories, download them to your own if you don't want to proxy them and then completely lock down the outside connections. This stuff needs to be dead simple as a lot of people don't like Maven crawling around all over the place. So we effectively I would encourage no repos in POMs, but we have what we have now and you need to identify repositories in the POMs flying through and contain them.



I think all I'm saying is that repository names are good, or
repository URLs are good, but names *and* URLs isn't.

On Sun, Mar 16, 2008 at 7:03 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote:

On 16-Mar-08, at 11:39 AM, Nigel Magnay wrote:

I've never thought it was sane in the first place...


It is. Ultimately a repository manager should requires users to point
at one URL, period. All control must reside in the repository manager
or it's a configuration nightmare. Even if you automated the
propagation of configuration, which can be done with an SCM, or a pub/
sub model it's still a pain in the ass.

The shortest settings.xml that fully delegates to a repository manager
is still pretty lengthy but it's possible to do now, but eventually
one short URL that every developer points to should suffice.

The mirrorOf is a result of people putting repositories in their POMs
which is a horrible practice. The short term benefit of what appears
to be self-containment is a huge, fat mess. In a corporate environment
it is entire possible to know what repositories you need up-front.
Putting repositories in POMs make it impossible to have any sort of
automated promotion model and the bane of anyone's effort to have a
sane process within their organization.

In short, the baked in repos in our super POM should go away, and be
replaced by a simple configuration visible in the maven install.
Anyone should be able to change that easily, and/or control it all
from settings and ultimately it's one URL and folks delegate to a
repository manager. Repositories in POMs, hacks to repath repositories
like mirrorOf, and the "*" notation are a complete dead end. It needs
to be made explicit and made manageable.



I don't understand why the artifact servers (archiva et al) can't just
respond in the same way that an ordinary proxy server does, without
all this mirrorOf mucking about. Working on two or three independant
projects and my settings.xml is a bloatfest of project-specific repo
names.

I've got about 5 <mirrorOf> sections all pointing to a corporate
archiva server. Unfortunately (again), that's been set up in the
'default/recommended' way, whereby many remote sites are all being
proxied through one archiva repository of /internal, which IMO is
really bad, because it's possible to specify a new artifact in your
pom.xml and find it magically downloads from {remote.repo.one} via
/internal, even though you never specified {remote.repo.one} in your
pom.xml in the first place. Which is all fine until someone remote
tries to build it offsite and.. bang, it all stops working.

If the local repository was more separated out into a different format
that separated out the remote repositories that the artifacts came
from, then you could rsync directly into them anyway, which would
solve half these problems anyway... I.E

.m2/repository/local/...
.m2/repository/snapshots.maven.codehaus.org/maven2/...

etc., etc.

On Sun, Mar 16, 2008 at 5:50 AM, Joakim Erdfelt <[EMAIL PROTECTED]>
wrote:
I was motivated by http://jira.codehaus.org/browse/MNG-3407 and some
personal headaches, mostly with dealing with working with OSS on a
laptop within restricted environments, (ie. no, or bad internet
connection, such as a service station, while waiting for your car
to be
fixed.)

I have a local directory on my laptop with a central rsync and the
java.net repos, which helps a ton.
But, I've set up a long list of <mirrorOf> entries to catch
specific ids
and redirect them to my file:// urls.
Which works, but the list is growing, I don't set up
<mirrorOf>*</mirrorOf> intentionally, because I have separations
for the
directories (so that rsync works ok for example).

I was motivated tonite to scan my central rsync mirror for
<repository>
and <pluginRepository> sections to see what is actually in use,
what I
found kinda confirmed my suspicions, the free form repository id
naming
has blossomed into an interesting variety of choices.

Heh, this email will be good google-bot food for people searching for
maven repository mirrors.

acegi-snapshot : http://acegisecurity.sourceforge.net/repository/snapshots
activemq : http://people.apache.org/~chirino/incubator-activemq-4.0/maven2/
activemq-repo : http://people.apache.org/repo/m2-incubating-
repository
agilesque-legacy-repository : http://agilesque.net/dist
AMQ 4.0.2 :
http://people.apache.org/~chirino/incubator-activemq-4.0.2-RC3/maven2
apache.incubating : http://people.apache.org/repo/m2-incubating-repository
apache-incubator : http://people.apache.org/repo/m2-incubating-repository/
apache.incubator : http://people.apache.org/repo/m2-incubating-repository
apache-incubator-repo :
http://people.apache.org/repo/m2-incubating-repository
apache-maven-snapshots : http://cvs.apache.org/maven-snapshot-repository
apache-maven-snapshots :
http://people.apache.org/repo/m2-snapshot-repository/
apache.org : http://people.apache.org/repo/m2-snapshot-repository
apache-plugin-snapshots-repository :
http://people.apache.org/repo/m2-snapshot-repository
apache.snapshot : http://people.apache.org/repo/m2-snapshot-
repository
apache-snapshot-repo : http://people.apache.org/maven-snapshot-repository
apache.snapshots : http://cvs.apache.org/maven-snapshot-repository
apache.snapshots : http://cvs.apache.org/repository
apache.snapshots : http://minotaur.apache.org/maven-snapshot-repository
apache-snapshots : http://people.apache.org/maven-snapshot-
repository/
apache.snapshots : http://people.apache.org/maven-snapshot-repository
apache-snapshots : http://people.apache.org/repo/m2-snapshot-repository
apache.snapshots : http://people.apache.org/repo/m2-snapshot-repository
atanion : http://www.atanion.com/maven2
atlassian : http://repository.atlassian.com
central : http://ibiblio.org/maven2/
central : http://repo1.maven.org/maven2
central : http://www.ibiblio.org/maven2
codehaus : http://dist.codehaus.org
codehaus : http://dist.codehaus.org/
codehaus : http://repository.codehaus.org
codehaus : http://repository.codehaus.org/
CodeHaus : http://snapshots.maven.codehaus.org/maven2
codehaus-legacy-repository : http://dist.codehaus.org
codehaus-m1-repository : http://dist.codehaus.org
codehaus-m2-repository : http://repository.codehaus.org
Codehaus Maven Plugin Repository : http://dist.codehaus.org
Codehaus Maven Repository : http://dist.codehaus.org
codehaus.org : http://repository.codehaus.org/
codehaus.org : http://snapshots.repository.codehaus.org
codehaus.org : http://snapshots.repository.codehaus.org/
codehaus-plugin-repository : http://snapshots.maven.codehaus.org/maven2/
codehaus-snap : http://snapshots.repository.codehaus.org/
codehaus-snapshot-repo : http://snapshots.repository.codehaus.org/
codehaus-snapshots : http://snapshots.maven.codehaus.org/maven2
codehaus-snapshots : http://snapshots.repository.codehaus.org
codehaus-snapshots : http://snapshots.repository.codehaus.org/
codehaus.snapshots : http://snapshots.repository.codehaus.org
dist.codehaus.org : http://dist.codehaus.org
dtddoc : http://dtddoc.sf.net/maven2
fabric3 : http://www.fabric3.org/snapshots
gleamynode-m1-repository : http://gleamynode.net/dev
gwt-maven-repo : http://gwt-maven.googlecode.com/svn/trunk/ mavenrepo
ibiblio : http://ibiblio.org/maven2
java.net : https://maven-repository.dev.java.net/nonav/repository
java.net : https://maven-repository.dev.java.net/repository
java.net repository :
https://maven-repository.dev.java.net/nonav/repository/
jetty6-releases : http://www.mortbay.org/maven2/release
jetty6-snapshots : http://www.mortbay.org/maven2/snapshot
jetty-repository : http://repository.codehaus.org/
jetty-snapshot-repository :
http://jetty4.inetu.net/home/ftp/pub/maven2/snapshot
jetty-snapshot-repository : http://snapshots.repository.codehaus.org/
jibx : http://jibx.sourceforge.net/maven2/
jibx.sf.net : http://jibx.sf.net/maven
jibx.sf.net : http://jibx.sf.net/maven2
m2-snapshot-repository :
http://people.apache.org/repo/m2-snapshot-repository
mapasuta.repo : http://mapasuta.sf.net/maven/repo
maven2 : http://repo1.maven.org/maven2
maven2-repository.dev.java.net : http://download.java.net/maven/1/
maven2-repository.dev.java.net :
https://maven2-repository.dev.java.net/nonav/repository
Maven Codehaus Snapshots : http://snapshots.maven.codehaus.org/
maven2/
maven-hostedqa : http://maven.hostedqa.com
maven-snapshot : http://snapshots.maven.codehaus.org/maven2
Maven Snapshots : http://snapshots.maven.codehaus.org/maven2
Maven Snapshots : http://snapshots.maven.codehaus.org/maven2/
mirror : http://www.ibiblio.org/maven2
mirrormax.mirror : http://apache.mirrormax.net/apache/maven-repository/
module-local : file://${pom.basedir}/repository
module-repo : file:${basedir}/repository
mojo.snapshots : http://snapshots.maven.codehaus.org/maven2
mortbay-repo : http://www.mortbay.org/maven2/snapshot
mortbay-snapshot-repo : http://jetty.mortbay.org/maven2/snapshot
oaw.repository : http://openarchitectureware.org/m2/
objectstyle.org : http://objectstyle.org/maven2/
ObjectWeb Maven Repository : http://maven.objectweb.org/maven2/
openqa : http://maven.openqa.org
OpenQA : http://maven.openqa.org
org.livetribe : http://repo.livetribe.org/maven2-snapshot
playboy.mirror : http://mirrors.playboy.com/apache/maven- repository/
project-repo : file:${basedir}/${topDirectoryLocation}/maven_repo
repository-codehaus : http://repository.codehaus.org
repository.codehaus.org : http://repository.codehaus.org/
safehaus : http://m2.safehaus.org
safehauS-m1-repository : http://maven.safehaus.org/
seekmeup.mirror : http://apache.seekmeup.com/apache/maven-repository/
smartlab : http://www.smartlab.net/releases
snapshot-apache : http://people.apache.org/repo/m2-snapshot-
repository
snapshot : http://snapshots.maven.codehaus.org/maven2/
snapshots : http://snapshots.maven.codehaus.org/maven2
snapshots : http://snapshots.maven.codehaus.org/maven2/
snapshots : http://snapshots.repository.codehaus.org
snapshots-plugins : http://snapshots.maven.codehaus.org/maven2
snapshots-plugins : http://snapshots.maven.codehaus.org/maven2/
plugins
snapshots.repository.codehaus.org :
http://snapshots.repository.codehaus.org/
sppatel : http://people.apache.org/~sppatel/maven/repository/
spring-repository :
https://svn.sourceforge.net/svnroot/springframework/repos/repo
spring-repository :
https://svn.sourceforge.net/svnroot/springframework/repos/repo/
spring-snapshot-repository :
https://svn.sourceforge.net/svnroot/springframework/repos/repo-snapshots
spring-snapshot-repository :
https://svn.sourceforge.net/svnroot/springframework/repos/repo-snapshots/
tapestry.javaforge : http://howardlewisship.com/repository
vraptor2 : http://vraptor2.sourceforge.net/m2repo
wicket : http://wicket.sourceforge.net/maven2
xfire : http://dist.codehaus.org

The approach nicolas took in MNG-3407 is strange. I don't understand the whole {0} idea. Wouldn't it make more sense to base mirrorOf on
host or url instead?
That way the mirror section can be wrangled in a more sane way?

example:

<mirrors>
<mirror>
  <mirrorOf>http://snapshots.repository.codehaus.org</mirrorOf>
  <url>file:///home/repos/codehaus/snapshots</url>
</mirror>
<mirror>
  <mirrorOf>http://repository.codehaus.org</mirrorOf>
  <url>file:///home/repos/codehaus/releases</url>
</mirror>
<mirror>
  <mirrorOf>http://people.apache.org/maven-snapshot-repository</
mirrorOf>
  <url>file:///home/repos/apache/snapshots</url>
</mirror>
</mirrors>

At first glance, the tendency would be to look for ":/" in the
mirrorOf
setting and use an url based mirror mapping, but that is probably a
bad
idea, considering that we had no restrictions on repository id
naming.
just because central has noone using ":/" in the repository id
doesn't
mean someone out there isn't using it.

- Joakim


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

Simplex sigillum veri. (Simplicity is the seal of truth.)






---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

We know what we are, but know not what we may be.

-- Shakespeare



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to