Kyle Smith

Today I’m going to talk about how we’re using the Eclipse IDE to develop the product.  Much of what I discuss was worked out by our Eclipse guru, Stephen Evanchik, so credit for it goes to him as well as to the folks that worked on the JDT and PDE features.  Can’t forget to include the Sonatype folks who work on the m2eclipse plugin.

Background

Originally we worked at the command line using Maven, but as the team grew we started doing the majority of the work in Eclipse and relying on the stable development release of the m2eclipse plugin to integrate with Maven.

We import all of our modules into Eclipse as Maven projects and via the magic of the P4WSAD SCM plugin, many developers never need to leave the IDE once they’ve done an initial build at the command line.  We also have custom launchers and target platform definitions that allow developers to run and debug the product from within the IDE.

Typical workflow

Developers start by checking out code via p4 or p4v in order to get a full copy of the codebase.  They then typically perform a full build at the command line using Maven in order to do some one-time setup (copying files around, creating the Eclipse target platform, etc.) as well as installing an initial copy of the artifacts into the local Maven repository.  The projects are then imported into Eclipse.

Once the projects are loaded they can work on their features or bug fixes and use P4WSAD to interact with Perforce.  It works fairly well, although there are some rough edges (such as having to select all the projects and go through the Team > Share Project dialog for every single project individually instead of doing it as a single batch).

For running and debugging the product we’ve assembled a custom target platform that incorporates all of our dependencies, so developers can launch the product and test out their work in the same runtime that the final product will use.  Remote debugging can also be used which has come in very handy when QA reports issues and developers can connect directly to the service and set breakpoints.

What works well

The target platform support and PDE tools (the manifest editor in particular) have worked well enough, and hopefully we’ll get everyone migrated from Ganymede to Galileo soon enough.

What could be better

1. I already mentioned the rough edges on P4WSAD, but thankfully that’s typically only a problem when doing the initial (large) import into Eclipse.  It can also be difficult to remember which projects you’ve already shared if you’ve got projects coming and going.  One thing that can make it more obvious which projects you’ve shared is to enable the Perforce annotations in the package explorer (Preferences > General > Appearance > Label Decorations and check the Perforce option).  This will show the Perforce server and file information in the package explorer.
2. We’ve also experienced a lot of pain with m2eclipse because of the time required to calculate dependencies and its tendency to eagerly rebuild projects.  Some of this is due to our running Maven in offline mode and the wonky HTTP proxies we have to deal with, but in some cases it blatantly ignores the settings you’ve given it.
3. Maven, Eclipse, and OSGi can be tricky enough on their own, but can be downright scary to someone that’s new to Java.  There’s a lot of magic involved for the newbie so the learning curve can be quite steep.  I would recommend that folks add a single technology at a time instead of trying for that perfect storm all at once.

Tags: eclipse, m2eclipse, maven, osgi, p4wsad, perforce

Came across another small bug with m2eclipse yesterday when editing an XML schema in a project that used  the Maven plugin for JAXB (jaxb2-maven-plugin).  You may find Eclipse complaining that it cannot build your project because of this error:

An internal error occurred during: “Building workspace”.
Provider org.apache.xerces.jaxp.SAXParserFactoryImpl not found

The underlying problem may be due to classloader funkiness with the embedded version of Maven (since command-line Maven works fine) or some transitive dependency not being handled correctly.

Anyway, the workaround mentioned in this bug on the Codehaus JIRA solved the problem.  The solution is to explicitly add Xerces as a dependency to your POM:

<dependency>
    <groupId>xerces</groupId>
    <artifactId>xercesImpl</artifactId>
    <version>2.8.1</version>
</dependency>

Once you’ve done that, right-click on your project in the Package Explorer and select Maven > Update Dependencies. Eclipse should then be able to rebuild the project.

Tags: eclipse, jaxb, m2eclipse, maven

Here’s a tip for a very specific problem I recently encountered when using Maven and the Felix maven-bundle-plugin in Eclipse, and I’m sure it can happen with other plugins. There wasn’t an immediate answer to this problem when I used Google to search for it.

When Maven is running in offline mode (set in the Maven section of the Eclipse preferences), if you haven’t specified a version for certain plugins — like the maven-bundle-plugin — Eclipse will report an error like this:

Project build error:Cannot resolve pre-scanned plugin artifact (for use as an extension): org.apache.felix:maven-bundle-plugin: Failed to resolve extension plugin: org.apache.felix:maven-bundle-plugin:maven-plugin:RELEASE

Maven outside of Eclipse will most likely continue to work fine, but Eclipse will be one unhappy camper.  Your project may even lose its Java nature if m2eclipse is unable to resolve the dependencies.

The solution is to either allow Maven to run in online mode (Preferences > Maven) or add a <version> element to the plugin configuration (see example below). It seems that specifying the version in the pluginManagement section of the pom.xml may not even solve the problem.

<plugin>
	<groupId>org.apache.felix</groupId>
	<artifactId>maven-bundle-plugin</artifactId>
	<version>1.4.3</version>
	<extensions>true</extensions>
	<configuration>
		...
	</configuration>
</plugin>

Once you make one of these changes Eclipse/m2eclipse should rescan the project and fix it.  If it doesn’t get fixed immediately, right-click on your project in the Package Explorer and choose Maven > Update Dependencies and Maven > Update Project Configuration.

Note: I’m assuming you’re using a stable development build of m2eclipse. The non-dev version didn’t have these options when I last checked.

Tags: eclipse, felix, m2eclipse, maven