Thanks again to all of the attendees and participants at the Sonatype and Eclipse Maven Meetup and DemoCamp last week.  It was a great event, and the Sonatype team is looking forward to the next Maven Meeetup.  There are some exciting events coming up in the next few months that Sonatype will be attending.  Keep reading to see the tentative schedule.  Hopefully we will be at an event near you.

Upcoming events:

Eclipse DemoCamp – Toronto, Ontario – June 29, 2010

JavaZone – Oslo, Norway – September 8-9, 2010

JavaOne – San Francisco – September 19-23, 2010

OSGI  Community event – London, U.K – September 29-30, 2010

NewYork JavaSIG Meetup – New York – October 2010

Eclipse Summit Europe – Ludwigsburg, Germany – November 2010

Eclipse Day Paris – Paris – November 2010

Have your say – Take part in our poll below:

April 7, 2010 Sonatype is hosting a Maven Meetup in downtown Philadelphia ahead of Emerging Technology for the Enterprise.  Take part in presentations given by the developers who are building the Maven software you will be using in the future.  Registration is filling up fast, there are only a few seats left.  Learn about Apache Maven, Hudson, Nexus, Sonar, Felix, OSGi, Tycho, Selenium, and more.  Visit www.sonatype.com/meetup2010 for more information about presentations and registration.

Maven Meetup April 7, 2010 8:00 AM – 5:00 PM Sheraton Society Hill (downtown) Philadephia, PA

Choose from a range of sessions presented by the Maven developers.  Sessions will include:

• Maven in the Enterprise
• Git, JGit & EGit
• OSGi Runtimes
• OSGi Provisioning with P2
• Nexus
• Moving from Plexus to Guice
• Hudson
• Tycho: Enterprise OSGI Builds
• m2eclipse
• Selenium
• Peaberry
• Nexus & OSGi

Join us for an interactive BoF session at the end of the day, followed by a reception where you’ll get to spend time in casual discussions.

20% Discount

Register by Monday April 5th and receive a 20% discount on the the $190 standard registration rate. Visit www.sonatype.com/meetup2010 to register or for more information. Register using the code PJUG20 to receive your discount.

Bring a Colleague for Free

Register one attendee by Monday April 5th at the $190 standard registration rate, and have a colleague join you at no charge. Visit www.sonatype.com/meetup2010 to register or for more information. When you register, add “+1” after your name to receive the special promotion pricing for you and a friend.

Seating is limited

It’s not too late to register for the Sonatype Maven Meetup taking place on April 7, 2010 ahead of Emerging Technologies for the Enterprise in Philadelphia.  Meet with Maven aficionados, sit in on presentations about Maven 3, Tycho, OSGi, Peaberry, and much more.

Choose from a dozen different sessions throughout the day, presented by the developers who are building the Maven software you’ll be using in the future.  Join us for an interactive BoF session at the end of the day, followed by a reception.

Special Promotion — Bring a Friend for Free

Register one attendee at the $190 standard registration rate, and have a friend join you at no charge.

Visit www.sonatype.com/meetup2010 to register or for more information.  When you register, add “+1″ after your name to receive the special promotion pricing for you and a friend.

Seating is limited

This post is a quick start guide to using the Maven PAX plugin to create OSGi project and start an OSGi runtime environment (Apache Felix). First, use the Maven Pax Plugin from OPS4J, and call the create-project goal. The following command-line will create a multi-module project with a groupId of org.sonatype.mhandbook, an artifactId of osgi-project, and a version of 1.0-SNAPSHOT:

~/examples/osgi $ mvn org.ops4j:maven-pax-plugin:create-project \
  -DgroupId=org.sonatype.mhandbook \
  -DartifactId=osgi-project \
  -Dversion=1.0-SNAPSHOT
[INFO] Scanning for projects...
[INFO] artifact org.ops4j:maven-pax-plugin: checking for updates from central
[INFO] Building Maven Default Project
[INFO]    task-segment: [org.ops4j:maven-pax-plugin:create-project] (aggregator
-style)
[INFO] [pax:create-project]
[INFO] Selecting latest archetype release within version range [1,2)
[INFO] artifact org.ops4j.pax.construct:maven-archetype-osgi-project: checking
for updates from central
[INFO] Using following parameters for creating Archetype: maven-archetype-osgi-
project:1.0.3
[INFO] Parameter: packageName, Value: org.sonatype.mhandbook.osgi-project
[INFO] Parameter: archetypeVersion, Value: 1.0.3
[INFO] Parameter: groupId, Value: org.sonatype.mhandbook
[INFO] Parameter: archetypeArtifactId, Value: maven-archetype-osgi-project
[INFO] Parameter: version, Value: 1.0-SNAPSHOT
[INFO] Parameter: archetypeGroupId, Value: org.ops4j.pax.construct
[INFO] Parameter: basedir, Value: ~/examples/osgi
[INFO] Parameter: package, Value: org.sonatype.mhandbook.osgi-project
[INFO] Parameter: artifactId, Value: osgi-project
[INFO] ********************* End of debug info from resources from generated POM
[INFO] Archetype created in dir: ~/examples/osgi/osgi-project

Once you’ve generated an OSGi project using the Pax Plugin, you will have the following directory structure:

If you want to verify that you can build the project successfully, run mvn clean install:

~/examples/osgi/osgi-project $ mvn clean install
[INFO] Reactor build order:
[INFO]   org.sonatype.mhandbook.osgi-project (OSGi project)
[INFO]   osgi-project - plugin configuration
[INFO]   osgi-project - wrapper instructions
[INFO]   osgi-project - bundle instructions
[INFO]   osgi-project - imported bundles
[INFO] ------------------------------------------------------------------------
[INFO] Building org.sonatype.mhandbook.osgi-project (OSGi project)
[INFO]    task-segment: [clean, install]
[INFO] ------------------------------------------------------------------------
[INFO] [clean:clean]
[INFO] [site:attach-descriptor]
[INFO] [install:install]
[INFO] Installing ~/examples/osgi/osgi-project/target/pom-transformed.
xml to ~/.m2/repository/org/sonatype/mhandbook/osgi-project/1.0-SNAPS
HOT/osgi-project-1.0-SNAPSHOT.pom
[INFO] ------------------------------------------------------------------------
[INFO] Building osgi-project - plugin configuration
[INFO]    task-segment: [clean, install]
...

Instead of executing these goals manually, you can also download and install the Pax-Construct scripts which can be used to automate the process of creating a new OSGi project with the Pax plugin. For more information, see the Pax Construct Quickstart page.

The generated multi-module project structure contains a parent project with the supplied groupId, artifactId, and version, and a few submodules:

• osgi-project/pom.xml This is the parent POM
• osgi-project/poms/compiled/pom.xml This POM serves as the parent POM to all of the compiled OSGi components you will add to this osgi-project Maven project.
• osgi-project/poms/wrappers/pom.xml If you can’t find a particular library as an OSGi component, the Pax Construct tools allow you to wrap an existing dependency artifact into an OSGi bundle. The configuration for these wrapped bundles is stored in this POM.
• osgi-project/provision/pom.xml This POM configures the Apache Felix runtime environment that you can start by running the pax:provision goal. If you need to import a bundle into your runtime environment, this is the POM that contains a reference to the corresponding Maven dependency.

To start the Apache Felix container, run mvn install pax:provision from the osgi-project/ directory:

~/examples/osgi/osgi-project $ mvn install pax:provision
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   org.sonatype.mhandbook.osgi-project (OSGi project)
[INFO]   osgi-project - plugin configuration
[INFO]   osgi-project - wrapper instructions
[INFO]   osgi-project - bundle instructions
[INFO]   osgi-project - imported bundles
...
[INFO] [pax:provision]
[INFO] ~~~~~~~~~~~~~~~~~~~
[INFO]  No bundles found!
[INFO] ~~~~~~~~~~~~~~~~~~~
    ______  ________  __  __
   / __  / /  __   / / / / /
  /  ___/ /  __   / _\ \ _/
 /  /    /  / /  / / _\ \
/__/    /__/ /__/ /_/ /_/
Pax Runner (1.0.0) from OPS4J - http://www.ops4j.org
----------------------------------------------------
 -> Using config [classpath:META-INF/runner.properties]
 -> Using only arguments from command line
 -> Scan bundles from [~/examples/osgi/osgi-project/runner/deploy-pom.xml]
 -> Scan bundles from [scan-pom:file:/~/examples/osgi/osgi-project/runner/deplo
y-pom.xml]
 -> Preparing framework [Felix 1.8.0]
 -> Downloading bundles...
 -> Using execution environment [J2SE-1.5]
 -> Runner has successfully finished his job!
Welcome to Felix.
=================
-> 

When you started up Felix, notice that the line directly following the execution of the pax:provision goal says “No bundles found!”. By running pax:provision, you’ve started the Felix OSGi service platform. Felix uses the configuration from a properties file and then scans two deploy-pom.xml files for bundles that it should download and install. Finding none, it presents a simple prompt and awaits orders. At this point, we have an empty container that isn’t running any custom logic or downloading any OSGi bundles.

Once you have the console for Felix loaded, you can control the platform, load components from remote repositories, list all of the running components, and start and stop components. Try executing the command help to see a list of available commands:

-> help
bundlelevel   ... |  - set or get bundle start level.
cd []                     - change or display base URL.
exports  ...                    - list exported packages.
headers [ ...]                  - display bundle header properties.
help                                - display impl commands.
imports  ...                    - list imported packages.
install  [ ...]           - install bundle(s).
ps [-l | -s | -u]                   - list installed bundles.
refresh [ ...]                  - refresh packages.
requirers  ...                  - list requiring bundles.
requires  ...                   - list required bundles.
resolve [ ...]                  - attempt to resolve the specified bundles.
scr help                            - Declarative Services Runtime
services [-u] [-a] [ ...]       - list registered or used services.
shutdown                            - shutdown framework.
start [-t]  [  ...]    - start bundle(s).
startlevel []                - get or set framework start level.
stop [-t]  [ ...]           - stop bundle(s).
uninstall  [ ...]           - uninstall bundle(s).
update  []                 - update bundle.
version                             - display version of framework.

If you execute the ps command, you can see a list of bundles with IDs that are running in the Felix container. You can start and stop bundles by running start and stop followed by the ID of the specific bundle you want to control. You can also install and uninstall bundles in the running container.

For more information, read the OSGi chapter in the Maven Handbook, it will walk you through the process of creating a new OSGi project and importing OSGi bundles into an OSGi container.

We’ve released a pre-alpha version of the Maven Cookbook which contains a chapter on OSGi development with Maven via the Pax plugin from OPS4J. This chapter contains a series of recipes which will walk you through the process of creating an OSGi project, importing bundles from both a Maven repository and existing OSGi Bundle Repositories (OBR), and executing an OSGi runtime environment all with the help of the Maven Pax Plugin. The last few chapters provide a road map for developers interested in hosting and combining multiple Maven and OBR repositories into a single repository group with Nexus.

To read the pre-alpha, version 0.1.1 release of the Maven Cookbook, you can:

• Read the Maven Cookbook on Scribd
• Read the Cookbook Online
• Download a PDF of the Maven Cookbook

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.

Example

Here’s a concrete example, the Apache Felix project has XML describing their bundle releases:

http://felix.apache.org/obr/releases.xml

They also provide an OBR service implementation that works on any R4 OSGi framework:

<dependency>
  <groupId>org.apache.felix</groupId>
  <artifactId>org.apache.felix.bundlerepository</artifactId>
  <version>1.4.0</version>
</dependency>

Let’s see OBR in action!

1. Go to http://felix.apache.org/site/downloads.cgi and download the 1.8.0 distribution
2. Extract Felix 1.8.0 to a local temporary directory
3. cd felix-1.8.0
4. java -jar bin/felix.jar

You should see the Felix command shell, type obr to see the available OBR commands:

 Welcome to Felix.
 =================
 -> obr
 obr help [add-url | remove-url | list-url | list | info | deploy | start | source | javadoc]
 obr add-url [<repository-file-url> ...]
 obr refresh-url [<repository-file-url> ...]
 obr remove-url [<repository-file-url> ...]
 obr list-url
 obr list [-v] [<string> ...]
 obr info <bundle-name>|<bundle-symbolic-name>|<bundle-id>[;<version>] ...
 obr deploy <bundle-name>|<bundle-symbolic-name>|<bundle-id>[;<version>] ...
 obr start <bundle-name>|<bundle-symbolic-name>|<bundle-id>[;<version>] ...
 obr source [-x] <local-dir> <bundle-name>[;<version>] ...
 obr javadoc [-x] <local-dir> <bundle-name>[;<version>] ...

This service is pre-configured to use the Felix OBR, to see a list of released bundles type:

 -> obr list
 Apache Felix Bundle Repository (1.2.1, ...)
 Apache Felix Configuration Admin Service (1.0.4, ...)
 Apache Felix Declarative Services (1.0.8, ...)
 Apache Felix EventAdmin (1.0.0)
 Apache Felix File Install (1.2.0, ...)
 Apache Felix HTTP Service Jetty (1.0.1, ...)
 Apache Felix iPOJO (1.2.0, ...)
 Apache Felix iPOJO (0.8.0)
 Apache Felix iPOJO Arch Command (1.2.0, ...)
 Apache Felix iPOJO Composite (1.2.0)
 Apache Felix iPOJO Composite (1.0.0, ...)
 Apache Felix iPOJO Event Admin Handler (1.2.0, ...)
 Apache Felix iPOJO Extender Pattern Handler (1.2.0)
 Apache Felix iPOJO Extender Pattern Handler (1.0.0, ...)
 Apache Felix iPOJO JMX Handler (1.2.0, ...)
 Apache Felix iPOJO Temporal Service Dependency Handler (1.2.0, ...)
 Apache Felix iPOJO White Board Pattern Handler (1.2.0, ...)
 Apache Felix Log Service (1.0.0)
 Apache Felix Metatype Service (1.0.2, ...)
 Apache Felix Prefrences Service (1.0.2)
 Apache Felix Remote Shell (1.0.2)
 Apache Felix Shell Service (1.0.2, ...)
 Apache Felix Shell TUI (1.0.2, ...)
 Apache Felix UPnP Base Driver (0.8.0)
 Apache Felix UPnP Extra (0.4.0)
 Apache Felix UPnP Tester (0.4.0)
 Apache Felix Web Management Console (1.2.10, ...)
 OSGi OBR Service API (1.0.0)
 OSGi R4 Compendium Bundle (4.0.0)
 Servlet 2.1 API (1.0.0)
 ->

Say we’re interested in the Felix Web Management Console, to deploy and start this bundle type:

 -> obr start 'Apache Felix Web Management Console'
 Target resource(s):
 ------------------–
    Apache Felix Web Management Console (1.2.10)
 Required resource(s):
 --------------------–
    Apache Felix HTTP Service Jetty (1.0.1)
    OSGi R4 Compendium Bundle (4.0.0)
    Apache Felix Log Service (1.0.0)
    Apache Felix Declarative Services (1.0.8)
 Deploying...org.mortbay.log:Logging to org.mortbay.log via org.apache.felix.http.jetty.LogServiceLog
 org.mortbay.log:Init SecureRandom.
 done.
 ->

Notice the OBR service was able to deduce we needed other bundles to successfully run the Web Management Console, and it automatically deployed and started them as well. To prove that the Web Console is now up and running, go to http://localhost:8080/system/console/ and log on using admin as both the user-id and password.

Nexus Pro

That should have given you a taste of OBR, but how does this relate to Nexus Professional?

Well with Nexus Pro 1.3.5 you will be able to:

1. dynamically generate OBR metadata for your existing repositories
2. proxy and cache remote OBRs, including both metadata and bundles
3. host local OBRs and deploy bundles into them using the UI or Maven
4. group all of the above types of OBRs into a single merged OBR
5. apply CRUD privileges to control access to particular bundles

Basically the same things you can do with Maven and P2 repositories you can now do with OBR!

This screencast shows how you can quickly build up and use OBR metadata using Nexus Professional 1.3.5. We have also been able to reconstruct the OSGi Alliance repository in a matter of minutes by proxying known public sites and grouping them into a single OBR.

Future

What does the future hold for OBR? Well although it’s existed as a draft specification since 2006, it has not yet been formally standardized by the OSGi Alliance. Since then alternative approaches have appeared, such as P2. The OSGi Alliance have therefore decided to revisit the original requirements and see where OBR can be improved, given what we know now about deploying large applications in OSGi.

So the final OBR specification might vary from the current draft, but if you use Nexus Professional to manage and generate your OBR metadata this shouldn’t bother you. The repository abstraction in Nexus makes it very easy to add support for new metadata formats, which means we will be able to support both the old and new formats as required.

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.”

Project-driven Plugins: Distributed, Open Innovation

In this case Maven is bridging a number of popular projects that have all created well-documented Maven plugins. Maven is the essential “glue” that allows someone like Brian to take a number of unrelated technologies and use them in ways that the designers of GMaven or the Scala plugin could never have predicted. As Maven matures and continues to evolve its Plugin API, we’re starting to see more projects and more systems commit to using it as an enabling “platform” for development. Those projects that have adopted Maven have found it beneficial to host and drive the Maven plugins that relate to their project or technology. Better support for Maven increases the adoption of Groovy, Scala, and (in this case) OSGi.

The PAX plugin is maintained and hosted by the Ops4J project, the Scala plugin is hosted and maintained by the Scala community, and the GMaven plugin is hosted and maintained by the Groovy community. Each community feels strongly enough about providing Maven support for their technology that they have made it a part of their project. This is important because it suggests an evolving approach to the way Maven plugins are created and supported. Four years ago, it was unlikely to see a project like Scala or Ops4J creating and hosting a Maven plugin. While Maven was already ubiquitous, projects still didn’t see Maven support as a primary concern. Instead, the plugin development would happen as part of the Maven community or in an ancillary community of Maven plugins known as the Mojo project at Codehaus.

Mojo is an important bridge. It allows third-party actors to craft support for tools like JBoss and GWT, but it is an aggregate, disjoint community with a single mailing list, perfunctory release votes, and little shared discussion about architecture or planning. It is a free-for-all. While Mojo does host some essential plugins it is also a dumping grounds for half-finished, owner-less plugins. As more projects provide their own Maven support, people should consider moving project from Mojo to the projects that develop the specific technologies in question. This is the “distributed” open innovation that will encourage quality, well-documented plugins.

Why Companies and Projects Need to “Own” Their Maven Support

We’ve transitioned into a point where projects need to start hosting and owning the Maven plugins that enable developers to use their software. Google would have been better off if they had invested a day or two crafting a solid Maven plugin for AppEngine before they announced Java support. Similarly, they should think about driving the development of the GWT plugin. If your project’s artifacts are available through the Central Maven repository, that is a first step, but if your project also publishes an artifact and a really compelling Maven plugin, you’ve made it trivial and easy for people to adopt your technology. “Going to market” without good Maven support no longer makes sense, and you should know that more and more developers are start with the question “how does this fit into my Maven build?” If your answer is “shrug, we don’t use Maven”, it is very likely that they will seek out other solutions that provide better integration.

If you are a tool vendor or create an open source framework, you should be hosting your own Maven plugin as a part of your project. If you support an SCM like Perforce or Clearcase, you should make sure that your software provides a solid SCM provider for Maven. If your company or project develops a server, you should be working with the Maven project to make sure that it integrates with Maven. To do otherwise is to invite your customers or users to look elsewhere for better integration. If you let someone else drive your Maven plugin, you are really just delegating an essential support function to the community. The message you are sending is, “we don’t really care that you use Maven, it isn’t a priority, someone will do the integration work for us”. This is true, but when that happens, you lose an opportunity to interact with your users and your customers.

PS: Brian’s post also inspired me to file this JIRA issue on the MVNDEF book project. Our book’s need code examples that can be more easily copied to the clipboard.

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 addition to Maven, support Eclipse/P2 repositories.
• Seamless roundtrip between local and remote artifact repositories. We need to easily consume and publish artifacts to remote Eclipse/P2 repositories. For us this would be building with Tycho, deploying to a Nexus/P2 repository, and then consuming from that Nexus/P2 repository using Tycho, the Eclipse Update Manager or any P2 client
• Allow implicit and partially defined target platform specifications.
• Reusable target platform specification.
• Run tests against multiple target platforms, possibly in different runtime environments.

There a couple more things to mention about target platforms. First, we believe it is important to allow a fully reproducible target platform construction, i.e. the specification should have enough detail to recreate the exact same target platform regardless of the content of artifact repositories or state of the local environment. Second, we believe it is also very important to be able to reuse a target platform specification either to define custom Eclipse distributions or RCP applications. When we develop m2eclipse extensions, we want to use the same target platform as m2eclipse and then layer new features on top of that target platform.

IDE support for Tycho projects

• Import Tycho projects as PDE projects in Eclipse.
• PDE target platform management.

Publish build results

• Publish Eclipse/P2 repositories and/or Eclipse Update Sites.
• Combine build results with pre-existing artifacts to create custom Eclipse distributions or RCP applications.

The idea is to make build results immediately usable by QA team or for production use.

P2 repository management

• Proxy, group, filter and control access to P2 repositories.
• Staging, procurement and other advanced repository manager features.

These are as useful for P2 as they are for Maven repositories. We’ve been using Nexus and local P2 proxy for m2eclipse development and testing this for a few months now. It saves lots of time and bandwidth for us and works more reliably as well.

We have setup a dedicated tycho-users mailing list which you can subscribe to in order to participate in the discussions.

Sonatype will be having a Maven Meetup on March 19th and 20th in our offices in Mountain View where we will be talking about our Eclipse/OSGi tooling. Sonatype will also be talking about this Eclipse/OSGi toolchain at the Philly Emerging Tech Conference and finally Sonatype will be participating in the OSGi Tooling Summit being hosted by Peter Kriens of the OSGi alliance. We hope to present solutions for a lot of the current impedance mismatch between Maven and OSGi. I strongly encourage anyone interested in the future of Maven & OSGi to join the Tycho users mailing list and get involved!

PHOTO CREDIT: NASA, Solar Eclipse from Moon

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] INTERVIEW TRANSCRIPT

Tim O’Brien: So, Rich could you introduce yourself?

Rich Seddon: Yeah, my name is Rich Seddon and I’ve been brought on at Sonatype for the purpose of producing a set of automated tests for the M2 Eclipse Product and the reason for doing this is that there’s a lot of performance improvements and bugs that we want to fix. But if we don’t have the automated test in place we won’t know if we’re breaking things. And it’s got to be automated because of the number of platforms that we support and the number of operating systems that we run on is very large and the manual testing process is really much, much more than a small company can possibly handle.

TO: So, can you give me a sense of what’s the difference between what you do and something like a basic JUnit test.

RS: Well, what I’m actually doing here is a full set of system tests for M2 eclipse so I actually in the test harness bring up the M2 eclipse on various platforms and drive the UI through a set of scenarios and verify along the way that no errors have occurred and that the state of the UI is as expected and the state of the project under test is as expected….you might say that what I’m doing is trying to capture, in an automated fashion, the types of usage that our users will actually go through from day to day.

TO: What kind of tools are you using for this?

RS: Right now I’m using uumm; I’m kind of using Hybrid approach. There are sort of two approaches to doing eclipse UI I testing. One of them is to drive it with a sort of UI robot where the robot pushes buttons and manipulates trees and things like that. And the other approach is sort of a white box testing approach where you bring up in a regular old unit test, eclipse, and you drive eclipse at the API level to the unit test. Both of these tests have their advantages and disadvantages.

The reason that I got attracted to this position is that, in the last few years, it seems there’s been a few sort of hybrid approaches come along one of them is called SWT POD (sp?) PPTP by eclipse and then there was Abbott. Then there’s a commercial company, Instantiations has a product called “Window Tester”. And these allow you to do both kinds of testing, UI Robot testing and API testing at the same time. What they do is they sort of record your actions as your drive eclipse through a set of scenarios and produce a JUnit test that you can then edit.

TO: Is this run as a part of the Maven build for m2eclipse?

RS: Yeah, it is run in….. integration using the Maven OSGI plugin. There’s an OSGI test runner plug-in that actually brings up the eclipse, loads in the unit test, and then within the running eclipses project runs the unit test.

TO: So, what sorts of things have you found through the testing that we wouldn’t have found if we hadn’t been doing this?

RS: Well, I’ve found quite a few things. There’s been certainly some deadlock situations that I don’t think we would have been able to reproduce. We would have got reports of them, but we never would have been able to reproduce them in-house because they don’t happen that often. But, when you have these tests running continuously and you’re capturing the output of them when things go wrong then that allows us to find intermittent bugs which is very difficult to do otherwise with manual testing.

The other thing that I’m finding though is that because I’m actually driving eclipse through an automated scenario, it forces me to pay very close attention to eclipse itself. So, I actually think even the manual testing that I’ve been doing has benefited from this process because I have to really think very carefully about how I’m driving eclipse through various scenarios in order to be able to produce these tests.

TO: I notice that sometimes the bugs that people find in a plug-in for eclipse have nothing to do with the plug-in itself. Are you testing different distributions of eclipse; like different combinations of plug-ins?

RS: I am not doing so much of that yet. I’ve just got started about a month ago, but it’s on the road map. So, I plan to have these automated tests— Right now they’re just running in Eclipse 3.4 and they’re running essentially with all the of the required plug-ins that M2Eclipse could ever never need: WTP, Subclipse and all kinds of things like that. But yes, it’s on the road map for maybe in a month or two, I’m going to start expanding the set of platforms and have different sets of plug-ins and different combinations of plug-ins. Certainly Eclipse 3.3, possibly Eclipse 3.2, IBM RAD and of course get running on different OS; These are all on the road map. And, once I’ve got the automated test running, I mean this is the advantage of the automation right, I can really easily expand it to be able to get good quality testing on all these different platforms.

TO: Well, thanks for taking the time to talk to us. And, we’ll check with you in a few months to see what progress you’ve made.

RS: All right, sounds good.

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.

A Basic Summary of Tycho

The general idea of Tycho is that it acts as a bridge between Maven and OSGi.  It supports a number of usage scenarios and is under active development.   It can be used in a manfiest-first mode which builds a Maven POM from an OSGi manifest and it can also be used in a pom-first mode in which Tycho is responsible for generating an OSGi manifest from a Maven POM.  Future plans include the ability to build a project usin Maven/Tycho without requiring the presence of a Maven POM, and there is active work under way to allow Nexus Maven repository manager to interact with Eclipse update sites and p2 repositories, that would allow Tycho to consume artifacts from those repositories.   If you are looking for a more in depth explanation of Tycho, check out the Tycho Project Overview.

If you are looking for a solution to automate Eclipse builds with Maven, look no further, Tycho is your answer.  In this post, I’m going to walk you through the process of configuring a Maven build for a real Eclipse plugin.   This process involves the following, high-level steps:

1. Configuring Eclipse
2. Downloading Tycho
3. Checking out Eclipse Plugin Source from Subversion
4. Generating Maven POMs using Tycho
5. Packaging Your Eclipse Plugin and Generating an Update Site with Maven

At this point in the development of Tycho, you’ll have to point the system at an installation of Eclipse, your targetPlatform.   Let’s get started.

Configuring Eclipse

Tycho currently builds Maven pom.xml using a local installation of Eclipse which should contain the Plugin Development Environment (PDE) and other Eclipse components your specific plugin depends on.   Future versions of the Tycho product will likely interrogate remote p2 repositories and Eclipse update sites, but for now we have to configure a local Eclipse Target Platform with the necessary components.  For this particular example, you’ll need to install Eclipse 3.4 and download a few plugins that the Neoclipse plugin depends upon.   For more information about what Neoclipse requires, see the Neo4J Wiki Page for Neoclipse. These steps are also needed when you need to work with Neoeclipse code using Eclipse PDE.   You need to:

1. Download and install Eclipse 3.4 if you don’t already have it installed.
2. Neoclipse has a graphical editor component which relies on GEF.  To build the plugin, you’ll need some of the Draw2D components.   The easiest way to install this particular plugin is not via the standard Eclipse update manager.  You should download GEF ALL distribution for Eclipse 3.4 from the GEF Download page.   The direct link for the GEF-ALL distribution is here.
3. To install the GEF-ALL distribution, unpack the ZIP file to a directory and then copy that directory to your Eclipse installation.  This will install all the necessary features and plugins that neoclipse depends on.
4. As usual, I would recommend installing both the m2eclipse plugin and the Subclipse plugin.   These are two plugins I almost always need:
   1. m2eclipse update site: http://m2eclipse.sonatype.org/update (or if you want to use the latest stable DEV build http://m2eclipse.sonatype.org/update-dev)
   2. Subclipse Update site: http://subclipse.tigris.org/update_1.4.x

I’m on a Mac, so I usually install my eclipse distribution in /Applications/eclipse.   For the remainder of this document, if you see /Application/eclipse, you should substitute your own eclipse installation directory.

Downloading and Configuring Tycho

At this point, you have Eclipse installed and configured with the necessary plugins to build the Neoclipse plugin.   Now you need to download and configure Tycho.  Tycho contains a development version of Maven 3.0 that has been extended to allow for Tycho to interact with the the OSGi components and format of the plugins directory of your Eclipse plugin. In the future versions you could use regular Maven 3.0 and use Tycho as any other Maven plugin.

1. Download Tycho from http://docs.codehaus.org/display/M2ECLIPSE/Tycho+builds.  I downloaded the latest DEV build, and I installed it in ~/programs/tycho – Tycho includes a development SNAPSHOT of Maven.
2. Set M2_HOME to point to ~/programs/tycho.   If you don’t do this and you already have Maven 2 installed, you are going to run into errors and issues if you try to run either Maven or Tycho.   I usually set M2_HOME to point to my Tycho installation by running “export M2_HOME=~/programs/tycho” in bash.

Once Tycho is configured, you are ready to generate Maven POMs from your Eclipse plugin.

Generating Maven POMs with Tycho and Building an Update Site

The demo script for Tycho uses a contrived a demo project called tychodemo.zip which contains a simple Eclipse plugin.   I wanted to demonstrate that Tycho is ready to be used today with a real Eclipse project.    This project is the Neoclipse plugin for Eclipse that allows users to interact with a Neo4J database in the Eclipse IDE.

1. Change directories to a working directory.  I usually do all of my coding in a ~/svnw directory which is segmented by focus.   So, I check out Open Source projects like neo4j in a ~/svnw/os directory: cd ~/svnw/os
2. Checkout the source code for the neoclipse Eclipse plugin with Subversion: svn co https://svn.neo4j.org/components/neoclipse/trunk neoclipse
3. Change directories into the neoclipse directory: cd neoclipse
4. Generate a set of Maven POMs from the Neoclipse source using Tycho: ~/programs/tycho/bin/mvn -X org.codehaus.tycho:maven-tycho-plugin:generate-poms -DgroupId=tycho.demo -Dtycho.targetPlatform=/Applications/eclipse

At this point, you’ll have pom.xml files in all of your plugins and at the top level.   Tycho has generated a multi-module Maven project that references components in your targetPlatform, specified using “tycho.targetPlatform” property on the command line.  Tycho doesn’t need Eclipse to be running, all it needs is access to the Eclipse directory so that it can resolve components such as the Eclipse Plugin SDK at the GEF plugin installed in the previous section.

To build the update site, run:  ~/programs/tycho/bin/mvn package -Dtycho.targetPlatform=/Applications/eclipse You should then have an update site in ./org.neo4j.neoclipse.updatesite/target/site

To avoid specifying tycho.targetPlatform property every time, it could be added to your settings.xml. For example:

...
  <profiles>
    <profile>
      <id>tycho.default</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
      <properties>
        <tycho.targetPlatform>/Applications/eclipse</tycho.targetPlatform>
      </properties>
    </profile>
  </profiles>
...

UPDATE (9:21 AM CST): Eugene Kuleshov just sent in a bunch of edits and improvements which were incorporated. Removed the section about adding the repository as it should already be in the public group hosted on Sonatype’s Nexus repository.