<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

Tamas Cservenak

Recent Posts by Tamas Cservenak:

Documenting the Nexus REST API with Enunciate

Nexus OSS Core has more than 120 REST Resources published. And that number is just increasing with new Nexus Plugins. Not to mention Nexus Pro that comes with even more plugins and more REST resources. Everything you do in Nexus, whether you use the Maven Nexus plugin or the Nexus UI, is interacting with a REST service that is available to you if you want to write your own customizations and scripts. It has been this way since we started the project in 2007. In this post, I'm going to discuss how this came to be, how Nexus was developed with REST in mind from the beginning.

Nexus: A Core of REST Services

When we started the Nexus project, I called it a "blind" application. A "blind" webapp is one with no UI technology whatsoever built-in. All it publishes is a few static files, and a REST API. All of the UI that you see in Nexus is Javascript. Your browser executes Javascript which, in turn, interacts with a set of services. The only presentation technology on the server side is a trivial Velocity template used to render the initial "shell" of the page.

How to Control Nexus Groups with Effective Routing Rules

When you run a repository manager you will likely want to control which artifacts developers have access to. Maybe you also want to try to speed up your builds and reduce the time it takes to find and retrieve the artifacts needed in your build. You might be looking for an easy way to filter out junk artifacts that you don't want to involve in your build. If you are trying to do any of these things, you'll need to know how to configure routing rules in Nexus. In this blog post, I walk through routing rules and provide some answers for people interested in using routing rules to gain more control over repositories in Nexus.

Writing Plugins for Nexus (Part 2)

As we said in first part of Nexus Plugins blog, Nexus itself is a Plexus application, we are quickly moving to OSGi runtime platform. The target for this new architecture is most probably Guice + Peaberry, a cool container and it's cool extension.

Okay, but will we need to rewrite every plugin after the migration happen? Well, hopefully no. This is actually the reason, why are we in hurry defining the Plugin API and plugin development environment as much as possible in a way, to make this migration as seamless as possible to plugin developers (core developers are already prepared for this challenge). In short, we are Nexus plugins from having to know anything of Plexus.

In perfect world, a plugin written today using this technique, against today's Nexus (powered by Plexus) should work without any problem after 6 months and the release of Nexus (powered by Guice + Peaberry). All you would have to do, is simply take your plugin bundle (a self-contained and self-sufficient package of the plugin) and move it from one Nexus to another. That's it.

Again, this is our "ultimate goal", but as with all software, we can't predict any tumbler. We are trying hard, at least. The rest of this post provides more guidance on writing Nexus plugins with some hints for how to prepare for the transition to OSGi.

Writing Plugins for Nexus (Part 1)

Nexus is a Plexus application, it uses Plexus as a container. As we are well aware, Plexus isn't the only Depedency Injection framework currently available. We decided to design the Nexus plugin mechanism to allow for extensibility in a container independent way. If you want to write a plugin for Nexus (and possibly all other Sonatype products) you don't need to pick up a book on Plexus, we're trying to make it easier for someone to innovate on the Nexus platform without having to adopt a whole series of technologies.

This post covers some of the initial steps, that are required to write a plugin for Nexus. Although Nexus is a Plexus application, we want to give 3rd party developers ability to extend Nexus, without forcing them to know Plexus. We also want to give 3rd party developers the ability to extend Nexus, without burying themselves into Nexus internals. Clearly if someone wants to add complex, highly custom behavior to Nexus they will need to dive into the internals, but it should be easy to add a simple extension to Nexus without having a PhD in Nexus Internals. We are also committed to adopting 3rd party "specs/suggestions/APIs" that look promising, even if it comes from another IoC provider.

Now, let's replace the "Nexus" in above sentences with "Sonatype Application" in the sentences above. It's not so different, right? At Sonatype, we're convinced that providing an intuitive plugin and extension mechanism is critical for adoption and we want to make it as straightforward as possible. To start this discussion, we need first a look at how Plexus works.

A tour of the Nexus repository internals

As part of the Nexus 1.3 release we revamped internals which makes for some interesting feature possibilities. Let's take a look at what's now available in the Nexus system.

A Late Report on a Late Event

It's been more than a year that I'm working for Sonatype (mainly on Nexus), the successor of Proximity. It was a great year, spent with cool people, and with great events like (in order as they happened):