PDE's Automated Management of Dependencies

I have been working with the upcoming Equinox OSGi book authors quite a bit as of late. They are a demanding bunch, but they have helped me improve PDE’s OSGi tooling while they write and exercise parts of PDE that not many people know about. In particular, the book uses something in PDE called Automated Management of Dependencies (AMD). What’s that? Well, have you ever noticed this collapsed section in the PDE editor:

Let’s take a peak!

This section of the manifest editor was built for people who have different bundle development workflow. At Eclipse, we have traditionally done a manifest-first workflow where users are responsible for crafting their whole manifest. I personally believe this is the best workflow for advanced users. However, for new users, it’s very cumbersome to specify your dependencies. For example, if I want to use some JFace Databinding code, how do I know what bundles or packages I need to specify? Well, AMD was built to address this concern. The first step to using AMD, is to add the bundles that PDE will consider to when generating your dependencies (we call this the secondary classpath). The easiest thing you can do is add all the bundles as part of your target (although this isn’t always optimal):

Ok, now that we have added all the bundles that PDE will consider when generating the dependencies, we need to select what type of dependencies PDE should generate. In this case, we choose Import-Package, but you can as easily choose Require-Bundle if that was your preference. To test the AMD functionality out, we will remove all of our current dependency statements, which will result in a bunch of compile errors in our project:

So now, we can either click the analyze dependencies button in the AMD section of the editor… or we can simply launch our application and the dependencies will be automatically calculated. To verify, let’s look at our manifest:

Wow, magic! PDE analyzed the code and calculated the dependencies so you didn’t have to think about it.

This works great, however, not everything is perfect yet… there are a couple bits missing. If you noticed, the version ranges weren’t properly calculated on the dependencies. This is a hard problem and we are currently exploring it in the PDE API Tools project. It is also a bit cumbersome to add things to your secondary classpath… should the default be that we look at everything in your target? Should PDE look at using something like BND to do the dependency calculation? Should we allow people to somehow scope the bundles in advanced… while creating a new project? If you’re interested in this functionality, please let me know. The PDE team plans to explore and improve AMD in the next release cycle, so please comment if you have ideas. You can also file bugs and feature requests against PDE.

I’ve also created a quick video which shows AMD usage with the RCP mail example.

Enjoy.

Enjoy.