Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Travis maven configuration doesn't use central by default #2528

Closed
sameb opened this Issue · 20 comments

4 participants

@sameb

Central is backed by a CDN and is designed to be fast. The other repositories can be singly homed and often can timeout while attempting to download jars.

For more information, see this thread, particularly these posts by Stuart: one two three, and the commit that fixed things for us.

@joshk
Owner

@BanzaiMan thoughts on this?

@BanzaiMan
Owner

Well, we overriding the default Maven settings with https://github.com/travis-ci/travis-cookbooks/blob/master/ci_environment/travis_build_environment/files/default/ci_user/maven_user_settings.xml, which was introduced by travis-ci/travis-cookbooks@14f0222.

The name "standard-with-extra-repos" leads me to believe that it is a settings that supplements the default settings (could that be https://github.com/travis-ci/travis-cookbooks/blob/master/ci_environment/travis_build_environment/files/default/ci_user/maven_user_settings.xml#L10-L40?) that includes the Maven Central repository, but I guess it is no longer the case. Unfortunately, the official documentation lacks the details as to what to do if we want to actually do this sort of "default + extra" maneuver. If we can confirm what values are recommended these days, I think we can attack this issue.

@sameb

@mcculls -- any idea? My guess is that things in the profile will be used in preference to the default (which is central). So maybe the solution is simply adding central at the top of the extra repos in the profile?

@BanzaiMan BanzaiMan self-assigned this
@mcculls

Yes the repositories in settings.xml have the highest priority when merging with any repository entries defined in the project pom.xml hierarchy (including the Central definition in the default super-pom).

So putting an entry for Maven Central first should also solve the issue:

    <repository>
      <id>central</id>
      <name>Central Repository</name>
      <url>http://repo.maven.apache.org/maven2</url>
      <snapshots>
        <enabled>false</enabled>
      </snapshots>
    </repository>

Central will then be checked first when looking for released artifacts (note it doesn't contain snapshots).

@BanzaiMan
Owner

@mcculls That snippet has <enabled>false</enabled>. Is that right? url is http://repo.maven.apache.org/maven2, which seems to redirect to http://central.maven.org/maven2. Which is more canonical at this juncture?

@mcculls

This is because Maven Central only contains releases so there's no point in looking in it for snapshots:

      <snapshots>
        <enabled>false</enabled>
      </snapshots>

The default setting for <releases> is true so you don't need to declare that, but you can if you want:

      <snapshots>
        <enabled>false</enabled>
      </snapshots>
      <releases>
        <enabled>true</enabled>
      </releases>

The canonical name (as defined in Maven's super-pom) is http://repo.maven.apache.org/maven2 which currently redirects to http://central.maven.org/maven2, but that's more of an implementation detail - for reference the latest super-pom can be found at http://maven.apache.org/ref/3.2.2/maven-model-builder/super-pom.html

@BanzaiMan BanzaiMan referenced this issue from a commit in travis-ci/travis-cookbooks
@BanzaiMan BanzaiMan Add Maven Central Repository
This repository is backed by CDN.
Detailed discussion is found in travis-ci/travis-ci#2528.
982ad12
@BanzaiMan
Owner

@mcculls Ah! Thank you for the detailed explanation and the link. Do you mind reviewing travis-ci/travis-cookbooks@982ad12?

@BanzaiMan
Owner

Is there a public repo that I can test the new configuration on? If this is resolved quickly, I can roll this into the VM update I'm working on.

@BanzaiMan
Owner

By the way, how does one tell where the artifacts are pulled from?

@BanzaiMan
Owner

Ah, I see the logs. I would still like a repository that is likely to exhibit this problem. Thanks.

@sameb

You're welcome to fork google/guice and test there. You'll just need to revert google/guice@c8bdc59 in order to see the problem.

@BanzaiMan
Owner

@sameb Hmm. I tried this… BanzaiMan/guice@2ebf5d5 is the 'undo' commit, but it is downloading from the Central repository it seems to me. (https://travis-ci.org/BanzaiMan/guice/jobs/29976422#L2821)

Did I do something wrong?

@sameb
@sameb

This is without your VM changes? Confusing. It vaguely looks like what's happening is we're still sending many requests to the wrong address, but they're now redirecting to central... so maybe externally folks have attempted to fix this also. I think after the VM changes, we'll stop seeing the initial Downloading: https://oss.sonatype.org & Downloading: https://repository.apache.org lines.

@BanzaiMan
Owner

@sameb This is without the change in VM. Running on the production image.

Indeed, on the test VM, I do not see those lines you mention.

@sameb

Sounds like the changes work then!

@BanzaiMan
Owner

OK. It'll be a part of the new VM.

@BanzaiMan
Owner

@sameb Update was released yesterday. Could you test it?

@BanzaiMan
Owner

Closing optimistically.

@BanzaiMan BanzaiMan closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.