Eclipse puts provisional API into internal
packages. I think this is really distracting. Why? Well, provisional API should encourage early adopters to support upcoming features. Great. But what do they get from adopting an API that will be moved to some other package in a later point of time? Right, their adoption breaks and the users of their plug-ins are stuck to an older Eclipse release.
This now happened to me with the Borland StarTeam integration. The developers adopted to the ResourceMapping support introduced in Eclipse 3.1. Actually this should bring the plug-in some benefits in handling model objects that are backed by multiple resources. That’s a great idea but now I’m stuck to Eclipse 3.1 and can’t use 3.2 M5 anymore because the package name of the Resource mapping support changed and the plug-ins can’t be started anymore due to a java.lang.NoClassDefFoundError: org...internal...mapping.ResourceMapping
. This reduces the intendence of the adoption to absurdity. Even a match="greaterOrEqual"
won’t help in this case.
Unfortunately, the StarTeam integration is closed source. Thus, I can’t go an fix this stupid error myself. I probably have to wait till long after Eclipse 3.2 has been released to get an updated. 🙁
And at the end? Nobody will get any benifits. Users are stuck to an older technology or need to drop the Team integration completely. The adopters appologize and may consider not adopting next time. And the developer will get no feedback about his API because there won’t be any volunteers anymore. 🙁
Update 2006-08-17:
I’ve written a plug-in for Polarion’s SVNImporter. It allows you the migrate from StarTeam to Subversion. The code is available here.