Again the dreaded &quot;No updates found&quot; for a Buckminster -built RCP producthttps://www.eclipse.org/forums/index.php/mv/msg/354684/875978/#msg_875978
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]]>Matthias Paul Scholz2012-05-23T16:50:52-00:00Re: Again the dreaded &quot;No updates found&quot; for a Buckminster -built RCP producthttps://www.eclipse.org/forums/index.php/mv/msg/354684/949509/#msg_949509
I have the same problem, and I have noticed that in my case, choosing the site.p2 action for instance, the artifact.xml file is not showing up.

Can this be the problem?

In my case I have a classic releng feature which contains a product feature.
]]>Andrea Richiardi2012-10-19T03:19:12-00:00Re: Again the dreaded &quot;No updates found&quot; for a Buckminster -built RCP producthttps://www.eclipse.org/forums/index.php/mv/msg/354684/950166/#msg_950166
It is under buckminster.output.root/com.test.myfeature_1.0.0-eclipse.feature/site.p2, and contains the feature jar.

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?]]>Andrea Richiardi2012-10-19T17:38:10-00:00Re: Again the dreaded &amp;quot;No updates found&amp;quot; for a Buckminster -built RCP producthttps://www.eclipse.org/forums/index.php/mv/msg/354684/950503/#msg_950503
> 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]]>Henrik Lindberg2012-10-19T23:53:50-00:00Re: Again the dreaded &amp;quot;No updates found&amp;quot; for a Buckminster -built RCP producthttps://www.eclipse.org/forums/index.php/mv/msg/354684/953720/#msg_953720
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 ?

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?]]>Andrea Richiardi2012-10-22T13:34:53-00:00Re: Again the dreaded &amp;amp;quot;No updates found&amp;amp;quot; for a Buckminster -built RCP prodhttps://www.eclipse.org/forums/index.php/mv/msg/354684/953784/#msg_953784
> 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]]>Henrik Lindberg2012-10-22T14:22:08-00:00Re: Again the dreaded &amp;amp;quot;No updates found&amp;amp;quot; for a Buckminster -built RCP prodhttps://www.eclipse.org/forums/index.php/mv/msg/354684/954067/#msg_954067
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.

]]>Andrea Richiardi2012-10-22T19:12:39-00:00Re: Again the dreaded &amp;amp;quot;No updates found&amp;amp;quot; for a Buckminster -built RCP prodhttps://www.eclipse.org/forums/index.php/mv/msg/354684/963147/#msg_963147
> 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.comhttp://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.comhttp://longlivemusic.blogspot.comhttp://www.gnu.org/software/src-highlitehttp://www.gnu.org/software/gengetopthttp://www.gnu.org/software/gengenhttp://doublecpp.sourceforge.net]]>Lorenzo Bettini2012-10-29T15:54:55-00:00Re: Again the dreaded &amp;amp;quot;No updates found&amp;amp;quot; for a Buckminster -built RCP prodhttps://www.eclipse.org/forums/index.php/mv/msg/354684/963154/#msg_963154
> 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
>
Manually. Keep an old version around, try to update it. Then to revert it.

- henrik]]>Henrik Lindberg2012-10-29T15:59:33-00:00Re: Again the dreaded &amp;amp;amp;quot;No updates found&amp;amp;amp;quot; for a Buckminster -built https://www.eclipse.org/forums/index.php/mv/msg/354684/963161/#msg_963161
> I guess that the moment I build the plugin from the svn I will also need
> all its dependecies...somewhere? In the p2 site?

We do rely on Eclipse to provide the platform etc. We do not have a copy
of everything in our repository. Basically just our stuff and what is
not found in the main eclipse repository.

OTOH, if we were a bigger operation and had the resources we would
probably have a mirror of the rest as well to ensure that our capability
to deliver was not dependent on Eclipse.
In this case we would not mix the two (our stuff & eclipse stuff) into
the same repo - just maintain a mirror. This is also useful when building.

Hope that helps.
Regards
- henrik]]>Henrik Lindberg2012-10-29T16:05:58-00:00Re: Again the dreaded &amp;amp;amp;quot;No updates found&amp;amp;amp;quot; for a Buckminster -built https://www.eclipse.org/forums/index.php/mv/msg/354684/973843/#msg_973843
To maintain the versioning of the target platform itself (plugin 3.2.1 has to match target plaftorm for version 3 of the product for example). I was thinking of having a SVN for that too.

This way, I will avoid wasting space for target platform plugins that are in common, and I can choose a target platform version just changing the SVN revision used in the rmap.

This is the idea, I will try to implement it first using a "local" content provider to see if it works.]]>Andrea Richiardi2012-11-06T17:11:38-00:00