Bugzilla – Full Text Bug Listing
| Summary: | Provide a way to update all the nested features | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Samuel Wu <samuelwu> | ||||
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | djshepard, irbull, john.arthorne, leberre, mauromol, mrrussell, pascal, pwebster, rdayal | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
|
Description
Samuel Wu
Actually I think that if you require the feature instead of including it, then you can specify a version range and you should be able to update the features independently of each other. Pascal, does that sound right? Hi DJ, When a build is run on a feature, it only build its included features, not its dependency features. Go back the original scenario, we actually want both com.abc.test2 3.6.1 and com.abc.test1 3.6.1 to be deployed within a single task. If com.abc.test2 doesn't include com.abc.test1, it won't build com.abc.test1 when building com.abc.test2. When it comes to install, it will not install test1 3.6.1 if test1 3.6.0 has already been installed and test2 3.6.1 requires test1 for 3.6.0 above. If test2 3.6.1 requires test1 for 3.6.1 above, the user still have to choose to update test1 when update test2. In a short word, we've tried depend/require and it doesn't seem to meet our requirement unless I missed something. In http://aniefer.blogspot.com/2009/07/composing-and-updating-custom-eclipse.html Andrew talks about setting the product requirements to be ranges. Can this trick be done with a feature p2.inf? PW Here is the detailed error list for this scenario. In this case B includes A. I installed A v1, then B v1, then tried to install B v2. I'm guessing this has to do with the fact that we have both A and B marked as roots. ("A" shows up twice in the About -> Installation Details... once on its own and once as a sub-feature of "B").
Your original request has been modified.
"B" is already installed, so an update will be performed instead.
Cannot complete the install because of a conflicting dependency.
Software being installed: B 2.0.0 (b.feature.group 2.0.0)
Software currently installed: A 1.0.0 (a.feature.group 1.0.0)
Only one of the following can be installed at once:
A 1.0.0 (a.feature.jar 1.0.0)
A 2.0.0 (a.feature.jar 2.0.0)
Cannot satisfy dependency:
From: A 1.0.0 (a.feature.group 1.0.0)
To: a.feature.jar [1.0.0]
Cannot satisfy dependency:
From: A 2.0.0 (a.feature.group 2.0.0)
To: a.feature.jar [2.0.0]
Cannot satisfy dependency:
From: B 2.0.0 (b.feature.group 2.0.0)
To: a.feature.group [2.0.0]
Adding Daniel to the CC list in case he or Pascal have any insight on this.
Created attachment 200474 [details]
update site
Update site containing the data required to replicate the problem.
It is correct for the resolver to reject that particular plan. The trick is there is a fairly obvious (from end user perspective) way to alter the plan: upgrade both roots together. I'm not sure if there is some information from the resolver explanation that could help make this recommendation to the user. Thanks DJ for the detailed test case. Yes, the issue here is not the resolver itself, but the way we manage roots. By default, we forbid to change a root, unless it is detected as "upgradable", in which case it is specifically handled. Because we know that one IU (A1) in the explanation is a root IU, we may suggest the user to update that IU too. Pascal, is there something we could do before calling the resolver to prevent such situation? *** Bug 351905 has been marked as a duplicate of this bug. *** Since bug 351905 has been marked a duplicate of this bug, could someone suggest a work-around? I too am having difficulty getting the WindowBuilder plug-in set from the Google Code site to install. This is a clean install of 64 bit Indigo on Windows 7x64, with just this one set of GUI builder plug-ins. I suspect I'm going back to the land of Helios, where common stuff like this works. However I am stubborn, so I'm really trying to make this work... I've tried hacking at the files in the eclipse folder to remove offending files and perhaps I've missed something, but the installer for the new packages seems to get stuck in the same place every time, delivering the same error: An error occurred while collecting items to be installed session context was:(profile=SDKProfile, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=). No repository found containing: osgi.bundle,javax.xml,1.3.4.v201005080400 No repository found containing: osgi.bundle,org.apache.lucene.highlighter,2.9.1.v20100421-0704 No repository found containing: osgi.bundle,org.apache.lucene.memory,2.9.1.v20100421-0704 No repository found containing: osgi.bundle,org.apache.lucene.misc,2.9.1.v20100421-0704 No repository found containing: osgi.bundle,org.apache.lucene.queries,2.9.1.v20100421-0704 No repository found containing: osgi.bundle,org.apache.lucene.snowball,2.9.1.v20100421-0704 No repository found containing: osgi.bundle,org.apache.lucene.spellchecker,2.9.1.v20100421-0704 No repository found containing: osgi.bundle,org.apache.xerces,2.9.0.v201101211617 No repository found containing: osgi.bundle,org.apache.xml.resolver,1.2.0.v201005080400 No repository found containing: osgi.bundle,org.apache.xml.serializer,2.7.1.v201005080400 No repository found containing: osgi.bundle,org.eclipse.emf.common,2.7.0.v20110605-0747 No repository found containing: osgi.bundle,org.eclipse.emf.ecore,2.7.0.v20110605-0747 No repository found containing: osgi.bundle,org.eclipse.emf.ecore.change,2.7.0.v20110408-2116 No repository found containing: osgi.bundle,org.eclipse.emf.ecore.xmi,2.7.0.v20110520-1406 No repository found containing: osgi.bundle,org.eclipse.emf.edit,2.7.0.v20110606-0949 No repository found containing: osgi.bundle,org.eclipse.jem.util,2.1.100.v201103021400 No repository found containing: osgi.bundle,org.eclipse.wst.common.core,1.2.0.v200908252030 No repository found containing: osgi.bundle,org.eclipse.wst.common.emf,1.2.100.v201101101900 No repository found containing: osgi.bundle,org.eclipse.wst.common.emfworkbench.integration,1.2.100.v201011172300 No repository found containing: osgi.bundle,org.eclipse.wst.common.environment,1.0.400.v200912181832 No repository found containing: osgi.bundle,org.eclipse.wst.common.frameworks,1.2.100.v201105122000 No repository found containing: osgi.bundle,org.eclipse.wst.common.project.facet.core,1.4.200.v201103170332 No repository found containing: osgi.bundle,org.eclipse.wst.common.ui,1.1.500.v200911190730 No repository found containing: osgi.bundle,org.eclipse.wst.common.uriresolver,1.1.401.v201004280700 No repository found containing: osgi.bundle,org.eclipse.wst.sse.core,1.1.600.v201105162116 No repository found containing: osgi.bundle,org.eclipse.wst.sse.ui,1.3.0.v201105101529 No repository found containing: osgi.bundle,org.eclipse.wst.validation,1.2.300.v201104190230 No repository found containing: osgi.bundle,org.eclipse.wst.xml.core,1.1.600.v201104251227 No repository found containing: osgi.bundle,org.eclipse.wst.xml.ui,1.1.200.v201105111835 Thanks in advance for any (helpful) suggestions. (In reply to comment #9) Your scenario is: a) feature A depends on feature B, and b) an older version of feature B is already installed, and c) we attempt to install feature A, then d) the install will fail The workaround in this case is to manually upgrade Feature B before installing Feature A. This enhancement is for p2 to automatically detect this and suggest performing the upgrade for you automatically. (In reply to comment #10) > (In reply to comment #9) > > Your scenario is: > > a) feature A depends on feature B, and > b) an older version of feature B is already installed, and > c) we attempt to install feature A, then > d) the install will fail > > The workaround in this case is to manually upgrade Feature B before installing > Feature A. This enhancement is for p2 to automatically detect this and suggest > performing the upgrade for you automatically. As an eclipse user, not an eclipse developer, my goal was simply to move past this problem and onto code that I actually should be working on. That said, here's what worked for me: delete the pre-rolled eclipse 'SDK' version download the pre-rolled eclipse 'java developer' version install the plug-in from this update site: http://dl.google.com/eclipse/inst/d2wbpro/latest/3.7 Problem solved. As there is no obvious uninstall feature once something is placed in the eclipse directory, the only way I know to make sure dependencies aren't installed 'in the wrong order' is to use packages where this apparently doesn't happen. (In reply to comment #10) > (In reply to comment #9) > > Your scenario is: > > a) feature A depends on feature B, and > b) an older version of feature B is already installed, and > c) we attempt to install feature A, then > d) the install will fail > > The workaround in this case is to manually upgrade Feature B before installing > Feature A. This enhancement is for p2 to automatically detect this and suggest > performing the upgrade for you automatically. I agree that this is the way to go, since this is the way we manage updates of installed components. We may detect this during the slicing stage. Do you think that we should really ask the users if he wants to update or should we do it silently? The end user probably do not know anything about that dependency. (In reply to comment #12) > Do you think that we should really ask the users if he wants to update or > should we do it silently? The end user probably do not know anything about that > dependency. This is what we do for similar cases: We modify the plan, and in the preview page we show all the changes (both the changes they requested, and the extra ones what we added). We add a message at the bottom such as, "The install plan has been modified. Installing X requires upgrading Y." So, there is not really another question for the user, but at least they are shown what is going to happen. It makes sense to do it for installed software (roots). But here we are talking about dependencies. The end user might not be aware that such dependency is installed in the system, right? (In reply to comment #14) > It makes sense to do it for installed software (roots). But here we are talking > about dependencies. The end user might not be aware that such dependency is > installed in the system, right? Ah, for non-root dependencies I believe we just upgrade them automatically without asking. I thought this was already what we do (only when the upgrade is compatible with the installed roots of course). I took a quick look at the code in the projector. - Nested features can be updated - The resolver cannot update a root So, we only the scenario summarized by DJ cause the problem described by this bug. I see two solutions to fix the current behavior: - try to behave similarly to what is done now when an updated version of a root is detected: the request is modified before being sent to the resolver - try to handle the problem into the resolver: I think it is not necessarily a good idea because we will have to ask the user to confirm he wishes to update that root. An in between solution would be to make the resolver provide a specific explanation when a root conflicts a new request, and that an updated package exists. The way, the flow would be (same example as DJ): A1 and B1 installed as root packages request to install B2 request fail with proposal to update A request to install B2 and update to A2 request succeed I am afraid that detecting if a root need to be updated it a problem itself, so it is better to let the resolver look after that. The third solution would have an impact on many parts of p2, to allow that new piece of information to arrive to the end user. What is your feeling about those proposals? DJ, Ian and I had an impromptu meeting on this topic yesterday aft. Here are the conclusions and action plan: Basically, there is nothing magic the resolver can do to without having the user involved. For example would the user prefer to uninstall what is blocking or stop the installation, etc. Should he downgrade what is installed, etc. To address this we have decided on the following: - We will improve the message presented to the user by focusing those on the roots installed and the things being installed. For example even if there is a conflict between two singletons deep down into two dep tree, we want the user to know that it is root A is colliding with root B. This may require some improvements to the explanations returned by the resolver. A tree of dependency would be ideal to facilitate the analysis. - We will provide an improved error resolution dialog that will let the user decide what he wants to do for each root (pin it to this version, allow for higher version, remove it). We may even provide a "I feel lucky" button :) and allow the user to retry the installation. At this point we will likely not base that on API, and will look into API once we have something functionally complete. Just to refresh my memory, the resolver bails after finding the first failure, right? I'm looking at a test case where we have: - P1, S1, T1 all installed - S1 includes P1 - T1 includes P1 - I want to update P1 In the error message I'm only seeing the reference to S1's dependency on P. I think that's expected but want to confirm. Correct. The resolver returns the first conflict. We may study how to retrieve all root conflicts if needed. Or we could even call the resolver several times to detect all the problems. This is related to some of the "relaxed update" work that has been done in Bug 261928. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag. |