In a recent post, Wayne pointed out several benefits brought to you by PDE and WTP tooling. In particular, if you are developing bundles or web apps, these tools take care of the horrendous classpath management task for you. Thanks! His post reminded me of something that I’ve been talking about for sometime and been meaning to blog about.

I’ve been writing plug-ins/bundles for so long now I have a hard time relating to folks living in barren world that is plain old Java programming (POJP?). Not a modular runtime in sight? No classpath management in the tooling! Alone. Just me and a linear, static classpath. Eerily scary.

One day I was cast upon the rocks as it were and asked to look at an application that came as 5 JARs/projects. After some fiddling I managed to get the various build paths setup. Having done that, I needed to reorganize some things. Well, didn’t that just suck. I ended up spending alot of time playing with build paths trying to resolve circularities and …

To be honest, most of the issues I had were actually user-error. Nonetheless the frustration was real enough. After all, I am just a user. The fact that there are so many opportunities for error in classpath management means it is just begging for tooling.

Then I had an epiphany. Why not make everything into Plug-in projects?! Plug-in projects have classpath management. Why not just define a plug-in for each JAR? Heck, there is even PDE wizardry that will take care of generating the required manifests and then build and manage the build paths. Bliss!

So I did just that and even got a little trickier and used some of the visibility statements like x-friends and x-internal in the manifests to make sure I wasn’t doing bad things in the code I was refactoring. Life was good. I didn’t have to look at the build properties again. I was told when I accessed something I wasn’t supposed to. I could reason about the JARs and what was where. I was even able to build the JARs using PDE’s export operation.

You may get a bit bummed however when you go to run.  When you launch an Eclipse application or OSGi framework there is no need for PDE to compute a classpath. The framework does that for you at runtime. When you launch a Java application however, someone needs to compute a static, linear classpath to give to java.exe. [Correction pointed out by Ed] If all your plug-ins are in the workspace then the Java launcher will use the project dependencies (also managed by PDE) to create a classpath.  If you are using something from the Target Platform however JDT doesn’t know about it.  Here it would be great to have a way of sorting the plug-in dependencies and generating the required classpath automatically. We’ll have to see if someone implements this (hint hint)

Anyway, that’s it. Next time you find yourself doing “New > Java Project” consider doing “New Plug-in Project” and using PDEs classpath management technology to free yourself from the hassles of build paths.  You will be in good company.  The EMF folks do this on a regular basis.  As do the Harmony folks.

I know it is summer and people are thinking about BBQs, landscaping, sailing, … (ok, well, at least I am…) but Ian, our ever so subtle marketing director reminded me that it would be good to remind you that the Equinox Summit is coming up at the end of September.  This event promises to be both very interesting and alot of fun.  We are holding it concurrent with the CDT summit (lots of other interesting people) and September is a fine time to be in Ottawa (be sure to check out the fall colors as you fly in).

One of the meta-goals of this summit is to take the recent increased interest in Equinox participation to the next level.  In the last few months we’ve seen substantial contributions from Prosyst (several service implementations including Declarative Services), Lotus (JAAS, JCA, …) and folks such as Stefan Liebig and Andrew Overholt stepping up and contributing to the new provisioning work.   There is lots left to do in these areas and other areas as yet unexplored.  We want to use the summit as an opportunity to explore what’s going on now, what could be going on and where you fit in.

Check out the announcement and send in a statement of interest if you think Equinox contributions are in your future.  See you there…

Thanks to the webmaster team, committers can now host blogs on eclipse.org infrastructure.  Accordingly, I have moved from mcaffer.blogspot.com to http://dev.eclipse.org/blogs/jeff.  If, for whatever reason you have me in your subscriptions, you may want to update that link.

BTW, some people have asked why the Foundation has setup its own blog infrastructure when there is so much free blogging available.  Honestly, I asked the same thing when the idea was first proposed.  Various reasons were given but in the end, the one that really converted me is the IP management.  Everything posted to eclipse.org falls under the EPL.  So if you post some ideas for how to do something etc. in your eclipse.org blog, the legal context and terms of use are clearly defined.  This committers, for example, to have open discussion and not be worried that some comment might taint their work.

Anyway, happy reading…

Jeff