While you could do this via the Nexus UI, this wouldn’t help your automated nightly backup script. For this script to be easy to run, you’ll need to script Nexus via the REST interface. With the Nexus 1.6 release, we’ve released full documentation of the Nexus REST services available in every Nexus installation (REST doc). Continue reading for an example of how to interact with, authenticate, and manipulate a Nexus instance via the REST APIs.

The following script is written in Ruby and uses the REXML XML processor and the Net:HTTP library. Both of these libraries are available in the Ruby standard library. I tested these Ruby scripts using a standard Ruby 1.8.7 distribution. If you want to try these scripts out on your own, they will run in any standard Ruby interpreter without requiring any extra RubyGems.

Here’s the script, we’ll walk through some of the highlights after the source:

So, what’s going on in this script?

• Lines 7-15: Define some simple variables like host, port, the root URL of Nexus. We also define the status string “OUT_OF_SERVICE”. If we ran this script and then wanted to bring all hosted repositories back online, we would change this string to “IN_SERVICE”.
• Lines 17-21: Get a list of all repositories as an XML document and parse it. All Nexus REST services can return either XML or JSON, the default response if no “Content-type” header is present in the request is “application/xml”. This is a simple HTTP GET which does not require any authentication. You can find detailed documentation for the /service/local/repositories service here.
• Line 24: We’re only interested in manipulating hosted repositories. This line applies the XPath query “//repositories-item[repoType='hosted']” to the XML document and passed matching nodes to a large block that operates on each matching repository element.
• Lines 26-29: Just print out the id of each repository and the URL.
• Lines 31-34: Retrieve the status of a repository using the repository identifier. Again, this is a simple HTTP GET that does not require any authentication information. It returns an XML doc that describes the current status of the repository. Detailed documentation for the “/service/local/repositories/{repositoryId}/status” can be found here.
• LInes 36-41: Now here’s where it gets a bit fancy. The REST call to get the status was an HTTP GET, which returns an XML document. The REST call to set the status is an HTTP PUT, which accepts the same XML document. To set the repository status, we’re going to use the XML returned by a GET call to the status service and just change the “localStatus” element to either “IN_SERVICE” or “OUT_OF_SERVICE”. The statement on line 38, simply sets the value of this element in the XML document which was returned by the previous GET.
• Lines 43-50: Changing the status of a repository requires the proper privileges. For this call, we’ll need to supply the credentials set in the initial portion of the script. We will also need to make an HTTP PUT call and pass the XML document for repository status as the request body. While Nexus REST defaults to an XML response if no Content-Type is specified for simple HTTP GET calls, our HTTP PUT call to the repository status service must set the request’s “Content-Type” header to “application/xml” for status to be updated. The request body is set to the XML, which was modified on line 38, and the request is made on line 50.

That’s it. While this particular script isn’t much, it should provide a template for those of you who are interested in starting to automate common tasks via the Nexus REST API.

OPEN CHALLENGE: This this script is too verbose? Create your own Gist on GitHub.com and point to it in the comments. I’d love to see what other people could do with this sample. Expect a lot of follow-up posts to this, as we’re really interested in developing a large library of scripts for people to use.

The following scripts are in Ruby and they use the REXML XML processor and the Net:HTTP library.  Both of these libraries are available in the Ruby standard library.   I tested these Ruby scripts using the latest JRuby release.  If you want to try these scripts out on your own, they will run in any standard Ruby interpreter without requiring any extra RubyGems.

The Nexus REST API

The UI of Nexus is written in ExtJS and it makes heavy use of AJAX callbacks to REST services.  In fact, if you load up Nexus in a tool like Firebug, an extension for Firefox which allows you to trace all network activity, you will see that almost every action in Nexus triggers a call to a REST service.  We’re going to focus on just two services in this post: list repositories and searching for artifacts, but you should know that there are hundreds of things you can do to Nexus via the various REST interfaces that are available.  In fact, you could create a custom UI tailored to your own needs that interfaces with Nexus via this REST backend.    In addition to the REST services in the core Nexus installation, you can extend Nexus and add in your own REST services via a Nexus plugin.  The Nexus UI is completely decoupled from the set of services Nexus provides, and the services which Nexus provides can be extended.

The Nexus REST Services are documented here.  In this post, we’re going to be writing scripts that hit the public instance of Sonatype Nexus at http://repository.sonatype.org, our REST URLs are going to look something like this: http://repository.sonatype.org/service/local/data_index?q=maven.  If you were attempting to hit the services on your local Nexus installation, your REST URL would look more like this: http://localhost:8081/nexus/service/local/data_index?cn=HibernateDaoSupport.   These REST URLs follow the pattern:  “http://{host}:{port}/{context}/service/{instance}/{service}?{query_params}” where the {instance} will almost always be “local”.

If you would like to download the sample scripts in this blog post, you can download this ZIP file which contains four Ruby scripts: http://books.sonatype.com/tutorial-files/nexus-rest-ruby.zip

Listing Repositories

The first script simply lists all of the repositories in a Nexus installation.  Here it is:

require 'net/http'
require 'rexml/document'
include REXML
 
url = 'http://repository.sonatype.org/service/local/repositories'
resp = Net::HTTP.get_response( URI.parse( url ) )
 
doc = REXML::Document.new( resp.body )
 
XPath.each( doc, "//repositories-item" ) do |r|
  puts "#{r.elements["name"].text}(#{r.elements["id"].text})"
  puts "\t" + r.elements["resourceURI"].text + "\n\n"
end

This script sets the pattern for the scripts to follow.  We construct a URL in the script (a more general script would read this from a config file), then we make the request using Net::HTTP and we parse the results with REXML by passing it to the Document constructor.  At this point, I use XPath to select all of the repositories and I print out the name, id, and the URL of the repository as served by Nexus.

This post is simply a pointer to the service and a quick demonstration so I’m not going to dive into the meaning of every single element in the XML document returned by the repositories service.   If you are interested in see the full set of elements that are available, load up the results of this service in a web browser by click on this: http://repository.sonatype.org/service/local/repositories.

Performing a “Quick Search”

require 'net/http'
require 'rexml/document'
include REXML
 
url = 'http://repository.sonatype.org/service/local/data_index?q='
resp = Net::HTTP.get_response( URI.parse( url + ARGV[0]) )
 
doc = REXML::Document.new( resp.body )
 
XPath.each( doc, "//data/artifact" ) do |r|
  puts "#{r.elements["groupId"].text}:#{r.elements["artifactId"].text}:#{r.elem\
ents["version"].text}"
end

This script follows the pattern of the previous script to list all repositories with the exception that it reads an argument from the command line.   This script performs a quick search by hitting the data_index service and passing in the q parameter.   This script simply prints out the groupId:artifactId:version of all the artifacts located.

If you would like to see an example of the XML that this service produces click here: http://repository.sonatype.org/service/local/data_index?q=activemq. In the full results, you’ll see more information such as the number of search hits available, the resource URL for each artifact found, and the context (or repository) in which the artifact is available.

Searching by Class Name

require 'net/http'
require 'rexml/document'
include REXML
 
url = 'http://repository.sonatype.org/service/local/data_index?cn='
resp = Net::HTTP.get_response( URI.parse( url + ARGV[0]) )
 
doc = REXML::Document.new( resp.body )
 
XPath.each( doc, "//data/artifact" ) do |r|
  puts "#{r.elements["groupId"].text}:#{r.elements["artifactId"].text}:#{r.elem\
ents["version"].text}"
end

This script is almost exactly the same as the prior script that performed a quick search.  The difference in this script is that instead of passing the q parameter, this script passes the cn parameter.   Passing the cn parameter causes Nexus to search for artifacts which contain classes that match the given value.   The results are going to look the same as the quick search query script.     To see the XML yourself, search for all artifacts which contain a class named HibernateDaoSupport: http://repository.sonatype.org/service/local/data_index?cn=HibernateDaoSupport.

Performing a GAV Search

require 'net/http'
require 'rexml/document'
include REXML
 
url = "http://repository.sonatype.org/service/local/data_index?g=#{ARGV[0]}&a=#\
{ARGV[1]}&v=#{ARGV[2]}"
resp = Net::HTTP.get_response( URI.parse( url ) )
 
doc = REXML::Document.new( resp.body )
 
XPath.each( doc, "//data/artifact" ) do |r|
  puts "#{r.elements["groupId"].text}:#{r.elements["artifactId"].text}:#{r.elem\
ents["version"].text}"
end

This final script takes three command line arguments: groupId, artifactId, version, and it performs a GAV (groupId, artifactId, version) coordinate search over the repository.