<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:

(Often,) You People are Too Smart to Train

I don't often teach our training classes in Maven or Nexus, but when I do, I always tend to get interesting classes. I'm halfway through a on site training class today that, so far, has stood out as a unique experience for me as a trainer. Usually you set up your slides, hand out the materials, and start running through the content. It often takes a class and an instructor an hour to find a good cadence for teaching and answering questions. One metric I keep track of is the amount of time spent delivering content from slides vs. the amount of time spent answering questions. I strive for 75/25 - 3/4 of the class is focusing on content, 1/4 of the class is focused on answer student questions.

The first thing I do in my classes is implore (literally plead) with the students to interrupt me. "Ask questions. If you don't this class won't be valuable to you." I do this because all too often I have a class of students that seems reticent to ask question or interrupt. Who knows why, maybe they don't want to ask a dumb question (those don't exist), maybe they are taking the class with a manager and they don't want to look bad? Whatever the case, silence is the worst thing an instructor can get in response to the question: "Are there any questions?..... no?..... anyone? Ok. Anyone want to make a statement?.... no? alright, let's move on..."

Dogfooding Sonatype Insight: We found Vulnerabilities in Nexus

"Dogfooding" is such a strange word, and I'm using it as a substitute for "Eating your own dog food". As we do have a global audience, I worry that the term is somewhat provincial (and maybe a bit strange out of context). So here, here's the explanation of this idiom on Wikipedia.

Sonatype is "recursive". We're a group of developers, creating tools for developers, getting feedback from developers. Logically, we tend to use everything we make. We're the first customer. We deploy early development releases of Nexus Professional to our own Nexus Professional instance, we use repository.sonatype.org as a test case as the release approaches, and every feature we send out to our customers has been audited and tested internally. By the time you download our software, we've already been using it often for a few months or weeks, and we also make heavy use of Sonatype Insight to identify licensing and security risks.

Now, this blog post is a bit risky. I'm about to tell you about the security issues that the Engineering team discovered in Nexus when we ran Nexus through our Insight scanner during the Nexus 2.1 release. By doing this, I'm exposing people that haven't updated Nexus to 2.1 to some risk. At the same time, I've given everyone ample notice to upgrade (I even made a video imploring people to upgrade), and I'm a big believer in transparency. If we know something related to security, you should know it as well after we've given people enough time to upgrade.

Best Strategy for Migrating from Apache Ant to Apache Maven

Whenever I teach a Maven training class someone invariably asks me to give some advice for migrating a large, complex Ant project to Maven. Toward the end of the class, I'll take questions:

Participant: "Could you give us some guidance for migrating Ant projects to Maven? Is there a process that you recommend to make it easier."

My (honest) answer: "If it's a complex project, it won't be an easy battle. Before you go down this road you need to understand what you are signing up for. It can be very complex, you may end up interrupting an active development cycle, and once you evaluate all of your options you might find it easier to first migrate to a repository manager. Maven's not the big win, moving a repository is."

In other words, I often find myself trying to discourage swapping build tools just for the sake of swapping build tools. While I do believe that Maven is preferable to Ant, I think that the build space often suffers from a belief that the grass really is greener on the other side. It might be, but is it greener enough to justify that work stoppage that is involved in taking a big important project and moving it to a different build technology? Often the answer is no. If it isn't related to making money, switching a build system is often the last thing an enterprise wants to do.

In this post I'm going to talk about the process of migrating build tools starts with a repository manager.

Securing Repository Credentials with Nexus Pro User Tokens

Until yesterday I had a Maven Settings file in ~/.m2/settings.xml that contained following XML:

Nexus 2.1 Now Available, Go Get It

This is a big release. We're announcing the immediate availability of Nexus 2.1, the first minor version update since the Nexus 2.0 release earlier this year. This simultaneous release of both Nexus Open Source and Nexus Professional caps off months of effort to implement two major features in Nexus Professional:

Learning the Nexus REST API: Read the Docs or Fire Up a Browser

When you use Nexus, it is more than a UI. It is a collection of services available for you to automate. With these services you can integrate Nexus in whatever workflow makes sense for you. As a developer, this is what I look for in a product: something beyond the UI, something I can automate, and, most importantly, something that is documented. In Nexus, we've made it easy to start integrating Nexus REST services into your workflow by providing extensive documentation.

Yesterday's post was all about automating Nexus with REST services, and today's post is focused on giving you the tools you need to access the hundreds of REST endpoints you have access to with Nexus. If you are trying to automate anything in Nexus, you should know that there are two ways to "read" the Nexus REST API. You can access plugin documentation via the Nexus UI, or you can use a tool like Firebug in Firefox or Chrome's Developer Tools and inspect the requests generated by the Nexus UI.

Nexus Pro: Automating Staging Workflow with Gradle using the Nexus REST APIs

I recently had a request from a customer for some guidance on how to automate Staging in Nexus Professional from Gradle. Here was his core problem: he had a series of builds that needed to deploy to a staging URL and he was wondering if it was possible to automate the closing of a repository from Gradle. It is. While we've made it easy to do this in Maven with the Nexus Maven Plugin we didn't have the equivalent example in Groovy. This post gives some guidance to anyone who needs to call out to our REST services from Groovy.

As Nexus Professional exposes every feature as a REST endpoint it is very easy to automate these interactions in just about any language. This sample demonstrates who to incorporate calls to Nexus REST APIs directly from your build. It also provides a model for parsing JSON responses from Nexus and posting JSON requests. If you are interested in more of these examples, please let us know in the comments of this post. (One thing is sure, this particular example could use some improvement, please be harsh.)