Nexus Plugin API


January 22, 2009 By Brian Fox

In several of the Nexus Pro blog posts, we have mentioned that the Pro features are just plugins to the OSS Core, but we haven’t formally discussed it yet.  This blog post is an attempt to introduce the Nexus Plugin API.

Most of the architectural work being done to Nexus in the 1.1, 1.2, 1.3 releases has been done to build and enhance the plugin model and convert existing 1.0 features to the new model. Right now a Nexus plugin is essentially a jar containing plexus components and resources such as Javascript alongside a simple descriptor.   Nexus plugins are able to add new REST services, add components that affect a request, and even add new UI elements and menu options to the user interface.  A look at the functionality defined by each of the Pro features gives a good overview of how significant a plugin can be:

  • LDAP – The LDAP plugin contributes a new security realm, associated REST services, privileges and extends the existing ajax ui panels.
  • Staging & Promotion – This plugin contributes a whole new type of Nexus Managed repository and REST resources / UI to manage it. What’s different about this plugin is that it is able to hook into the configuration and create/delete repositories on the fly and the core can still understand the existence of the repos.
  • Procurement – This plugin also adds REST, privileges, new UI panels like the others. It goes a step further and introduces a new remote repository type to handle the plugin firewall logic.
  • P2 Proxy – This plugin contributes entirely new repository content types to handle P2. So now instead of just M1/M2 you get P2 as well. Following this model, a plugin could add content types for things like RPMs, Ruby Gems, etc.

Plugins are also able to:

  • Attach to the event system and process incoming streams in real time
  • Introduce new scheduled tasks (new repo types are able to communicate with the scheduled tasks to prevent certain things from occuring — for example the Procurement repo blocks out any purge tasks regardless of the source)
  • Extend any UI panel and introduce new ones with left nav items
  • Override or redefine existing ui resources
  • …and, much, much more… the entire Nexus system is comprised of Plexus components that can be rewired on-demand

The current plugin model requires a restart of Nexus to introduce new plugins.   Jason has built a plugin manager based on the Maven plugin model and work is already underway to integrate this into Nexus 1.4. The plugin manager will allow plugins to be loaded/unloaded/reloaded in real time without restarting the system. Full API documentation and examples is under construction and will be covered in future versions the Nexus Book.

Extending Nexus with Plugins

All further functionality we build, both OSS core and Pro will be built as a plugin, which means the plugin model will expand and become more robust over time. It’s not an unused API sitting idle.

Justin Edelson has already come forward with a Crowd plugin for Nexus and a release is imminent in the Sonatype Forge – Nexus Plugins project. This will be a significant milestone as it represents the first plugin built and released entirely outside the core Nexus team.  There have also been a number of simple LDAP plugins created by third-parties, and while we certainly believe that our own LDAP is more capable the fact that there are already competing options is a testament to the flexibility of the product.

If you have a Nexus plugin or want to write one, please ping us on the Nexus Developer list. We will provide SVN, Jira, Confluence and Nexus repository services via the Sonatype Forge to support this effort.