<iframe src="//www.googletagmanager.com/ns.html?id=GTM-TT8R4P" height="0" width="0" style="display:none;visibility:hidden">

Sonatype Blog

Stay updated on the latest news from the makers of Nexus

Tim OBrien

Recent Posts by Tim OBrien:

Google Guava Shows Strong Growth in April

I was doing a bit of data analysis of the data that drives our Nexus Professional popularity results and I came across some statistics that show demand for Google Guava has been picking up over the last year. Our Top 10 list for general utilities contains the usual suspects. Libraries like Commons Lang and Commons Beanutils are predictably near the top of the list as are both log4j and slf4j. Not only are these the utilities you'd expect to see in almost every Java project, many of the dependencies you depend on also reference these libraries. This list is a list of utilities and projects you'd better be familiar with if you are programming in Java because you will undoubtedly encounter them.

Nexus is for Sharing

One of our customers asked me for a presentation deck making a simple case for bringing Nexus into a development environment: what are the broad stroke benefits of the repository from the perspective of the Enterprise? This video is that presentation, it doesn't spend too much time enumerating a list of pro features. It focuses on the two core benefits: consuming OSS and internal sharing.

Selecting OSS Components: Three Questions Answered by Nexus Pro

There are over 400,000 components in the Central repository including everything from servlet containers like Apache Tomcat to critical application infrastructure like Spring and Hibernate. When you are designing an application or trying to update an application's dependencies, how do you choose which component to use?

Now Available: Nexus OSS 2.0.4

Sonatype is pleased to announce the release of Nexus OSS 2.0.4. Nexus 2.0.4 OSS is available and ready for download immediately. If you are new to Nexus, or if you are an existing user, go to http://www.sonatype.org/nexus/go, click on the download button and get started.

When you run Nexus: "It Just Works"

Here's a message to nexus-user from Eric Kolotyluk an active Nexus user who just upgraded his instance of Nexus and sent this message to the Nexus Users mailing list:

Can Nexus Scale?

We're often asked by customers to prove that Nexus can scale to meet the demands of thousands, and sometimes tens of thousands, of developers. Fortunately, we don't have to stand up an expensive set of machines for a proof-of-concept as we have the world's largest collection of active open source projects hosted on a single instance of Nexus Professional running at http://oss.sonatype.org. This instance isn't just proof that Nexus Professional can scale, it serves as a public instance that you can model your own instance after.

An Emerging Role in IT Governance: The ALM Architect

Whenever I'm at a client I tend to ask, "Who decides what open source packages are acceptable?" Nine times out of 10, people will say something about an "Architecture" group. Maybe there's a single architecture group that sets standards across the entire department, or, more often, there are several groups that offer a set of services that may overlap. The more moving parts in an IT department the less clear people are about who will be responsible for running Nexus.

Take one example: I encountered a company that had a central architecture group alongside another team that managed deployments. There was some confusion: who would manage Nexus. Eventually they decided that Nexus fell under the auspices of the Architecture group because this group was setting license policy and that's why they were bringing it in in the first place. I had two takeaways from this:

  • This is an entirely new problem that most organizations haven't adapted to yet - having a comprehensive view of everything in your Development Infrastructure stack.
  • While everyone was cordial, there was some tension. Some unknown set of overlapping responsibilities that wasn't entirely development nor ops. I do think that while DevOps preaches harmony it may also encourage lack of clarity for who is responsible for running something like a repository manager.