Over the past few days I’ve seen a number of cases where people are challenged by managing development-time code dependencies.  Compiler errors like “<some class> is indirectly referenced from required .class files.”  Very annoying.

You can solve this simply by adding a dependency on the package or bundle that contains the missing class(es) but that introduces additional and often unnecessary dependencies and tightly more coupled system.

There is a better way!

First lets step back a second and see what’s going on. Say you have a structure like this…

Here the green lines are the class dependencies (extends).  The blue lines are the runtime resolved bundle classloader dependencies (Import-Package or Require-Bundle). At runtime, the C’s classloader simply delegates the loading of its parents to the bundles supplying them.  That is, bundle B is asked to load class B.  Similarly, bundle B classloader asks bundle A to load the class A. C is doesn’t know anything about A. Great.

Unfortunately, at compile-time the compiler needs to see the entire class structure of C and all its parents. PDE works with JDT to create a compile time classpath that closely mimics that of the runtime but under the covers the compiler uses a flat, non-delegating classloading model that ultimately does not match the runtime.  So it ends up with this picture when compiling C.  Notice that the red line is effectively the direct dependencies that C is known to have and so does not include a reference to A.

You can see now why adding the explicit dependency in C’s manifest fixes the problem — it adds a red line from C to A but at the expense of additional coupling.

There has to be a way!

Fortunately, you can get the compile-time classpath entry without the bitter aftertaste using PDE’s Automated Management of Dependencies (AMD) mechanism.

The list shown on the Dependencies tab of the bundle manifest editor essentially shows bundles to add to the compile classpath of the bundle. This makes their content available for code completion, searching and compiling but does not change their MANIFEST.MF.  Adding bundle A to this list in bundle C solves the compile problem by giving you this without a superfluous dependency. Sweet.

Note that you can have the opposite problem if a bundle is listed in the AMD section but not in the Imports or Requires. In that case, the dependencies are not there at runtime.  This problem is easily solved by clicking on the add dependencies link.

AMD has lots of interesting uses as it allows you to basically write your code first and then generate the manifest dependency entries after.  Take a few minutes and try it out. I think you’ll like it.

Tags: eclipse, pde

Cut the download cord and populate your target platforms faster with PDE 3.7M4.

Software Site (p2 repository) based PDE Target Platforms are great. Point at a repo, pick some features, click and everything you need gets downloaded and cached locally.  With some recent improvements you can easily include source, update and export these targets. What could be better?

How about downloading the content faster?  How about not downloading at all?!

I dunno about you but I have some 50 or so workspaces on my machine.  Different Eclipse projects, customer projects, company projects, hobby projects, book projects, …  Pretty much all of them use p2-based target platforms. I don’t mind that each workspace has its own cache (aka bundle pool) of the target bundles — disk space is cheap.  I do mind that every time I make a new workspace the target bundles are downloaded again.  They are already on my disk in a folder right next door!

Turns out that with some very minor tweaks in the PDE code I was able to have the downloading step consider additional artifact repositories. Once that was enabled, I added in the bundle pool for the current running Eclipse IDE as well as the PDE target bundle pool for all known “recently used” workspaces. The net effect is that you pick features from one metadata repo and the content, if already local, is just copied.  No downloading.  Of course, new content is still downloaded as needed.

We are looking at exposing some preferences to allow additional artifact repositories to be listed.  Makes sense, just need to put a UI on it.  Can you think of additional improvements?

Watch your network access next time you add content to your target platform.  You should be pleasantly surprised.

Sidenote: People have suggested that PDE manage just one artifact repository/bundle pool for all target definitions for all workspaces. This would save disk space for sure but introduces some additional complexity in managing concurrent repo access as well as garbage collection. It would be great but for now, this is the next best thing.

Tags: eclipse, osgi, pde, target

There is a long standing disconnect between PDE Target Platforms and the input you give to PDE Build.  With target platforms you can define directories, installs and Software Sites (p2 repositories) as places to get pre-built bundles to use during development.  That support has long been baked into the PDE UI code making it hard for the headless PDE Build infrastructure to use the same target definition when it compiles bundles.

In 3.6 (Helios) we partially addressed this by introducing the ability to “Export” your target definition. Users could get a snapshot copy of their active target definition content copied to a defined location.  That location could then be used as input to PDE Build.  With Eclipse 3.7M4 we’ve improved the export support in two major ways (and one minor fix).

1. If the target definition uses Software Sites then the exported content coming from those sites has p2 metadata and artifact repositories associated with it. These repos can be directly consumed by PDE Build thus preserving the original published metadata and all the little extra configuration information that comes from the originator as well as supporting binary and feature root file content.
2. You can now export any target platform, not just the currently active one.  This considerably simplifies the workflow as you don’t have to switch targets and recompile your workspace (twice).
3. I also slipped in a fix to a bug where deselected content was being exported even though it was deselected.  Now the exported target content is a faithful copy of the original.

Like the other PDE changes I’ve been working on, these are just little steps down a longer path of making the end to end PDE and p2 workflows better integrated.  The next step for this function is to make the exporting available directly to PDE Build via an Ant task so that it can get/update its target definition at the beginning of each build.  That should be reasonably easy but there are sure to be details. Look for more on that later and in the mean time, enjoy these new more complete and higher fidelity target exports.

Tags: eclipse, osgi, pde, target

In the winter here (Canada) we don’t just ask, “Would you like fries with that?”, we ask “Would you like poutine with that?”  You may not be able to get poutine where you are but now you can get source code wherever you are.  You just have to ask.

In the Eclipse 3.7M4 build that was released yesterday PDE has a new “Include Source” option available when using Software Sites (aka p2 repositories) in your target definition. If you check that box, PDE will look in the available repositories for source bundles that correspond to the binary bundles you have selected.  No need to manually find/select them.

This change is part of a bigger story.  A while ago I was putting together a development/build workflow for a customer.  They wanted to use their build output as a PDE Target Platform much like we do by default in the Eclipse project.  Makes total sense. Unfortunately, setting it up is not as easy as you’d hope.

First you’d have to have source features in the build.  These would generate source bundles corresponding to your binary bundles. You’d also have to figure out how to get them built in your product build.  Then, when populating a target platform, your developers need to select a special “SDK” or “Target Components” feature that includes the source.  Now they just point at the binary features they want and “Include Source”.

The story is not quite complete however. You still have to create the source bundles in the first place.  When exporting features from the workspace there is a handy “Generate Source” check box.  Simple.  Unfortunately, we never added a convenience option like that in PDE Build.  Bug 329162 seeks to change that.  While it did not make it into M4, the patch attached to the bug allows you to generate source bundles with one property setting. I’ll be working with Andrew to get that in for M5 and will post here when the fix is in.

Even without the PDE Build changes the ability to include source is already useful. You can pick your desired runtime feature, check the box and get just the source you need. Sorta like poutine when it’s -30C and windy…

Tags: eclipse, osgi, pde, target

Target platforms are a mechanism in PDE that allows developers to identify the set of bundles and features that will be available to their application. You can then write bundles and compile against those in the target, define features/products based on target bundles, and run or export using those target bundles.  Very powerful and convenient.

With the evolution of p2, you can define target platforms in terms of Software Sites.  That is, you can point at p2 repositories and select particular versions of features to be used in your applications. Even more powerful and convenient.  Now another step.

Starting with Eclipse 3.7M4 there is an Update button in the target management UI. Simply select the features and software sites you want to update and let PDE discover newer versions.

One of the coolest usage patterns this enables is targeting your builds. Simply setup your build system to publish its output into a p2 repository and then add that repo to your target and pick the relevant features. Then, whenever you want to pick up the latest build, click Update.

Tags: eclipse, osgi, pde, target

Over the past few years I’ve had (and still have) a number of blogs. One for the RCP book, one for the OSGi book, one for EclipseSource and a dead one at Eclipse.org.  In the past month or so I have been revamping the RT and Equinox project web pages and included aggregations of various feeds.  The other day BJ Hargrave setup a Yahoo pipe aggregation of OSGi related posts to make Planet OSGi.  I’ve started to think that I’ve been blogging wrong.

The problem is that my various blogs overlap in content domain. This is a problem for me, the producer, but also you, the consumer. The blogs are all related to Eclipse technology of some sort and I’ve often found myself either posting the same thing on several blogs or posting only on one blog and leaving the others wanting. The former is a pain for me and exposes you to “blog spam”.  The latter is easy for me (though I still have to choose which blog) and eliminates the spam, but limits the audience.

After some deliberation and consultation with various blog-knowledgable folks I decided that I’d be better off having one blog and using tagging and categorization to facilitate feed aggregators (myself included) to pull the content they think is relevant.  The classic producer-consumer split.  I produce content and mark it up in interesting ways while others choose whether or not consume the content.

After looking at all the other blogs that I currently have it was apparent that while they overlap, none would fit the bill as “the Jeff McAffer blog”.  This blog site is the result of that realization.

mcaffer.com has been in my family for some time now but has been largely unused.  In a couple hours I got it setup on Dreamhost with WordPress and a custom theme (that I will continue to tweak).  My next task is to aggregate the relevant posts from here onto my other blog sites and see how I can project some SEO love onto eclipsesource.com.

Anyway, this new blog will be largely about computer science-ish stuff and likely mostly Eclipse but I reserve there right to post on other topics as well.

To follow everything I say add this feed to your favorite reader and enjoy.  You can also get tag-specific feeds using urls like http://mcaffer.com/tag/eclipse/feed.

Enjoy!

Tags: eclipse, osgi, rcp