Home » Archived » Buckminster » Creating plug-in update sites
| Creating plug-in update sites [message #1690564] |
Sat, 28 March 2015 23:21  |
 Marian Schedenig
Messages: 18
Registered: July 2012 |
Junior Member |
|
|
I originally posted this in the P2 forum as a follow up to another question, but obviously it belongs here. In short, I'm new to Buckminster and trying to come to grips with it within the rather limited scope of generating a P2 site for the plug-ins in my workspace.
---
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.
Thx,
Marian.
|
|
|
| Re: Creating plug-in update sites [message #1690637 is a reply to message #1690564] |
Mon, 30 March 2015 09:34  |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
If you are changing publishing technologies you should consider all the
alternatives. Three years ago Buckminster was the prevailing bandwagon.
Today it seems to be Tycho.
Regards
Ed Willink
On 28/03/2015 23:21, Marian Schedenig wrote:
> I originally posted this
> https://www.eclipse.org/forums/index.php/m/1690563/ as a follow up to
> another question, but obviously it belongs here. In short, I'm new to
> Buckminster and trying to come to grips with it within the rather
> limited scope of generating a P2 site for the plug-ins in my workspace.
>
> ---
>
> 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 https://www.eclipse.org/forums/index.php/m/1652494/ 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.
>
> Thx,
> Marian.
>
|
|
| |
Goto Forum:
Current Time: Tue Apr 23 10:31:57 GMT 2024
Powered by FUDForum. Page generated in 0.03216 seconds |
] 
Search
Help
Register
Login
Home
