Hello Samuel,
I am interested in your solution. Let me see if I have understood
it right. Instead of building a product, you are using a feature which includes
the other features you need ? Is there a straightforward way to define a
feature out of other features ? I thought that only plugins can be defined
there. The only way to instrument such a “composite” feature I can think of is
via p2.inf.
Best regards,
Shenny
From:
p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Samuel
Wu
Sent: Monday, September 27, 2010 6:16 PM
To: P2 developer discussions
Subject: 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
"Yousouf, Shenol" ---09/27/2010 10:08:55
AM---Hi, First, thanks for the dedicated support and the quick responses ! :)
|
From:
|
"Yousouf, Shenol"
<s.yousouf@xxxxxxx>
|
|
To:
|
P2 developer discussions
<p2-dev@xxxxxxxxxxx>
|
|
Date:
|
09/27/2010 10:08 AM
|
|
Subject:
|
Re: [p2-dev] Product publishing and product
update
|
|
Sent by:
|
p2-dev-bounces@xxxxxxxxxxx
|
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
