Community
Participate
Working Groups
M5 Unzip eclipse-SDK-3.5M5-win32.zip to ..../eclipse Unzip mdt-ocl-SDK-1.3.0M5.zip to ..../eclipse/dropins/mdt-ocl-SDK-1.3.0M5 This is a problematic configuration since OCL depends on EMF which is missing. 3.5M5 provides no diagnosis of this problem. Start eclipse. No obvious problems. Nothing in Error Log. Help About plugin details shows org.eclipse.ocl.doc, but not org.eclipse.ocl. Help About Configuration Details has no (diagnostic) mention of org.eclipse.ocl. Help Installation Information Installed Software has no mention of org.eclipse.ocl Where are the nice error markers?
I would not consider this an enhancement request. It is a bug and a really annoying one.
This bug has caused us a lot of trouble and wasted time :-(
The reconciler is a best effort, as such nothing really ever fails to install. To diagnose why a bundle fails to install, just try to install it using the p2.director or the p2 ui and you will get the explanation.
Created attachment 127334 [details] Potential fix We could enable explanations when a debug flag is set to make diagnosis easier for clients. Computing the explanation can be quite expensive so we can't enable this by default.
(In reply to comment #4) > Created an attachment (id=127334) [details] > Potential fix > > We could enable explanations when a debug flag is set to make diagnosis easier > for clients. Computing the explanation can be quite expensive so we can't > enable this by default. This would be very cool, John.
Will there be any explanation when optional pieces aren't installed. If not we might have to figure out which IUs weren't installed and re-run the planner turning off the optional flags for those IUs.
This would not suffice because the bundles are installed optionally and as such the resolver would not report any error since not being able to install a bundle is authorized. Instead you would have to re-plan with strict inclusion and see if there is any error. Unless someone makes a contribution, I don't see this happening.
replying to #3: Since in the original report OCL was not installed and was not diagnosed as not installed, I fail to understand the comment nothing ever fails to install. Indeed as per #0, #1, #2 a definite bug.
Comment on attachment 127334 [details] Potential fix Pascal and Simon are right, my patch isn't sufficient
would explanations (proposed by John) be helpful in any other cases than dropins diagnosis? If so, could this patch be reconsidered?
*** Bug 291555 has been marked as a duplicate of this bug. ***
Just to make sure all you smart guys don't just see everything as a SAT problem ... I'm wondering if a simple heuristic would be helpful? For example, if you could keep a tally of the things you tried to install, via "dropins", and then if that differs from the things that were installed, you could print out an informational message to that effect to log. I know in my case of wasting 6 hours (bug 291555) I didn't have a clue that lots of things were not installed and kept looking elsewhere. I think I expected to see the message, because I see them frequently during PDE builds, when PDE does its resolution and can't find things. I realize this simple heuristic might always result in messages like "found 400 bundles to install but installed only 390 of them" and that might be completely normal, not indicating a real error at all. But then, at least, experienced developers (the likely users doing these "custom assemblies") would be better alerted to the fact that something was amiss, if and when they saw a message that wasn't like the ones they normally see, such as "found 400 bundles to install but installed only 250 of them". And, yes, I do know what "helpwanted" means :) Just wanted to document this possible improvement.
(In reply to comment #3) > To diagnose why a bundle fails to install, just try to install it using the > p2.director or the p2 ui and you will get the explanation. IMHO for your average user, the p2.director option is pretty much off the table. Using the p2 UI is not possible unless you have a repository. Right? In most cases the reason I'm "dropping in" is because I don't have one to point at. I think to leverage what is already built, why not add an option in the p2 UI to select an arbitrary "dropins" style directory of their choosing? Such an action would plan with strict inclusion and provide the error reporting that is needed. Perhaps such an enhancement deserves a different bug entry, but that's the solution I'd like to see.
I have done some initial work for 174515 - there is a simple checker which reports missing plug-ins. Maybe that code could be adopted.
I'm confused. My original compliant in bug 291555 (dupped to this one) was that nothing was written to log or console when constraints not satisfied. But, bug 174515 just referenced says that errors are written to log (and its seeking better 'end user' messages). I'd be happy with log messages (for my case). So, which is it? Written to log or not? If it used to, it is not any more. If it never has ... why do some people think it was? :)
(In reply to comment #15) > I'm confused. My original compliant in bug 291555 (dupped to this one) was that > nothing was written to log or console when constraints not satisfied. But, bug > 174515 just referenced says that errors are written to log (and its seeking > better 'end user' messages). I'd be happy with log messages (for my case). > > So, which is it? Written to log or not? If it used to, it is not any more. If > it never has ... why do some people think it was? :) Bug 174515 predates p2. The Equinox framework writes to the log when a bundle has been installed that cannot be resolved. p2 doesn't even install such bundles (the problem is now caught earlier in the bundle lifecycle), so these messages from the framework don't appear in the log when using p2.
*** Bug 296449 has been marked as a duplicate of this bug. ***
See patch on bug 296449.
Created attachment 153905 [details] Fix proposition for 3.6 API branch This patch does the following things: 1. Traces what has been discovered in dropins/ folder. 2. Traces the request 3. Traces the plan. Those pieces of information allow for diagnosing 2 major dropins/ shortcomings: A. Changes are not discovered. B. Features/plugins do not fit into installation. C. Dependencies are not met.
Created attachment 153906 [details] Better diagnosis for HEAD
Created attachment 153911 [details] Better diagnosis for 3.4 stream
Thanks for the patch. Released into p2 API clean-up branch. This will be merged with HEAD later this week. Tracing can be enabled by the following debug options: org.eclipse.equinox.p2.core/debug=true org.eclipse.equinox.p2.core/reconciler=true
