Home » Archived » Buckminster » Again the dreaded "No updates found" for a Buckminster -built RCP product(When building an RCP product and a related p2 repository with Buckminster, never an update is found )
| Again the dreaded "No updates found" for a Buckminster -built RCP product [message #875978] |
Wed, 23 May 2012 16:50  |
 Matthias Paul Scholz
Messages: 40
Registered: May 2012 |
Member |
|
|
Hi all,
This is a topic that has come up earlier and I worked through everything I found here and on other places, but after two days of frustration and fruitless efforts I decided to drop a question finally:
For my Eclipse RCP product, I can create an executable by using Eclipse's export wizard for Linux x86 that runs fine. Also the P2 repository created that way works well and the RCP client can be updated with new versions from that repository.
I can also create an Eclipse RCP product that works without any troubles using a headless Buckminster build.
My problem is, though, that this Buckminster-built product can never be updated from the p2 repository, regardless whether this p2 repository has been built by the Export Wizard or by the site.p2 feature of Buckminster: it always states that "no updates are available" (no further error or log messages).
I tracked it down to the version qualifiers not being replaced in the p2 profile which is packed into the p2/org.equinox.p2.engine folder of the created application.
From various threads dating back to 2009 I have seen that there's a workaround for that by just not specifying a version in the .product file that is located in the app's feature. Doing so, the qualifiers in the said profile look fine indeed, but the update still does not work for the P2 repository created by Buckminster's site.p2 (as a matter of fact, not even the update of a product created by Eclipse's Export wizard does that any more for the related P2 repository).
The other option stated in said discussions was to use p2.gathering=true and setting the p2.product.qualifier variable to something useful; yet, that never worked for me (qualifiers in generated profile get not replaced).
So I'm pretty much out of my depths here.
Any help would be pretty much appreciated.
Thanks,
MP
|
|
| | |
| Re: Again the dreaded "No updates found" for a Buckminster -built RCP product [message #950503 is a reply to message #950166] |
Fri, 19 October 2012 23:53  |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
On 2012-19-10 19:38, Andrea Richiardi wrote:
> Oh, I actually found that my p2 site has been created, but it is not
> under the buckminster.output.root folder.
Its where it is because you could be building more than one site, or
more than one version of a site throughout the lifetime of what is under
the buckminster root.
> It is under
> buckminster.output.root/com.test.myfeature_1.0.0-eclipse.feature/site.p2, and
> contains the feature jar.
>
Location is named after the component and the action to make it unique.
> Now, at least I understood where to put the .property file.
> The fact is, I would like to obtain the same configuration as eclipse's
> repositories, where you don't have to browse to the site.p2 folder in
> order to have find your site. For example, in my case I am trying to
> have artifact.xml directly under buckminster.output.root.
>
> IS there a way to accomplish that using a releng repository (so that you
> are still able to change build properties?
Why not add a separate action that copies the update site to where you
want it to be? When we build Geppetto, we typically copy the repo result
to the location from which the webserver provides it.
Regards
- henrik
|
|
| |
| Re: Again the dreaded "No updates found" for a Buckminster -built RCP prod [message #953784 is a reply to message #953720] |
Mon, 22 October 2012 14:22 |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
On 2012-22-10 15:34, Andrea Richiardi wrote:
> Yes, that is a good idea, but the problem is that I thought there was an
> "update" function for your repositories.
>
Not really. You also need to keep the old versions to allow users to
rever to an older build; can't just merge stuff. And if you mix all
releases into one big bucket you have a huge problem when you want to
prune a particular build (one you do not want to let users revert to).
> Let's say I build every hour my feature:
> - Is the site.p2 action rebuilt every time (my feature includes other
> plugins/features that need to be there for the application to run) ?
> - Do I have to copy the whole site every time then ?
>
afaik, it is rebuilt; it is a new copy/version of the respository.
> Sorry I am really newbie to Buckminster but in my mind every time I
> build a feature/plugin I just want to copy the resulting jar (plus its
> metadata) to the p2 site in order for my eclipse client to directly
> update from there.
>
> Will I be able to do that?
We maintain a composite repository where we add each new build as a
child of that repository. We prune this composite repository and remove
old builds that we do not want the client to be able to "roll back to".
Naturally each copy takes up disk space, but our project is not that
big, so this is a reasonable tradeoff.
Not sure if there are free utilities that directly help you do that.
There are repository products (Yoxos comes to mind) that uses a more
efficient way of storing/referring to repository content and making it
manageable.
What we do (in development) is always run self hosted (no installing or
updating) to run all the tests etc. until happy with the developed code.
Once that is done we build on our Jenkins build server (and run all the
tests) to see if build is ok. If we want to release that version (in
some stream), we link that built result into the aggregate/composite
repository (and perform any pruning).
Although we can build the product locally, we do not normally gain much
by this step as we want to always do a clean build on the server to
ensure that there are no influences from a particular developer's
environment that affects the outcome of the build. Running it locally
first typically just adds an extra step - 99.9% of the time it works
locally anyway).
We test the ability to update the product as part of the release
process. Typically we test each build without updating it (i.e.
downloading a zip and running that) - it just becomes too confusing
keeping track of what is being tested, and prefer to just refer to the
overall version of the product. (This especially when making these
releases available to external testers). [i.e. nightly builds do not
update, release candidates do]. Also found that as long as we are not
doing any special stuff with updates (such as rearranging the
dependencies/inclusions/renaming etc.) we really do not need to test the
update - we just release since for us updates have worked in 99.9% of
the releases. Instead, if an issue is found, we fix it immediately.
We have some commands that help us copy the repo and link it to the
composite repository, but they are specific to our project - should not
be hard to write. Someone else may have written something similar and
made it available.
Are you using Jenkins? If you do, a typically setup builds the zips and
the repo and they are then available from Jenkins with URLs for things
like "latest result". Have not tested to update directly from such a
build - I imagine that would work, but as I said we prefer to test the
nightly builds without such updates.
Hope that helps.
- henrik
|
|
|
| Re: Again the dreaded "No updates found" for a Buckminster -built RCP prod [message #954067 is a reply to message #953784] |
Mon, 22 October 2012 19:12 |
Andrea Richiardi
Messages: 64
Registered: August 2012 |
Member |
|
|
I actually have a really similar spec for my site too.
I want to be able to run builds on a separate server, using Cruise Control.
This post really helped me, thanks!
It's clear now that every time there is a new build I have to rebuild my p2 site.
In my p2 site there will be the jar of my plugin, the svn site i am pulling the plugin source from will be on the same machine (or other).
I guess that the moment I build the plugin from the svn I will also need all its dependecies...somewhere? In the p2 site?
I am also playing with the materializing part..."No component found" is the message I most commonly receive when I try to mimic the mailapp tutorial (I will probably open another post on that, seems a different issue).
Anyway, thank you very much for your answers.
[Updated on: Mon, 22 October 2012 19:13] Report message to a moderator |
|
|
| Re: Again the dreaded "No updates found" for a Buckminster -built RCP prod [message #963147 is a reply to message #953784] |
Mon, 29 October 2012 15:54 |
|
On 10/22/2012 04:22 PM, Henrik Lindberg wrote:
> We test the ability to update the product as part of the release
> process. Typically we test each build without updating it (i.e.
> downloading a zip and running that) - it just becomes too confusing
> keeping track of what is being tested, and prefer to just refer to the
> overall version of the product. (This especially when making these
> releases available to external testers). [i.e. nightly builds do not
> update, release candidates do]. Also found that as long as we are not
> doing any special stuff with updates (such as rearranging the
> dependencies/inclusions/renaming etc.) we really do not need to test the
> update - we just release since for us updates have worked in 99.9% of
> the releases. Instead, if an issue is found, we fix it immediately.
How do you test that the product can be updated?
cheers
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134 (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
| | | |
Goto Forum:
Current Time: Mon Dec 30 17:52:32 GMT 2024
Powered by FUDForum. Page generated in 0.04663 seconds |
] 
Search
Help
Register
Login
Home
