#16 Reference binary features

[mitko]

Another easier and faster way to extend the target platform with compile-time dependencies is to just copy the dependencies in the ${buildDirectory} folder of pluginbuilder. This can save the above 2 phase approach, that is currently used in pluginbuilder, if the configuration is built in pluginbuilder.
In details - the the problem addressed is as follows: let's have a source feature built by pluginbuilder, that has a dependency to a "binary feature" (e.g. a feature whose plug-ins are maven artifacts and valid OSGi bundles). So the target build platform has to know the "binary feature", in order to compile the source feature listed in pluginbuilder, while at the same time the pluginbuilder, in version 0.7.xxxx , does not know how to find the "binary feature", because the "binary feature" has no sources, ant therefore is not built. This results in a compilation failure on build.
Now, the proposed solution is to copy the "binary feature" in ${buildDirectory} (meaning "<the.plug-in.jars> in ${buildDirectory}/plugins, <the.feature.zip> in ${buildDirectory} /features. Then the <the.feature.zip> has to be unzipped - this is very important - so that the pluginbuilder could find the "binary feature" when it builds a product. In no product is built, the plug-ins of the "binary feature" themselves must be enough to provide the compile time dependencies needed by the PDE build. If there are automation tests, the dependencies must be copied additionally in the ${test.eclipseExtensionDirectory} folder, to be available for the test host, because the pluginbuilder has no knowledge about them (this can be also solved in a different way, e.g. call the standalone update). Of course the solution requires an override of the sources, generated by pluginbuilder.

I am interested to know what you think of this solution. Could it be an option for pluginbuilder?