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/i...@ibmca > <ecblank.gif> > To: <ecblank.gif> > P2 developer discussions <[email protected]> > <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> > [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 > > > <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" <[email protected]> > <ecblank.gif> > To: <ecblank.gif> > P2 developer discussions <[email protected]> > <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> > [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
_______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
