This is a “would be nice to have” feature. From the inception of the project, we had the idea to clean up and publish
buildSrc as a separate plugin. We can’t do it by ourselves as we have many other priority stories for Buildship: define stable API, add task execution upon synchronization, just to name a few. If somebody - like you - wants to work on it then please go ahead, we always try to give good guidance to the external contributors.
Here are a few hints if you want to assess whether you want to work on this. The biggest blocker in
buildSrc is the gap between the Eclipse and the Gradle wold. For the dependency resolution, we use an Eclipse SDK to install all required plugins to a target platform using command-line operations (for the details search for the
assembleTargetPlatfrom task). Then, we use the ant tasks from
maven-ant-tasks to convert the target platform to a maven repository (
installTargetPlatform task). Besides we use a bunch of other command-line applications from the Eclipse SDK to sign and condition (pack200) bundles, create P2 repositories, etc.
This is obviously just a workaround and not meant to be a general solution. For example, the plugin fragments are not handled correctly. To solve that in Buildship, we had to explicitly declare the SWT fragments as dependencies.
There are a few choices here. First, you could look into alternatives like Goomph whether Buildship and other plugins should just use that.
We could also look into what Eclipse Tycho does. I checked the sources a while ago and it seemed like a suboptimal solution. Frankly, I can’t quite recall what was there, maybe it worths another look.
The last approach would be to develop an Eclipse plugin that would expose the necessary features from an Eclipse runtime to the Gradle build. Here’s how it would work:
- At the beginning of the build, an Eclipse application (defined by our plugin) would start
- The Gradle build would query the P2 dependency information from the Eclipse runtime
- The Gradle build would declare dependencies in the build based on the results
This approach would give us complete freedom as the Eclipse plugin would have access to all APIs in the Eclipse runtime. We could programmatically create P2 repositories, sign bundles, execute integration tests, etc.
It’s certainly not an easy thing to implement. Let me know what you think.