|Buckminster for plug-in update sites [message #1677623]
||Mon, 16 March 2015 00:13
| Marian Schedenig
Registered: July 2012
I'm developing a few Eclipse plug-ins and publishing them on an update site on my own server. In the past, I've been building the update site via an Update Site Project. That had the occasional hiccups, but recently stopped working completely for one of the plug-ins.|
From another thread I've learned that this way of creating update sites seems to be outdated (though it still seems to be what the Eclipse help suggests), so I've been trying to switch to a Buckminster-built site.
My problem is that there is virtually no documentation on how to use Buckminster to create an update site for plug-ins. There's a ton of documentation out there that describes the detials of Buckminster and how to use it to build and deploy products, but that's not what I want to do and frankly I don't want to invest a significant amount of time to learn how to create and manage RCP products (which I have no plans of doing) just so I understand enough of these documents to figure out how to change the process for a simple plug-in site.
I did manage to get the very basics out of some of the available tutorials, namely how to create a feature that describes the update site. Via the IDE, I can use the site.p2 action to create an update site from the referenced plug-ins and features in my workspace. Categories (including a separate one for sources) and build timestamp qualifiers work well.
But there are a few more basic issues I have to work out before I feel comfortable with this, and so far I've had no luck:
1) Keep old versions in the update site repository when adding new ones
The old update site project did that automatically. In fact, it got unstable when anything interfered and deleted any of the older files. Which always made it a bit scary to me, but at least it mostly worked. With Buckminster, the entire site is build from scratch each time, so nothing is kept from the previous version.
I'm awar of "composite repositories", but as far as I understand, I'd then have to set up a separate update site for each new version I release, even for minor bug fix updates. Surely there must be an easier way? See also #3.
2) Headless build
Supposedly, the point behind Buckminster is that it can be used in a headless fashion. I've succeeded in installing the headless version of Buckminster via Director, and I've also added the necessary features so it understands the site.p2 command. But when I try to build the site from the console, I get the following error:
No component named org.eclipse.ui:osgi.bundle is known to Buckminster
As far as I've been able to figure out, this should be related to the target platform. Apparently, calling Buckminster from the Eclipse IDE uses the running RCP as the target, so all the standard bundles are available. But I haven't been able to find out how to tell Buckminster which target to use from the command line.
(This never worked with the old update site project, so it's more of a bonus goal, but I'd certainly trust Buckminster more if I saw this working)
3) Rebuild only some of the plug-ins
I'm currently maintaining 5 different plug-ins. Usually I'm only working on one of them at the same time, but if I want to release plug-in A while plug-in B is currently in a broken or unfinished state, I obviously don't want to deploy a current build of B to the site (if B can even be built correctly). But since Buckminster always clears and rebuilds all projects, I don't know how to control this.
I could obviously have two workspaces, one of them only containing the exact latest versions that should be on the site, but that's more complicated than it should be. I imagine this might be somehow tied to question 1.
I understand that Buckminster can deal with various version control systems. I'm using Git, but I haven't been able to find any documentation that touches this without going the full RCP product way.
I'd be more than happy to sum this up in a tutorial blog post once I know how it works.
Powered by FUDForum
. Page generated in 0.01990 seconds