Tag Archives: plugins

Writing a Nexus Plugin Using m2eclipse


January 8, 2010 By Damian Bradicich

nexus-small

In this post, I’m going to walk you through the process of creating a new Nexus plugin using the m2eclipse plugin for eclipse from start to finish including all steps in the process.  After reading this post you will know about the easiest way to get started working on your own Nexus plugin.

Some things to note are that I am using the latest m2e 0.9.9 dev build available from the http://m2eclipse.sonatype.org/update-dev update site. I am also using eclipse 3.5.1.  All maven builds have been done using local build of latest maven 3.0-SNAPSHOT, however, that is not a requirement for the plugins to work, just a recommendation as maven 3 (in my opinion) is much better than maven 2 :)

Continue reading →

Writing Plugins for Nexus (Part 1)


June 3, 2009 By Tamas Cservenak

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.

Continue reading →

How to make a plugin that runs once during a build


May 22, 2009 By Brian Fox

With it’s default behavior, Maven runs a plugin invocation for each project in a multi-module build. For plugins that operate on a single project at a time, this is what the author wants.

Some plugins are what we call “aggregators” which means they actually do want all the information about the full multi-module build before execution. These plugins, when run on a tree of projects cause Maven to resolve all the children before calling the plugin’s execute() method. In this mode a plugin executes just once, but effectively on the whole tree at once. (as a side note, you never want to bind an aggregator goal in your pom as this would cause the plugin to run an n! recursive build since the lifecycle would step into each child and execute the aggregator…which would cause Maven to reresolve all the children, etc)

Continue reading →

Maven: Integration and Distributed, Open Innovation


May 8, 2009 By Tim O'Brien

Brian Murphy wrote a long blog post about the PAX Plugin which provides a good example of the power of Maven to act as an integration “bridge” between a number of unrelated technologies. In this post, Brian is using the PAX Maven Plugin from ops4j together with the gmaven-plugin and the maven-scala-plugin, he concludes with praise for Maven as an essential time saver:

“This ended up being a much longer article than I anticipated but we’ve covered a lot of ground. Maven has worked it’s dependency voodoo which saved an enormous amount of time downloading jars and messing with classpaths. We’ve seen how the PAX toolkit from OPS4J makes creating, modifying and provisioning OSGi bundles a breeze. While the actual code examples were pretty trivial, we successfully managed to code up bundles in Java, Scala and Groovy. I think this displays a lot of the power that is offered by OSGi and points to a bright future for enterprise development on the JVM.”

Continue reading →