I had every intention of blogging during and after the Equinox Summit earlier this week. As it turned out, things were way too interesting and the conversation far too engaging for me to get even a couple minutes to dash off a note or two. For those who don’t know what I am talking about, the Equinox team and the Eclipse Foundation held a two day “summit” involving current Equinox committers and contributors as well as a number of key consumers of Equinox technology.

We were worried that with about 35 participants the group was a bit large for dynamic discussions. In the end we used a format that called for a series of 1 hour break-out sessions followed by plenary summaries and further discussion. This worked really well in my opinion. By having the group pick the session topics we pretty much ensured there was something for everyone all the time (thus no blogging time :-)  The results of the summit are captured as a series of presentation slides and breakout session reports.

The N things I took away from the summit:

1. p2, the new provisioning platform is hot on people’s minds
2. Server-side Eclipse via both the Equinox server work and simply Equinox/OSGi on the server is impacting people today
3. PDE is not done yet
4. Component programming models (e.g., Eclipse extension registry, OSGi services, Declarative services, Spring, SAT, …) are at the center of it all so w’d better get it right

The next stop for Equinox enthusiasts is the Eclipse Summit Europe where there will be a Server-Side Symposium and a Provisioning Symposium.  See you there!

Philippe posted earlier today with some sad news.  Plug-in is still plug-in and not plugin.  But wait Philippe, not all is lost!  Plug-in == Bundle!  So good-bye plug-in (and plugin for that matter) and hello bundle.  Use it in your code, with your friends, in documentation and presentations.  It’s simple, easy, shorter and has no pesky horizontal lines.

As some of you may have seen in Wayne’s post a while ago, Eclipse Summit Europe is coming up and there are going to be a series of workshops and symposia. He mentioned the RCP experiences workshop (sounds like lots of fun) but I’d like to point out the Provisioning Symposium. Provisioning is one of the hot new areas in Eclipse with p2 in the Equinox Incubator and Maya (soon to be Maynstall) as well as interest and overlap in several other projects and product teams. This symposium is designed to bring together people interested in provisioning to talk about their usecases, technologies and potential contributions.  It should be a great time so send in your name to summit@eclipse.org and let us know you are interested in coming.

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