Building a modern Java app with Eclipse, Maven, OSGi, and Spring DM (Part 4)
August 5th, 2009 | Published in development
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
- 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.
- 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.
- 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.
