https://bugs.eclipse.org/bugs/show_bug.cgi?id=279659
There is no update, only install and uninstall … which when
combined can substitute for update.
From:
p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Yousouf,
Shenol
Sent: Monday, September 27, 2010 10:05 AM
To: P2 developer discussions
Subject: 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.
On 2010-09-27, at 8:28 AM, Yousouf, Shenol wrote:
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 !
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.
On 2010-09-24, at 11:17 AM, Yousouf, Shenol wrote:
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>'>
<provided
namespace='org.eclipse.equinox.p2.iu' name='tooling<product name>.configuration'
version='<product version>'/>
<touchpoint id='null'
version='0.0.0'/>
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) ?
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
On 2010-09-23, at 12:13 PM, Yousouf, Shenol wrote:
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)"
/>
<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 ?
<repository1.zip><repository2.zip>_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
|