You are not alone In our case, the big difference is that everything was normalized. What I mean is that we had the same third-parties (checked-in source control) and same Eclipse target platform (also checked-in) inside a single big monolithic repository. Our old build system was custom but did not have Eclipse headless building feature like you.
Now, the main goal I had was to extract a subset of projects (related to same end product), gradlelized them and still be able to develop in Eclipse (and build command line all of them except those having direct Eclipse dependencies). The next milestone after extraction will be to make Eclipse headless build work from command line.
Extraction is now complete and all goals have been fulfilled for this part. To make it work, my current approach was to have a
vendor project, build semi-automatically that contains all third-parties jar. Target platform has been extracted to a distinct repository but still needs to be added manually to Eclipse workspace.
I did my experiments on this part in a repository. You can see a WIP branch (real work is however finish in the enterprise repository). I’m hoping to finish it soon as well with the associated documentation. You can check it out here.
Now, my next goal is to make the Eclipse headless build come true within my test repository above. Here some possible solutions I will try:
Wuff seems rather complex but it’s not. It simply downloads an Eclipse SDK (so it has access to Eclipse jars), This acts as the target platform. Then, it
mavenize the Eclise jars (because PDE has no notion of group, only artifact name and version) by tranforming for say the bundle
org.eclipse.core.runtime into a dependency usable by Gradle of the (here fake) form
My current concerns with it are: how to use a target platform instead of downloading an Eclipse SDK? how to continue development within Eclipse when using Wuff? I started a thread on Wuff repository to gather feedbacks on those two questions.
Buildship build system
I did not investigate it a lot yet but it would better fit my needs. As Builship is using them, I have a real-life working example of you I could leverage it. Just need to extract it. This is probably my next experimentation step for my Eclipse headless build task.
This is a tool used to work with OSGI at large based on bnd (don’t be afraid from there old site). I just encountered it recently but it has a Gradle support as well as an Eclipse plugin support. But this is a different beast as it completely ditched Eclipse PDE. What it means is that you must use some
bndtool metadata file. An inside Eclipse, bundle, features and plugins are build without relying on PDE at all. It’s the bndtools plugin that do the hard work of resolving everything and ensuring everything conforms to OSGI spec, completely replacing PDE. This is a hard step because it’s completely different. Not sure where I could go with it. But it’s wort mentioning.
I’m hoping to start again new experiments for Eclipse headless build in the upcoming weeks. Feel free to share any knowledge, findings, tips & tricks, problems with me. We could even chat about it sometimes.
Hope this helped you a little bit. Don’t hesitate to ask more information if needed.