Nexus or Nexus Professional: Which one is right for you?
If you are a software developer, you most likely rely on a Maven Repository Manager to acquire, manage, and report on open source software artifacts — the building blocks of application development. Nexus is the industry-leading Repository Manager, and the recent release of Nexus 1.6 brings many exciting upgrades to both Nexus and Nexus Professional. But how do you decide what version of Nexus is best for you?
There are a few things to consider. Below is just a few differences to keep in mind and help you make the best decision.
Nexus 1.6 introduces Auto blocking unreachable remote repositories
In Nexus 1.6, we reintroduced a useful little feature that had been available in early 1.0 betas: The ability to have Nexus auto block proxies that are unreachable. What’s improved in this version is the ability to control this feature and the fact that it will auto unblock the repo once it becomes reachable again.
Whenever an artifact is downloaded from a proxy repository, it is automatically cached locally and used to serve subsequent requests. Nexus will continue to serve the artifact until it expires based on the configuration (release artifact typically never expire).
When new artifacts are being requested that Nexus has never seen before, it will look in the proxies to locate it (this behavior can be optimized with routing rules). If the remote request times out, Nexus by default will check two more times before giving up. This is usually enough to handle transient network glitches. If however, the repository is down for an extended period of time, all these retries can back up the connections and slow down over all performance. This is where the auto block comes in.
Now Available – Sonatype's Spring 2010 Newsletter
The Spring 2010 edition of the Sonatype newsletter is now available! Read all about Nexus 1.6 – a new release for both Nexus Open Source and Nexus Professional – and the changes that we’ve made to our repository manager. In this edition of the newsletter you can also watch the latest m2eclipse videos, view presentations from Sonatype’s Maven Meetup in Philadelphia, and learn how to find out about product releases and announcements the minute they break.
In this issue, you can also learn more about Sonatype’s instructor-led online training courses covering Maven and the design of efficient software development infrastructure. These classes are led by world-class experts in the field and have become the premier source of education for companies deploying Maven-based infrastructure.
To continue reading, click here.
JBoss Switches to Nexus Professional
Over the weekend, the JBoss repository team put the final pieces in place to complete the switch to Nexus Pro. We’ve been working with them since early this year to perform analysis and tool support for the conversion. Their team performed very diligent testing of the entire system prior to the conversion. Kudos to Paul for such an orderly and thorough process. The timing of the production switch is great because we are nearly done helping to clean up the Java.net repositories.
Historically the JBoss and Java.net repositories have been painful for Maven users. The reasons for this pain differed in each case, but overall these repositories have affected a large section of the community because of the popularity of the artifacts they contain.
The JBoss repository generally had decent metadata and release practices. The major concern in this repo was that the single repository contained artifacts in the following categories: 1) JBoss original artifacts 2) Copies of artifacts from other repositories 3) Artifacts with the same coordinates as artifacts in another repository, but that had been patched or otherwise altered
Ideally the repository should have contained only artifacts in category 1. Category 3 is what caused the most pain, because as soon as you pulled some artifacts from the JBoss repo, you potentially could get “polluted” with these altered artifacts.
"Why Nexus?" for the Non-programmer
I’ve had a number of non-programmers ask me “What is Nexus?” What is it? What does it do? You’d think I’d have a quick answer for the question, and I have a few that I always resort to that revolve around efficient collaboration and ease of deployment. But the challenge in this particular conversation was how to convey “What Nexus is” to someone who might not have direct programming experience. It is easy for a developer to talk to another developer, as we share the same set of experiences. I can say “compiler” and be reasonably certain that you not only know what a compiler does, but that you use one every single day. So, when I say something like:
“Nexus is a repository manager. It allows you to proxy, collect, and manage your dependencies so that you are not constantly juggling a collection of JARs. It makes it easy to distribute your software. Internally, you configure your build to publish artifacts to Nexus and they then become available to other developers. You get the benefits of having your own ‘central’, and there is no easier way to collaborate.”
Someone who doesn’t program every day nods, feigns approval; “That sounds very interesting”, but I am still skeptical that I got the message across. I’ll usually resort to an assembly line analogy; “Think of Nexus as an assembly line, it provides a context for collaboration.” But, still, there is a lack of shared context. If you are a programmer, my previous explanation was likely clear. If you are not a programmer, you’ll have questions. What is ‘central’? What is a ‘JAR’? What am I proxying? Instead of attempting to explain Nexus in a paragraph, let’s try to set up some background.
