| Samuel,
P2 searches the update site for bigger versions of the IUs installed local. Then it presents the result to you. What matters matters are the "root components" (don't know how the p2 guys call those) like your product.
e.g.: the whole software is installed by deploying 1 product - this product contains 10 sub-features or plugins => you can only update this product e.g. 3.6.0 to 3.6.1 - but you cannot update one of the sub-features because the product stats that it needs the exact versions of plugin/feature x defined in the product.
with this approach you get 1 big build, which is only updateable as a whole.
for my case (building automation server) i created a "base installation"-product. in my case this contains: + osgi runtime + webserver + a plugin which exposes a p2 administration servlet - there i can manage repositories, perfom updates, install new features and do reverts. (i want to set this open source but in the last days i can't find time to create some docs for it...)
=> then i export this product and deploy it where it has to run.
after this i can open the p2 admin website of this installation in the browser and install what is needed for this specific installation.
the advantages are: + you got a minimized installation + you can update sub-components also => you don't need to build "a big new product" for every bugfix.
if i want to update a feature, i simply increment the version of the changed plugins and the version of the feature. then export it on the update site and it can be installed.
hope this helps for your case.
greetings, Michael
Am 08.09.2010 um 19:55 schrieb Samuel Wu: My question actually is how you are going to install 3.6.1 on top of the existing 3.6.0. For instance, 3.6.0 contains 30 plugins and 2 of them have been updated in 3.6.1. You don't want the end user to pick up a 3.6.1 zip file and unzip it again.
Best Regards
Samuel Wu
<graycol.gif>"Yousouf, Shenol" ---09/08/2010 03:19:26 AM---Hello Samuel, I am sorry if I do not grasp some of the details in your use case so you may already b
<ecblank.gif>
From: | <ecblank.gif>
"Yousouf, Shenol" <s.yousouf@xxxxxxx> |
<ecblank.gif>
To: | <ecblank.gif>
P2 developer discussions <p2-dev@xxxxxxxxxxx> |
<ecblank.gif>
Date: | <ecblank.gif>
09/08/2010 03:19 AM |
<ecblank.gif>
Subject: | <ecblank.gif>
Re: [p2-dev] How to build an update site for a product? |
<ecblank.gif>
Sent by: | <ecblank.gif>
p2-dev-bounces@xxxxxxxxxxx |
Hello Samuel,
I am sorry if I do not grasp some of the details in your use case so you may already be familiar with the information that follows.
If you lack a product IU in the repository that gathers all the features/plugins you need, the usual way is to describe them in a .product file and publish it into the site you already have. You can automate the publishing process in an ant build by using the respective p2 ant tasks for that purpose. You can find further details about the various publisher applications on the following page:
http://wiki.eclipse.org/Equinox/p2/Publisher
If you need to publish a new release of your product, just increment the version attribute of the product file. The generated product IU will hold the necessary update metadata to signify that it replaces the older releases during install.
Hope this helps !
Best regards,
Shenol Yousouf
SAP Labs Bulgaria
From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Samuel Wu
Sent: Wednesday, September 08, 2010 12:34 AM
To: p2-dev@xxxxxxxxxxx
Subject: [p2-dev] How to build an update site for a product?
Hello there,
During the headless build of a product, an update repository is created. But it only contains the features/plugins. Wonder how to build a site which can ship a new release of the product. For instance, a 3.6.1 product which can be installed as update to 3.6.0. Thanks.
Best Regards
Samuel Wu_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
| 