Eclipse Woes: Import-Plugin

Posted on February 18, 2015 by Richard Goulter
Tags: , ,

Eclipse Plugin Development, I’ve found, has been fraught with with “learning experiences”.

They say it’s easy to create Feature projects & Update Sites for Eclipse.
Turns out when the exporter gives an error saying “I can’t find Installable Unit for your plugin”, something is wrong with your plugin project’s build!
– It’s possible for a PDE project to have a plugin which is valid when running an “Eclipse Application” to test the plugin; but still can’t be exported due to invalid settings.

Rather. It’s possible for Eclipse PDE to know about your plugin and not know about your plugin at the same time.
Argh!

For a PDE project created in Eclipse, my problem was a bad build.properties file. (Which tells Eclipse what order to build/export things, or so).
Sure. Fine.

I also had an OSGi-bundle generated from an SBT project:
Because Eclipse’s classpath & OSGi classpath don’t get on together at all, it’s necessary to have not just the standard Eclipse project, but a separate project with an OSGi-enabled MANIFEST.MF.

– Eclipse plugin dependencies must be OSGi Bundles. An OSGi bundle is a .jar whose MANIFEST.MF has some additional properties, detailing what the bundle exports & which bundles it needs. Eclipse needs to know about a ‘target platform’ of bundles for its plugins to work.
– This can be achieved by either installing the plugins to where Eclipse will load them when you run it; or, with Eclipse PDE (Plugin Development Environment), PDE can launch an Eclipse instance loading projects in the workspace as plugins. When developing plugins, it’s surely easier to not have to re-export & re-install plugins each time something changes.
At least, I’m pretty sure that’s how it works.
Simple, right? Such is Eclipse.

So. I need a project which has the OSGi bundle for some tool I’m working on, (a tool I might want to use outside of OSGi, because testing OSGi bundles can only be done within an OSGi environment. Working with some OSGi environment is the difficulty I’m having here, see).
One way to do this is PDE’s “New Plugin from Existing JAR…” project, which wraps a project around a JAR..
Another approach is to import a bundle and wrap a project around this JAR. (“Import Plugin…”).
These do not do the same thing
One works, the other doesn’t.
Wut.
Rather, with one, “Export Plugin…” works fine, but not for the other.

I mean, obviously, right?

If one wanted to investigate why one works, the other doesn’t, one might look at the differences in project settings between the two; and incrementally copy the changes across until both ‘work’.
– Turns out copying / replacing all the files from the working one to the not-working one, so that they’re identical, doesn’t solve this.
Unless, after making such changes to the project, the project is removed from the workspace and added back to the workspace. (Clearly this updates/refreshes some setting which “Refresh Project”, Closing/Opening the project don’t update. I don’t know what).
Clearly, right?

– Eventually I figured out that the manifest generated from an sbt-osgi plugin wasn’t in the format Eclipse liked it when importing it (though for running the plugin with PDE it’s okay); and a build.properties file wasn’t automatically generated when using “Import Plugin…”. That’s not so bad.
It amounts to a small amount of manual effort to setup a project with PDE. (No more ‘manual effort’ than typicap PDE things like exporting Plugins / Features / Update Sites).

Finally I could export the Plugin! (or a Feature using it, or an Update Site with that feature). Again, just using the plugin with PDE itself wasn’t as bad.

On a side note, it seems support for Tycho / building Features / Update-Sites for Eclipse isn’t so great for SBT compared to what support there seems to be for Gradle. - That matters in terms of automating the process of building an Update Site (particularly outside of Eclipse PDE GUI), though isn’t as pertinent to getting a PDE project of an OSGi Bundle.
(With an automatically generated Update Site, it’d be easier to install said plugin to the Eclipse environment you’re using, though, so..).


Newer post Older post