Community
Participate
Working Groups
I had to dabble a little bit in explanations in order to fix bug 310206. Some things to make note of while they are on my mind. (I thought we had a bug for this already but couldn't find it.) - currently PlannerStatus, RequestStatus, etc. are internal. They are marked provisional so I don't feel *too* bad using them. However they leak other non-provisional internals (such as Explanation) in their API so clearly this needs cleanup. - I need to be able to know about Explanation in order to detect a specific case like "Missing Requirement". There are the short error codes that describe these cases, but they are located inside Explanation. For example, see InstallOperation.missingRequirement(IProvisioningPlan failedPlan). - it's not clear where to look when deciphering a RequestStatus. Right now the overall status is much clearer about what is wrong (missing requirement) than the individual IU-based errors. For example, if A is missing a requirement, the overall status tells me this, but the status for A is simply "ERROR." That will help me to do things like mark a red "X" on A in the UI, but I don't see a way to tie that X to the specific "MissingRequirement". Ideally, I'd like to be able to get the status for an IU, as we do today. But if that status is an error, I'd like to be able to say something like... RequestStatus.getExplanations(IInstallableUnit iu) so that I'd know exactly why IU was in error. It feels like we might be missing info when we compact explanations into a status, or that we might want each individual IU to carry a PlannerStatus so that explanations can be accessed per IU.
I think you are referring to Bug 261928 :) We have now a much better explanation system than in 3.5. So we may enable the possibility to compute on request a specific explanation for a given IU. Regarding the case of missing requirements, I guess that we need at some point to define some constants that defines the kind of possible problems. Then we could allow in the API to gather the problematic IUs per type of problem.
(In reply to comment #1) > I think you are referring to Bug 261928 :) That bug is about what we could do in the UI. This bug is what the UI needs from API in order to do it... I figure we'll evolve these two bugs together...
What's the latest progress of this improvement in 3.7? Personally I think some error information still are hard to be understood by users. For example, Eclipse 3.6 could report below unsatisfied dependency, "Eclipse Monkey (Incubation) (1.0.0.200706060977) requires plug-in "org.mozilla.rhino". It tells user the feature "Eclipse Monkey" that user want to install requires plug-in "org.mozilla.rhino". But I think most of user don't know what the plug-in "org.mozilla.rhino" is, where it comes from and how to install it firstly. It would be much more graceful if the error message looks like below, "Eclipse Monkey (Incubation) (1.0.0.200706060977) requires install "Mozilla Rhino" firstly that can be installed from http://www.mozilla.org/rhino/p2. The repository address could be a hyperlink, open a wizard to add the repository then install Rhino firstly after clicking the link. I know it's impossible to get the name of group feature that contains the plug-in "org.mozilla.rhino" in current metadata repository. I'm curious whether it's possible that referring the third-party repository when publishing the p2 repository. In the "Eclipse Monkey" example we could record the name of third-party plug-in, the plug-in namespace, id and where to install them into the metadata repository of "Eclipse Monkey". It's some additional messages not to impact the performance of resolving the dependencies. Just use them to report the graceful error message. What do you think about? If it's acceptable, I'm interested in contributing this capability in 3.7. :)
(In reply to comment #3) > What's the latest progress of this improvement in 3.7? > > Personally I think some error information still are hard to be understood by > users. > > For example, > > Eclipse 3.6 could report below unsatisfied dependency, > > "Eclipse Monkey (Incubation) (1.0.0.200706060977) requires plug-in > "org.mozilla.rhino". > > It tells user the feature "Eclipse Monkey" that user want to install requires > plug-in "org.mozilla.rhino". But I think most of user don't know what the > plug-in "org.mozilla.rhino" is, where it comes from and how to install it > firstly. > > It would be much more graceful if the error message looks like below, > > "Eclipse Monkey (Incubation) (1.0.0.200706060977) requires install "Mozilla > Rhino" firstly that can be installed from http://www.mozilla.org/rhino/p2. > > The repository address could be a hyperlink, open a wizard to add the > repository then install Rhino firstly after clicking the link. > > I know it's impossible to get the name of group feature that contains the > plug-in "org.mozilla.rhino" in current metadata repository. I'm curious whether > it's possible that referring the third-party repository when publishing the p2 > repository. > > In the "Eclipse Monkey" example we could record the name of third-party > plug-in, the plug-in namespace, id and where to install them into the metadata > repository of "Eclipse Monkey". > > It's some additional messages not to impact the performance of resolving the > dependencies. Just use them to report the graceful error message. > > What do you think about? > > If it's acceptable, I'm interested in contributing this capability in 3.7. :) +1 for the direction this is going. I think the "dependency failed" case is an area we need to improve, it currently leaves the user clueless on how to resolve the situation. Some additional metadata, only meant for error recovery, could be the resolution to this problem. This would move the problem of finding the missing plug-in from (user) install time to (provider) generation time, which is always great to do. What do you guys think, is this an area Wind River could help, or is there an alternate approach we could help with?
(In reply to comment #3) > What's the latest progress of this improvement in 3.7? So far, nothing got done on this front. > Personally I think some error information still are hard to be understood by users. I agree and this is why we have bug #261928. This bug is about providing a more structured API around the root cause so that the UI can be improved. > [...] > "Eclipse Monkey (Incubation) (1.0.0.200706060977) requires install "Mozilla > Rhino" firstly that can be installed from http://www.mozilla.org/rhino/p2. This would definitely be an interesting improvements, however this raises the question of how can the repository be found? > > The repository address could be a hyperlink, open a wizard to add the > repository then install Rhino firstly after clicking the link. > > I know it's impossible to get the name of group feature that contains the > plug-in "org.mozilla.rhino" in current metadata repository. I'm curious whether > it's possible that referring the third-party repository when publishing the p2 > repository. It is possible to refer to additional repos from a repo. However, if a repo is being referred to from the one I'm installing from but is not enabled, I would say that this is a metadata bug from the producer of the site. In the sense that the producer knows which artifacts he includes in his repo and which one he expects to see coming from another place. > In the "Eclipse Monkey" example we could record the name of third-party > plug-in, the plug-in namespace, id and where to install them into the metadata > repository of "Eclipse Monkey". I'm not following. > If it's acceptable, I'm interested in contributing this capability in 3.7. :) A problem which I think would be more valuable to solve is one of general presentation (using some sort of tree like widget), especially in terms of conflicts because it is not necessarily clear to ppl what they need to uninstall or update, and even simply figure out the roots that are involved.
(In reply to comment #5) > > [...] > > "Eclipse Monkey (Incubation) (1.0.0.200706060977) requires install "Mozilla > > Rhino" firstly that can be installed from http://www.mozilla.org/rhino/p2. > This would definitely be an interesting improvements, however this raises > the question of how can the repository be found? That's IMHO a big issue. In many cases, if we can end up detecting that there are missing dependencies and automatically contact all update sites to see if the missing requirement can be found could be really nice. By default, the "contact all update sites" box is ticked which makes any plugin installation takes a while because all those repository meta data have to be collected. Have an automated process that contact all update sites in case of missing dependencies would allow us to not tick that box by default, thus providing a faster installation for specific plugins (subclipse, findbugs, etc). In that case, it would require the planner to be incremental, i.e. to be able to resolve the current request with a growing number of repository. We could also try to start resolving while downloading the remaining metadata. From the solver point of view, this is possible (so called "incremental sat"). > > If it's acceptable, I'm interested in contributing this capability in 3.7. :) > A problem which I think would be more valuable to solve is one of general > presentation (using some sort of tree like widget), especially in terms of > conflicts because it is not necessarily clear to ppl what they need to > uninstall or update, and even simply figure out the roots that are involved. I think that we need to take into consideration to potential actors - basic user does not require all the details of the problem. Only the root causes and some directions to sort this out are needed. - plugins and apps producers (aka p2 power users): in that case, they are generating metadata so they need to relate the current problem to their own metadata.
(In reply to comment #5) > (In reply to comment #3) > > I know it's impossible to get the name of group feature that contains the > > plug-in "org.mozilla.rhino" in current metadata repository. I'm curious > whether > > it's possible that referring the third-party repository when publishing the p2 > > repository. > It is possible to refer to additional repos from a repo. However, if a repo > is being referred to from the one I'm installing from but is not enabled, I > would say that this is a metadata bug from the producer of the site. In the > sense that the producer knows which artifacts he includes in his repo and which > one he expects to see coming from another place. I don't recognize the feature that one repo refers to others. I'll try it to see what will happen. :) > > In the "Eclipse Monkey" example we could record the name of third-party > > plug-in, the plug-in namespace, id and where to install them into the metadata > > repository of "Eclipse Monkey". > I'm not following. > I know p2 is vastly used as provisioning/backend installing technique for the RCP, which are always distributed via DVD or CD as standalone applications. The prerequisite of some components of those standalone products is installing another product firstly. It's no way to refer another repo, because it's not published on the Internet. So creating some additional data to provide the full description of the required products could be an optional solution to make the explanation more helpful. Those data is not used for resolving the dependency, because they don't contain the actual artifact information. They're the additional information to help explain the failure of resolving the dependency.
(In reply to comment #6) > I think that we need to take into consideration to potential actors > - basic user does not require all the details of the problem. Only the root > causes and some directions to sort this out are needed. Yes, basic user doesn't care the details of problem. They definitely like some directions to help resolve the problem. > - plugins and apps producers (aka p2 power users): in that case, they are > generating metadata so they need to relate the current problem to their own > metadata. I think so. The app producers should provide enough information to help explain why installation fails. App producers know which prerequisites are required by their apps, so they are easy to provide those information when publishing their repositories.
In 3.6, the semantics of the "contact all update sites", when it is off, got slightly modified to cater for the case where a repository refers to additional ones (metadata or artifact ones). In this case, now the repo and the referenced one are now being checked. This was a first step toward being able to ship with this option off by default. However I don't think we never did the automatic re-enablement of the check box because we were missing some API to introspect the explanations. So after all that, who is going to do the work :)
> So creating some additional data to provide the full description of the > required products could be an optional solution to make the explanation more > helpful. Those data is not used for resolving the dependency, because they > don't contain the actual artifact information. They're the additional > information to help explain the failure of resolving the dependency. In 3.6 we added IRequirement#getDescription to start dealing this use case but I don't think it ever got used in the planner.
Move all 3.8 bugs to Juno.
