When you deploy API plugins to a platform, developers are expected to target the platform, and reference the exported API. You do this all the time during the course of plugin development. Within the Eclipse IDE, you begin by targeting an Expeditor or Notes platform. Then you to develop new plugins which reference the exported Java types or contribute extensions to those plugins.
- com.ibm.rcp.support.unpack.provider makes code within the same package name available to downstream plugins. The Provider class that is contained in the .provider plugin and is intended for use with 3rd party developers.
- com.ibm.rcp.support.unpack.consumer references the provider API plugin and makes use of the Provider class within its Activator. Basic stuff, you do this all the time in PDE.
But the developer has decided that his plugin should be unpacked (unjared) during installation.
Now let's assume that the com.ibm.rcp.support.unpack.provider plugin is deployed into the field either via an update site or bundled product. An eager developer intends to use the Provider type. He targets the platform containing the com.ibm.rcp.support.unpack.provider plugin, adds it to his dependency list, and adds the Provider type into his code. What happens? Interestingly, he receives a compile error stating that the Java type can not be resolved. This is odd because the plugin dependency is satisfied and the original plugin exports the necessary packages. What gives?
It turns out this is a known issue in Eclipse 3.4.2. Because the com.ibm.rcp.support.unpack.provider plugin unpacks itself, it is not added to the classpath appropriately. While not a run-of-the-mill developer issue, it is a bit counter intuitive. But then again, many bugs are exactly that.