Over the last month or so I have been working on adding OSGi Bundle Repository (OBR) support to Nexus Professional, and I am happy to announce this feature will be available in the 1.3.5 release. But what exactly is OBR and why should you care?
OBR has been around since 2006, it defines a small XML schema and Java API that allows clients to discover and deploy OSGi bundles by matching capabilities with requirements. Distributors provide XML describing their bundles, and this is used by OBR service implementations running on OSGi frameworks. Management clients talk to their local OBR service using the Java API.
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.”
From the very beginning we positioned [Tycho] as the tool for doing Eclipse/OSGi development with Maven. Even though Tycho originally focused on build automation, we think it is time to extend its functionality, as well as integrating it with other projects, to support the full Eclipse/OSGi application development lifecycle.
Below is a preliminary list of key features we want to implement. We want to know if it looks useful, or if we’re totally off base. What other features and improvements are needed to make Tycho a turnkey solution for Eclipse/OSGi development?
Target platform management
In a previous post entitled m2e Roadmap, Jason discussed Sonatype’s commitment to quality and testing for m2eclipse. As a follow-up, I did a quick interview with Rich Seddon and asked him some questions about Sonatype’s approach to testing for Eclipse plugins. The interview is approximately five minutes long and in this interview, you’ll here Rich give some detailed descriptions of the tools he uses to test the m2eclipse plugin.
[media id=1 width=320 height=70]
Yesterday’s post was in response to a question from Anders Nawroth of the Neo4J effort, and today’s post is no different. On Tuesday (or maybe it was Monday), Anders asked the neo4j-users list whether it made sense to build the neo4j eclipse plugin with Maven.
I have looked into building Neoclipse using Maven, but at the moment I’m not convinced there are more advantages then disadvantages in this case. Building Eclipse plugins and products has quite many quirks. With increasing use of product configuration options, the number of build quirks increases as well.
There seems to be no really automated build system for Eclipse plugins/products, even when using maven you have to install and update the dependencies manually (the Eclipse artifacts are not deployed to a maven repository).
Sonatype is busily working to address these gaps, and we already have some solutions you can use to start building your Eclipse plugins in Maven. Igor Fedorenko has been working on Tycho and Maven to create a system to facilitate OSGi and Eclipse development in Maven, and m2eclipse is currently built using Tycho. To prove that Tycho is a viable path for build the Neoclipse plugin, I took some time yesterday to generate Maven pom.xml files with Tycho and build an update site for Neoclipse. Continue reading