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
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Andrew Niefer/Ottawa/i...@ibmca
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|P2 developer discussions <[email protected]>
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|09/27/2010 11:26 AM
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Re: [p2-dev] Product publishing and product update
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|[email protected]
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
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
Inactive hide details for Samuel Wu---09/27/2010 11:19:03 AM---Hi Shenny, I
ran into the same problem as yours. I posted questiSamuel 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
From: Samuel Wu/Toronto/i...@ibmca
To: P2 developer discussions <[email protected]>
Date: 09/27/2010 11:19 AM
Subject: Re: [p2-dev] Product publishing and product update
Sent by: [email protected]
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
Inactive hide details for "Yousouf, Shenol" ---09/27/2010 10:08:55 AM---Hi,
First, thanks for the dedicated support and the qui"Yousouf, Shenol"
---09/27/2010 10:08:55 AM---Hi, First, thanks for the dedicated support and
the quick responses ! :)
From: "Yousouf, Shenol" <[email protected]>
To: P2 developer discussions <[email protected]>
Date: 09/27/2010 10:08 AM
Subject: Re: [p2-dev] Product publishing and product update
Sent by: [email protected]
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: [email protected] [mailto:[email protected].] 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: [email protected] [mailto:[email protected].] 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: [email protected] [mailto:[email protected].] 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
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
<repository1.zip><repository2.zip>_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
