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
_______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
