CODEWITHSUNDEEP
mavenrepositorynexus
Paul Verest
Paul Verest

Reputation: 63872

Is there better way of configuring repositories in Nexus?

I have Nexus server, and maven user setting shared within team, that contains

  <mirrors>
      <mirror>
      <!--This sends everything else to /public 
      http://www.sonatype.com/books/nexus-book/reference/maven-sect-single-group.html
      -->
      <id>nexus</id>
      <mirrorOf>*</mirrorOf>
      <url>http://192.168.16.232:8081/nexus/content/groups/public</url>
    </mirror>    
  </mirrors>

That is all repositories defined in pom.xml (including default Maven Central) are served by Nexus.

In Nexus new repositories are added into public group.

Nexus public group

QUESTION: Is there better way? Currently other developers don't understand Nexus+Maven interaction and when there's new repository defined in pom.xml (that is not proxied by Nexus), maven will just say 'unable to get artifact'. But not "configure your Nexus server" :) Secondly I found that some public repository also cache from some others, so in the end, I can't be sure where exactly this jar came from.

UPDATE: I am searching for the most beautiful, simple, easy to explain and understand solution.

Upvotes: 0

Views: 199

Answers (2)

Michael
Michael

Reputation: 6499

That's actually the exact way that we're accomplishing it where I work. We mirror around 30 public repos and it's just the easiest way. The devs all use our nexus installation as one stop shopping and as we need to add things, it just shows up in the public repos. Doing this also allows us a much finer grain of control over what artifacts people are using, as we only include things we want to allow, not everything in the world.

We do have one difference though, we have a 'releases-only' and 'snapshots-only' repo, instead of one huge public one. The main reason is so we can have different caching policies, but it's also a bit nicer organizationally.

The only issue I have with the setup is that if you're trying to build while not on the network (office or vpn), then nothing works. I get around that by keeping 2 settings.xml files locally and switching on the rare occasion that I need to.

Upvotes: 1

chad
chad

Reputation: 7519

I'll give a couple of thoughts that come from my recent experience, but my sense is that you should make sure that you have a clear set of requirements regarding the build and various group's interaction with it, and drive your design of the build environment from those real requirements.

Tips.

1) I wouldn't put the mirror anywhere but on the CI build server. Inform the devs that they can pull from where ever they want on their local dev boxes, but when they check it in, if the dependency can't be located from the CI referenced nexus, then they have to work on that with you. This puts the responsibility on them.

2) That's a lot of repositories. I would consider NOT officially referencing so many public repo's. I don't know much about those repos in particular, but's a lot of stuff. And it sounds like you're experiencing duplicates. HOWEVER, your public group configuration will tell you were the jar came from; the order of the repos in that config will determine where the jar comes from. So, it will always pull from the first place it finds it.

Upvotes: 1

Related Questions