Is it possible to build an Eclipse plugin

Hi, I’m interested if it’s possible to build an eclipse plugin (or whole RCP application) using gradle. I’ve simple project which depends on several plugins from p2 repository. I was wondering if it’s possible to build such project using gradle.

Cheers, P

Hello P, There is no full blown gradle support for building eclipse plugins / rcp apps yet. Grégrovy Boissinot started the pdePlugin for gradle a while ago. This is a thin layer on top of the eclipse PDE build. You can find this plugin at github (https://github.com/gboissinot/gradleplugins)

regards, René

I started to look at the pdePlugin, just in case anyone else is interested, here is what I did to get the pde plugin Project in our maven Repository:

  • download the latest sources (7.1.3 in my case) * in the base gradle.build file: ** remove the ivy configuration (starts with org.apache.ivy.util…) ** replace the uploadArchives configuration with your own company settings * do a gradle uploadArtifacts * you can now use the plugin when after importing it with the buildscript{} element

Right now I’m trying to get the samples working, they seem to be written for Gradle 0.9-rc-1 (?). I’m using 1.0-milestone-7

Right now I’m trying to get the samples working

… are you still trying?

no :slight_smile: it didn’t take 5 months to get it working :wink:

Unfortunately I don’t have access to the sources for the next few weeks, so I can’t give you a summary of what I needed to change.

The plugin is a wrapper around the pdeBuild ant - Task. So If you’re able to run that, it shouldn’t be too much work to get it working using the plugin. This means that you can build a product.

IIRC: pde tests are not executed out of the box (Rene correct me if I’m wrong). We worked around this issue by defining a ‘normal’ Gradle build that compiles our plugins and runs all of our tests outside an OSGI - container. This worked for us because we have no gui tests and we also don’t test any OSGI - specifics.

Another downside of it is that we currently have the plugin dependencies in two places - the Manifest and in build.gradle. In order to be able to resolve our plugin dependencies, we uploaded artefacts for all plugins in our target platform to our Maven Repository (using the mvn eclipse plugin).

HTH.

Eclipse now has a Maven plugin called Tycho. I didn’t try, just read about it. I think it would be gread if Gradle had a comparable plugin.

Well I guess for now we’re stuck with Tycho.

Well I guess we have to stick with Tycho.

I’ve taken a look at the original pdePlugin and I’m in the process of bringing it in a usable state for gradle 1.3. I’ve also added a couple of features to it that I needed and I’m almost done. I’ll release the code on github in my personal repo and with a PR to Gregory for good measure.

Right now I’ve gotten the feature sample to work but can’t get the product sample to compile. I won’t try any further for product build because I don’t need it right now, but I might come back to it eventually.

Hello,

I’d like to revive this thread to know from the source what the status of building Eclipse plugins / products with Gradle is.

Thanks in advance,

Laurent

Hi Laurent,

There’s been no change in terms of core support. You’ll have to check in with the plugins linked to above.

HI, I am using Gradle 1.9 on which I am not able to use pdePlugin7.1.5.Getting some error NoSuchMethod allTasks(). Can you please , who used this plugin to develope eclipse plugin, guide me to use this in developing Eclipse plugin.

Thanks In advance.

I’ve forked the original pde Plugin here: https://github.com/pgelinas/gradleplugins. It is known to work with gradle 1.3, so it should work with 1.9. It’s been months since I’ve used it though, there might still be some rough edges.

Hi Pascal, I tried with your forked pdePlugin but still not able to build my plugin using it. I have configured pdeBuild but getting failure message -

:pdeBuild FAILED FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ‘:pdeBuild’. > No such property: jar for class: java.lang.String

Here is my configuration- pdeBuild {

def projectDir = getRootDir()

envConfigs = “linux, 3.2.0-52-generic, amd64, unix”

buildDirectory = “${projectDir}/build/work”

publishDirectory = “${projectDir}/build”

pluginsSrcDirList = ["${projectDir}/…"]

builderDir = “${projectDir}/build”

base = “/home/epeyrul/NGMM/Eclipse-RCP”

buildId = “ProductOnPluginsExample”

baseLocation = “/home/epeyrul/NGMM/Eclipse-RCP/eclipse”

eclipseLocation = “/home/epeyrul/NGMM/Eclipse-RCP/eclipse”

equinoxLauncherPluginVersion = “1.3.0.v20130327-1440”

pdeBuildPluginVersion = “8.0”

productName = “/ProductOnPluginsExample/simplemailproduct.product”

}

Please help me to build sample plugin first then I’ll try to build my plugin.

Please open an issue on the github repository with the full stack strace (gradle -s) so I can better help you. Thanks.

Regarding original question: yes, now it is possible. Today I released new gradle plugin: Wuff version 0.0.1. It fully automates assembly of OSGi/Equinox/Eclipse-RCP/Eclipse-IDE bundles and applications.

Sources and doc: https://github.com/akhikhl/wuff

Wuff is available at jcenter and maven central.

After a quick reading through your wiki docs I got the impression that you did a fine work and the plugin deserves a try.

Some questions remain: - with the Gradle build using the plugin, the compiler is a regular Javac. Therefore, the compile process does not depend on the “Export-Package” definitions of the MANIFEST.MF but uses the Gradle dependencies, i.e. “compile project(:‘some.subproject’)”? - Will the plugin respect user defined entries (done in the IDE) within “plugin.xml” or “MANIFEST.MF”? This means: for the IDE developper the Gradle build scripts are fully transparent?

Answers: 1. Wuff supports two opportunities: dependency as compile project(’:some:subproject’) and dependency as Require-Bundle in MANIFEST.MF. Require-Bundle is automatically translated to project-level dependency, as soon as project tree contains a project with given symbolic-name in manifest. 2. Wuff respects user-defined plugin.xml and manifest, yes. Although these files can be completely omitted - it will generate them as necessary.

I’ve written tutorial on converting existing Eclipse plugins and apps to Gradle/Wuff:

BTW, version 0.0.2 is out.

Answers: 1. Wuff supports two opportunities: dependency as compile project(’:some:subproject’) and dependency as Require-Bundle in MANIFEST.MF. Require-Bundle is automatically translated to project-level dependency, as soon as project tree contains a project with given symbolic-name in manifest. 2. Wuff respects user-defined plugin.xml and manifest, yes. Although these files can be completely omitted - it will generate them as necessary.

I’ve written tutorial on converting existing Eclipse plugins and apps to Gradle/Wuff: https://github.com/akhikhl/wuff/wiki/Convert-existing-Eclipse-plugins-and-apps-to-Gradle

BTW, version 0.0.2 is out.

Documentation will be improved with these valuable details.