Hi to all,
I have two company related plugin projects, which I build with gradle and my own gradle plugins. I have also seen that in buildship you have build logic in buildSrc. I have already heared that you want to provide plugins to build eclipse features and bundles with gradle. My question: Do you have concrete plans when you want to provide them or do you still look for contributers, who can do this?
Cheers
Markus
Nothing planned? If you are looking for contributors for this feature I could imagine to help on this.
Hi,
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:
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.
Hi,
thank you for your detailed answer. As I am already working on a solution to build eclipse-plugins and was implementing https://github.com/moley/egripse ( but implementing some things like target platform in a way they appear as workaround, too), I’d like to implement something which could be also used by others, and perhaps together with others to get a general solution.
Last weekend I have started to get an overview over goomph and tycho. I am completely open in mind how the implementation could look like, here are some thoughts on the things you have written in your post:
I like this idea to use oomph to create the targetplatform as we already use oomph itself (editing xml directly) to create our teamwide ide and it works very good for us. We didn’t notice the existence of goomph yet. Furthermore oomph seems to be a widely accepted solution (please correct me if I’m wrong). So I could imagine that providing oomph functionality in gradle could be a cool thing to assist in both cases. The question is to reuse the existing plugin or try to get the maintainers of goomph on board to provide an integrated solution.
The tycho implementation I didn’t find yet, but I understand it like they provide a way to work with p2 directly by adding an own dependency resolver… which has the advantage to be very fast because done in maven, but at cost of having an own implementation, which has to be maintained.
As I understand you want to create a eclipse bundle to provide all kinds of informations both for the command line build and building eclipse plugins in Eclipse itself and then start it (as permanent background process like daemon) in case of command line build or simply use it in case of gradle build in eclipse runtime to get infos and trigger implementations? Did I understand it right? On the one hand this gives us maximum flexibility because we could expose ANY kind of functionality to the build and don’t have to use headless applications provided by others, but have to do our own implementations which have to be maintained. On the other hand I think especially resolving dependencies should work very very fast because it is done very often. And I fear that starting an eclipse with our custom plugin could be too slow to have a runny build. But perhaps I overlook anything…
So I would be interested in your thoughts about my writings, all in all I think it’s an exciting thing to implement.
Cheers
Markus
That’s correct. Buildship also contributes an Oomph profile to the installer to speed up the development environment setup.
Not exactly, my idea concerns only the command line. What I have in mind is a plain Gradle plugin that builds Eclipse plugins. The Gradle plugin would spawn a new Eclipse application daemon and interact with it via RMI or equivalent.
Note, that the word ‘application’ is special here: it’s a variation on the RCP apps. A good example of how these applications work is the P2 director application: documentation, source.
Inside the application, we could use all Eclipse APIs we need for the builds, P2, and whatnot. From the Gradle plugin, we could collect the build configuration (project location, osgi manfests, etc) and pass it to the application. Does this make sense to you?
Ok, I understand. This approach is from my point of view good for features, which are not performance critical (e.g. when building updatesites etc). For things that have to be called in every build I am sceptical to get a good performance…