|
Hi guys,
Update operation is already submitted as a patch. It's
denoted with "-updateIU" and could be used in simillar manner as
"-installIU" and "-uninstallIU". You can see the
bug below for more information.
Any comments and feedback are highly appreciated.
Kind regads,
Katya
Of course, adding an update operation would be relatively straight
forward. Seems like that would be a welcomed contribution to the director
app. As Richard mentioned, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=279659.
Jeff
On 2010-09-27, at 11:27 AM, Andrew Niefer wrote:
As Jeff pointed out, you need to "update" the product. The director
application does not have any arguments for updating IUs. The closest
equivalent using the director is uninstall followed by install.
See http://stackoverflow.com/questions/2380228/run-plugin-updates-outwith-eclipse-ui
and https://bugs.eclipse.org/bugs/show_bug.cgi?id=279659
<graycol.gif>Samuel Wu---09/27/2010 11:19:03 AM---Hi Shenny, I ran into the
same problem as yours. I posted question on how to update an
<ecblank.gif>
From: |
<ecblank.gif>
Samuel
Wu/Toronto/IBM@IBMCA |
<ecblank.gif>
To: |
<ecblank.gif>
P2
developer discussions <p2-dev@xxxxxxxxxxx> |
<ecblank.gif>
Date: |
<ecblank.gif>
09/27/2010 11:19 AM |
<ecblank.gif>
Subject: |
<ecblank.gif>
Re:
[p2-dev] Product publishing and product update |
<ecblank.gif>
Sent by: |
<ecblank.gif>
p2-dev-bounces@xxxxxxxxxxx |
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
<graycol.gif>"Yousouf, Shenol" ---09/27/2010 10:08:55 AM---Hi, First, thanks for the
dedicated support and the quick responses ! :)
<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/27/2010 10:08
AM |
<ecblank.gif>
Subject: |
<ecblank.gif>
Re: [p2-dev] Product
publishing and product update |
<ecblank.gif>
Sent by: |
<ecblank.gif>
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. Ill check for further
information on the net but Id 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
cant 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 dont 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 wont 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 Ill 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 dont 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
wouldnt 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
|
