Hello Jeff,
I can assure you that we at SAP are very dedicated to seeking a
clean standardized solution for the update of our products and, accordingly, making
the necessary contributions to the p2 director (possibly something more refined
than simply simulating an update by combining uninstall and install in one step).
At the moment, however, we are stuck with the current situation so I explored the
options that would fit best our business use case. (not hacking it ;))
Best regards,
Shenny
From:
p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Jeff
McAffer
Sent: Tuesday, September 28, 2010 10:20 PM
To: P2 developer discussions
Subject: Re: [p2-dev] Product publishing and product update
Products are singletons. You can only have one product in an
eclipse install. That is the definition of a product. It is
"the thing that this install is". It includes the launcher, the
.ini settings, branding, ... While under the current model it is possible
to install multiple *different* products in one install that is more of an
omission than a design point.
I strongly caution people *against* making container
features that use requires rather than includes to get flexibility in updating
products. This will lead to non-determinisim and unmaintainable end-user
installs unless you carefully manage the repos available to your end users.
AFAICT the only real problem we are discussing here is the
absence of an *update* option in the director app. If you had that you
should be able to simply update the already installed product. If you were
running the p2 UI from inside your product for example, you would be able to
update the product. I suggest you look at adding update to the director
app rather than hacking your product architecture.
On 2010-09-28, at 12:19 PM, Yousouf, Shenol wrote:
My thanks to all participants in the mail thread who gave me
some hints how to find a solution !
I had overlooked the possibility to define composite features.
However, they are not real products and cannot take the benefit of the
configuration units which are generated automatically during product publishing.
I tried to find some way which preserves the product IU in the
p2 repository but makes it “updateable” in some way. After some
research of the planner, I still tend to believe that the
“singletonness” of the product IU has something to do with the fact
that new product version cannot be installed on a system where the product has
been previously installed. So
I decided to work around this by wrapping the product inside a non-sngleton IU.
This can be done very easily by instrumenting the publishing process with a
special p2.inf file placed in the same folder as the .product file. Sample
contents of p2.inf follow:
units.1.id=TestProduct.updateable
units.1.provides.1.namespace=org.eclipse.equinox.p2.iu
units.1.provides.1.name=TestProduct.updateable
units.1.provides.1.version=1.0.0
units.1.requires.1.namespace=org.eclipse.equinox.p2.iu
units.1.requires.1.name=TestProduct
units.1.requires.1.range=1.0.0
(More details on customizations with p2.inf can be found here.)
So now both the product and the new units end in the same p2
repository and you perform all installations from the new IU
(TestProduct.updateable). When your product is updated, you increment the
versions in the .product and the p2.inf files and republish it again. (Version
incrementation is possible, for example, with string substitution tasks in ant
and maven builds.)
Please, find attached two simple repositories produced by two
runs of the proposed procedure. You may install TestProduct.updateable from
test_repo1 (old version) and then update it from test_repo2 (new version). You
will notice that the bundle with the new version successfully replaces the old
one during update.
Please, take note that the proposed solution preserves the
product definition in the repository along with all of the advantages to
install from a product (instead of a feature ;)) ; the only overhead to the
publishing process is the addition of the p2.inf file.
I’ll be glad to have your feedback about the suggested
algorithm !
In the end, I would also like to raise the question why the products are chosen to be
published as singletons whereas features and bundles are not.
From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Samuel Wu
Sent: Tuesday, September
28, 2010 5:56 PM
To: P2 developer
discussions
Subject: Re: [p2-dev]
Product publishing and product update
Thank
you, Shenny, for the information. I'll try it out.
As to question on my work around. I created a root feature which contains all
the other features. The other features are added to the Included Features page
of the feature.xml of the root feature. An update site project can be created
to include this root feature. Once this root feature is built, all the included
features are also built. And you can install the root feature from the update
site created.
Hope it helps.
Best Regards
Samuel Wu
<image001.gif>"Yousouf, Shenol"
---09/28/2010 07:55:06 AM---Hi Samuel, You can use the product publisher
application to the same purpose and there are also corr
|
|
|
|
|
|
|
|
<image004.png>
09/28/2010 07:55 AM
|
|
|
<image004.png>
Re: [p2-dev] Product publishing and product update
|
|
|
|
Thank you,
Andrew,
I just realized that the exporting a product from GUI actually produces a
repository of the product as IU. Is it possible to generate the same repository
from a headless build?
Best Regards
Samuel Wu
<image001.gif>Andrew Niefer---09/27/2010
11:26:56 AM---As Jeff pointed out, you need to "update" the product.
The director application does not have any a
|
|
Andrew Niefer/Ottawa/IBM@IBMCA
|
|
|
|
|
|
|
|
|
Re: [p2-dev] Product publishing and product update
|
|
|
|
|
|
Samuel Wu/Toronto/IBM@IBMCA
|
|
|
|
|
|
|
|
|
Re: [p2-dev] Product publishing and product update
|
|
|
|
Hi Shenny,
I ran into the same problem as yours. I posted question on how to update an
installed product but haven't figured it out yet. My current work around is to
only use the product as a stub. All the features are built under another main
feature and install that main feature to the product instance. The installed
main feature can be updated. You may want to try this approach.
I still want to know how to update a product. Although the package is small, it
may still contain bug that needs to be fixed.
Best Regards
Samuel Wu
<image001.gif>"Yousouf, Shenol"
---09/27/2010 10:08:55 AM---Hi, First, thanks for the dedicated support and the
quick responses ! :)
|
|
|
|
|
|
|
|
|
|
|
Re: [p2-dev] Product publishing and product update
|
|
|
|
Hi,
First, thanks for the dedicated support and the quick responses ! J
I checked the official p2
director documentation but none
of the described arguments do not explicitly point to an update functionality.
Only the options for install and uninstall of IUs are quite apparent.
I also reviewed the options constants in DirectorApplication to make sure that
none of them are missed in the documentation.
Maybe it is some combination of parameters which is not known to me. I’ll
check for further information on the net but I’d really appreciate any
help to speed up resolving this case.
Best regards,
Shenny
From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Jeff McAffer
Sent: Monday, September 27,
2010 4:26 PM
To: P2 developer discussions
Subject: Re: [p2-dev] Product
publishing and product update
Seems in step 7 you are trying to *install* the new version of the product
rather than *update* the existing version. This seems like the source of the
difficulty. I don't remember the various director arguments but there likely is
one that does update.
Jeff
On 2010-09-27, at 8:28 AM, Yousouf, Shenol wrote:
Hi,
Yep, wrong setup is the most probable reason for that; however, I tried to
minimize the product configuration in order to avoid dependencies to other
factors as much as possible and I still can’t see where the problem is
coming from. Here is what I am doing:
1. Download standard Eclipse IDE, at least version 3.6. Personally, I tested on
Eclipse 3.6.1 and 3.7 M2a to the same effect. Run it without any
modifications in a clean new workspace.
2. In the IDE create an empty bundle (no activator, no sources) and a feature
which includes this bundle.
3. Create a new Product Configuration (File à New à Product
Configuration…) which includes only this feature. The option for native
launcher artifacts in the Product Editor must NOT be checked. (we don’t
need any extra IUs). Append some version to the product in the Overview tab.
4. Run the “Eclipse Product export wizard” (available as a link in
the “Overview” tab in product editor) and publish the product to
some directory. The only difference from the default settings is that I uncheck
the “Synchronize before exporting” checkbox in the wizard,
otherwise the export is not possible (probably because product has no plugin to
synch, only a feature). A sample p2 repository which is a result from the first
export is attached as “repository1.zip”.
Alternatively, instead of using the wizard, you can first export the feature
and then run the product publisher application against the feature repository.
The final p2 repo looks identical.
5. Run the p2 director application from the IDE to install the just exported
minimal product (sample application arguments: ” -os
${target.os} -ws ${target.ws} -arch ${target.arch} -nl ${target.nl} -consoleLog
-console -repository file:/e:/temp/test_repo/repository -installIU TestProduct
-destination e:/temp/test_install -profile Test -bundlepool
e:/temp/test_install”)
6. You may want to delete the repository from step 4 to regenerate it again
from scratch but it won’t influence the final outcome. Increment the
product version in editor and export it again. Note that in the result
repository (example is attached as “repository2.zip”) both the
product and the included feature versions have increased.
7. Try to install the “updated” product with the p2 director
application to the same installation location used in step 5. The installation
fails with message that looks something like this:
“!MESSAGE Only one of the following can be installed at once:
!SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2010-09-27 14:38:29.642
!MESSAGE Test Product 0.0.1 (TestProduct 0.0.1)
!SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2010-09-27 14:38:29.642
!MESSAGE Test Product 0.0.2 (TestProduct 0.0.2)”
I tested this procedure on several different versions of Eclipse and also on
the PCs of my colleagues to avoid local setup factors. So I’ll be
grateful to anyone who can show me what I am doing wrong here. Thanks in
advance !
Best regards,
Shenny
From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Jeff McAffer
Sent: Friday, September 24,
2010 10:44 PM
To: P2 developer discussions
Subject: Re: [p2-dev] Product
publishing and product update
Must be something quirky in your setup as my customers and I do this all the
time.
The singleton-ness should not be an issue as you are wanting to update/replace
this IU anyway so there will only be one.
Jeff
On 2010-09-24, at 11:17 AM, Yousouf, Shenol wrote:
Hello again,
I am continuing with some experiments along the directions that Jeff gave me. I
encountered several problems for which I cannot find an explanation. For
example, I tried to update the product after incrementing its version in the
repository. The update failed again because it lists among its requirements a
tooling configuration unit which is a singleton. It looks quite simple:
<unit id='tooling<product name>.configuration' version='<product
version>'>
<provides size='1'>
<provided namespace='org.eclipse.equinox.p2.iu' name='tooling<product
name>.configuration' version='<product version>'/>
</provides>
<touchpoint id='null' version='0.0.0'/>
</unit>
Note that this is generated by the product publisher and cannot be avoided. I
don’t have any idea what the purpose of such a basic unit could be but
being a singleton and a requirement of the product, it stops the update of the
whole product because there is already an IU installed with the same name on
the system (actual message from p2 director says “Only one of the
following can be installed at once”, concerning this IU).
Can anybody tell me why is this configuration unit created at all on publishing
?
In general, I am very surprised to see how many problems I encounter to
implement a “simple” product update given the fact that p2 supports
updates of features and bundles out of the box. So far, the most direct
approaches I tried failed completely:
- If I try to update, preserving the same product version (as it
is fixed in the .product descriptor), it fails because of conflicting versions
of the requirements.
- If I try to update with an increased version of the product, then the
singleton configuration unit stops me.
So it seems that my initial concept how the product update should be done is
wrong. But then how new versions of products are supposed to be shipped to
customers to be consumed immediately by p2 ? How are the customers supposed to
perform updates of the whole product (not by individual bundles and features) ?
Best regards,
Shenny
From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Jeff McAffer
Sent: Friday, September 24,
2010 4:36 AM
To: P2 developer discussions
Subject: Re: [p2-dev] Product
publishing and product update
There are a couple sides to this. One is that if you have Product X v
1.2.3.20100923, that should mean something. If you allow ranges as described,
then two users installing X 1.2.3.20100923 may not get the same actual software
installed. Variation is introduced for example, if user 1 has access to a
different set of repos than user 2 or there is a network error for user 1 but
not user 2 or the single repo changed between when user 1 and user 2 did their
install.
Of course, these behaviours *could* also be exactly what you want but certainly
some folks free at this non-determinism as a support nightmare.
Anyway, looking at features, they allow for things to be *included* or
*required*. Included things have exact version ranges while required things
have, generally, wider ranges. Traditionally the notion was that on install,
the things *included* by the feature were installed whereas the things
*required* merely had to be there. Early update manager didn't even help you
find/get/install the required things. That was goofy so we provided a means for
users to say "yeah, get the required stuff also". Now with p2 we do
this automatically without involving the user. So much for context...
It would be reasonable to allow ranges on product content but it would also
force the product designer to be very aware of the consequences pointed out at
the beginning of this message. I honestly don't know what people would do
naturally or what guidance we could/should give them (e.g., what's the
default?).
Back to your original topic, there is also the possibility of producing new
versions of your product that identify the new versions of the components.
Product production and distribution in p2 is very light weight and users would
see this as incoming new versions of the product (that they know about) vs
changes to random components (that they may well not even know exist). What
would you say as the user of some banking product if told that there was a new
version of EMF? "WFT?!"
Scenarios vary. If that does not work for you, you can insulate your product by
making it consist of one feature. In that feature, *require* everything that
you want to be updatable, include the stuff you want to be fixed (or put this
stuff directly in the product). The product will be bound to the one version of
your container feature and the container feature can use ranges. Beware the
problems outlined above with non-determinism. Note that you can also usethe
p2.inf file to do this. Andew Niefer did a couple blog posts on this a while
ago
http://aniefer.blogspot.com/2009/07/composing-and-updating-custom-eclipse.html
http://aniefer.blogspot.com/2009/07/composing-and-updating-custom-eclipse.html
Good luck
Jeff
On 2010-09-23, at 12:13 PM, Yousouf, Shenol wrote:
Hi all,
I noticed that product publishing always sets requirements for a fixed version of the contained
bundles/features, i.e. the defined range has its lower and upper boundaries equal
like this:
<required namespace="org.eclipse.equinox.p2.iu" name="TestBundle"range="[1.0.0.201009171510,1.0.0.201009171510]" />
while I need something like this:
<required namespace="org.eclipse.equinox.p2.iu" name="TestBundle"range="[1.0.0.201009171510,2.0.0)" />
or even this:
<required namespace="org.eclipse.equinox.p2.iu" name="TestBundle" range="1.0.0.201009171510" /> (which means “any version > 1.0.0.201009171510”)
The .product file format does not support a way to specify a range for its
components, only an attribute for a fixed version. The product publisher also
has no notion how to generate version ranges – it simply sets the range
boundaries equal to the component version (see method AbstractPublisherAction.createIURequirements() for reference). So far, I cannot find
a way how to workaround this issue and in my opinion it as a limitation of the
product definition concept.
Why is this so important ? The use case is like this:
I am developing a product consisting of several components which is getting
published on an update site on a regular basis. The components receive frequent
updates in the p2 repository and their versions are incremented which is
reflected in the requirements of the published product. However, once I install
this product, I cannot apply updates to the system any more. The updates are
refused because version ranges of the requirements for the installed and the
updated products do not intersect which seems to make them incompatible.
This wouldn’t be the case if it was possible to define open ranges in the
product file. For example, the installed product would require a specific
component in version range [1.0.0, 2.0.0) while its new version would require
it in the range [1.1.0, 2.0.0). This would allow the update to pass because
obviously range [1.1.0, 2.0.0) is compatible with (falls into) range [1.0.0,
2.0.0). The way they are generated now is [1.0.0, 1.0.0] for the old product
and [1.1.0,1.1.0] for the new one. Since these two ranges do not intersect, the
update is not possible.
In short, I have two issues and hope to receive some advice from you how to
address them:
· Is it possible to
define a product with extended version ranges of its components ?
· What makes product
versions compatible for update ? Why changed version requirements, which come
as a natural result of the publishing process, do not allow the product to get
updated to the higher version of its included components ?
Best regards,
Shenny
_______________________________________________
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
<repository1.zip><repository2.zip>_______________________________________________
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
_______________________________________________
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
_______________________________________________
p2-dev
mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
<test_repo1.zip><test_repo2.zip>_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
|
