At last night's OSGi DevCon London, a panel discussed the state of OSGi tooling and what's missing. (The panel members were Chris Aniszczyk of Eclipse Source, Peter Kriens of aQute, Glyn Normington of VMWare, David Savage of Paremus and Toni Menzel.) One of the problems seems to be lack of funding; build systems are generally not paid for, but collectively, there's a massive amount of time wasted on building generally. Hopefully, Sonatype's venturing into the OSGi fray with Tycho and Maven 3 will provide a standard tool for those already on the Maven platform, and other approaches (like Sigil) will step in to help out. What's interesting is that most panel members did not think a Manifest-first approach was the right way of going, instead preferring a bnd or bundlor type of approach which involved automatic generation of the Manifest. PDE, for now, will stick with Manifest first (and Tycho will also use that approach) but it's clear that there are several ways.

One question (of the several...) I asked was relating to obtaining the source of a given bundle. One of the problems with providing any kind of patches (or fixing) is that the source is often missing, or that it's from an older version of the repository. Peter's observation was that shipping the source in-bundle was the only way to be sure; but most prefer to distribute separate source and executable content separately, or in a fragment. There's OSGi standardisation in place to permit a known source folder being automatically introspected if present (which is good, and useful), but we can do better than this by adding a pointer to the source repository where it came from.

A long time ago, I suggested the addition of Bundle-SCMURL (OSGi bug 48) to an OSGi's manifest, such that it would allow IDEs to pull down a version of the code. Many Maven-based projects already encode the SCMURL in the pom.xml, which allows someone downloading the (manifest-equivalent) header and then using that to obtain the source code. I even prototyped a plugin (don't know if it still works) which would allow you to check out any of the Eclipse CVS-based projects, with an 'override' that supplied missing Bundle-SCMURLs where missing for known top-level repositories. (Eclipse RT has moved since then, so I'm pretty sure it wouldn't work for those projects; but that's just a config update.) The idea was blocked by Jeff McAffer, Pascal Rapicault and Michael Valenta on Eclipse bug 195729 when I raised it at the time.

So, it was a pleasant surprise when Chris Aniszczyk said at the tooling panel that Eclipse 3.6 will come with some PDE support for checking out source code from a binary bundle; there's work going on as we speak to prototype this. (As Gunnar pointed out, it's bug 243582, which ironically referenced my bug last week...) For the good of the open-source community, I hope this makes it in, and that Apache Felix bundles start using that information (derived from their pom.xml automatically via the maven-bundle-plugin). At the very least, we should re-use the Maven SCM format for the URLs, which is generic enough to handle arbitrary providers; it will also allow the maven-bundle-plugin to generate this information automatically. Note that the format is standardised; but PDE won't need to re-use any implementation, just share the URL, much like CVS can be read from multiple providers (Eclipse CVS, windows CVS etc.). For example, here is the Felix-1.0.0.pom, which defines the scm:svn:http://svn.apache.org/repos/asf/felix/trunk url.

The format of this SCM URL is well defined, and all Maven projects use this. The format also permits other version control systems to add additional information; for example, here are the scm:cvs and scm:svn implementations. If this is going to be added to the Eclipse tooling, then we really should follow this format, even if it means the addition of other fields to represent (say) CVS tags. There's also no reason why the format couldn't be standardised on by OSGi for the bundle header for all tools (hence, bug 48) and you couldn't really get a larger set of projects that use this format anyway, demonstrating that it works.

Note this is useful in both open-source as well as commercial projects. Large organisations typically have many departments, and not all will share the same repository; in fact, it's quite likely that an organisation's code base may be split over multiple repositories rather than just a single one. Being able to get the source from a binary-only bundle in an IDE would be a great way of debugging, or contributing back patches.

So, if this is going to happen, let's reuse the scm:cvs and svn:svn formats already defined. They're trivially parseable and manglable into the existing Eclipse CVS/SVN Project Set Files (which is how my implementation worked) and we don't need any additional code in Eclipse to make it happen. We just need to use the same URL instead of inventing our own one.

Update: I've implemented a spike solution which enables you to import projects into Eclipse by only specifying a Maven SCM URL. You can comment on and download it from the attachment in Bugzilla at Eclipse; the file contains the source as well (ironic, I know). Obviously, it's not production-ready code, but it demonstrates how trivial the problem is to solve whilst not using anything more than a few tens of lines of Java and the existing Eclipse libraries.