Bugzilla – Full Text Bug Listing
| Summary: | [p2] when self-hosting, p2 update ui won't come up | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Chris Aniszczyk <caniszczyk> |
| Component: | p2 | Assignee: | Pascal Rapicault <pascal> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | cgs.schaefer, curtis.windatt.public, darin.eclipse, eclipse, john.arthorne, larsivar, pascal, schoenbach, sflaniga, simon_kaegi, susan |
| Version: | 3.4 | ||
| Target Milestone: | 3.4 RC1 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Chris Aniszczyk
I am using AvailableIUGroup for the target provisioner (bug 204347). Now when self-hosting, trying to open the AvailableIUGroup takes forever (30sec+). I have a warning in my log "Could not locate the running profile instance". This has been true for some time, and I have just been working around it for UI development. If the intention is just to operate the update UI, and you don't mind the self hosted workbench p2 UI manipulating your *host* install, you can set ProvSDKUIActivator.ANY_PROFILE to true. This is how I do UI development. If the intention is to update your self hosted install, then I don't think it's configured properly for p2. The core guys will need to explain this one. Earlier this year we have decided to *not* have specific self hosting support for p2, even though we had started some code a while ago (see org.eclipse.equinox.p2.selfhosting plugin). So, much like with the old updated manager that would not work without a very specific layout, p2 UI is useless without the selfhosting support and therefore we do not open it. I get the "Could not locate the running profile instance" log entry as well (in M6), on every startup of a target workspace. I'm not trying to update, just launching a target workspace to carry on my normal plugin development work. It's troublesome to get a new log entry with every startup, because it makes it harder to see whether my own code is producing warnings. I can't tell from the comments whether this is something we expect to have fixed by release? Or maybe there's something awry with my target workspace? btw Walter, the error log view has the ability to group your messages by plug-in... that can help narrow down messages ;) Sure. But what I want to know is not only whether my plug-in is logging anything, but whether my changes are provoking any other plug-ins to log something. There's no way for me to know, a priori, whether a new warning (like this one) is my plug-in's fault. >I can't tell from the
>comments whether this is something we expect to have fixed by release? Or
maybe there's something awry with my target workspace?
The message is telling you that the target workspace is not configured properly from a p2 point of view. Last I heard, the PDE guys are going to investigate if there's something on their end that can be done, but there's no commitment yet that this will be addressed for 3.4.
If your main issue is that you don't want the noise in the log, we could look at having some additional settings on ProvSDKUIActivator so that the error won't be logged. That message is important for us when debugging p2 installs, but perhaps not for the rest of the community.
It makes sense to me that p2 does not work in a self-hosted configuration. (Similarly, you can't change workspaces when self-hosting.) So the issue for me is just the noise in the log. This is related to a general problem we have, discussed in bug 174515: we have no adequate UI for the case where "plug-in X is unable to function, but that is for known reasons related to the execution context and is probably innocuous unless you were trying to use it." Eclipse is modular, and it is normal for not all bundles to be loadable or runnable in any given context. I think it is bad UI practice for bundles to complain if they can't be loaded, UNLESS there was an explicit user attempt to get at their functionality. That is hard to solve in general, for reasons discussed in bug 174515. But in this particular case, if we can disable the log entry when running self-hosted, that would make me very happy. This may get addressed by the support to spoof up profiles. I had to cancel an update and now, I am also getting the error message mentioned by the bug reporter. Is there any workaround to re-enable the update functionality again? This has been fixed by the work done on shared install in RC1. The UI comes up populated with a profile representing the IDE and not what you are running. Obviously this is not ideal but we can't do more at the moment since doing more would mean resurrecting the p2 selfhosting bundle and get it integrated with PDE. Still closing as fixed. I and my colleague are running the JEE IDE Eclipse download, RC2, and after installing Subclipse from their 1.4.x update site, both of us get the above cited message when trying to open software updates. So, doesn't really look like fixed. I'm sure you don't want a full release cycle without a possibility to update the Eclipse IDE's. (In reply to comment #12) > [...] both of us get the above > cited message when trying to open software updates. Are you describing a self-hosting case (that is, Eclipse debugging another instance of Eclipse, as in a plugin development situation)? If not, then please enter a separate bug report, since this bug report applies to the self-hosting scenario specifically. If so, then please also reopen this bug (don't just add a comment and leave it in its resolved/fixed state); and add sufficient details to let someone investigate and debug. For instance, exactly what steps did you take to make the problem happen, what troubleshooting have you performed, and are there any entries in your error log file (in either the host or target instance of Eclipse). Eclipse wouldn't be shipping with p2, if it hadn't been tested and proven to work. Your comment "I'm sure you don't want a full release cycle without a possibility to update the Eclipse IDE's" is specious. But obviously there are (and always will be) scenarios that are untested. For a bug report to be useful, it needs to have enough information to determine what is special about the bug scenario. Thanks! (In reply to comment #13) > (In reply to comment #12) > > [...] both of us get the above > > cited message when trying to open software updates. > > Are you describing a self-hosting case (that is, Eclipse debugging another > instance of Eclipse, as in a plugin development situation)? No, this is actually just an Eclipse-using case. > If not, then please enter a separate bug report, since this bug report applies > to the self-hosting scenario specifically. Ok, 238211 posted. > If so, then please also reopen this bug (don't just add a comment and leave it > in its resolved/fixed state); and add sufficient details to let someone > investigate and debug. For instance, exactly what steps did you take to make > the problem happen, what troubleshooting have you performed, and are there any > entries in your error log file (in either the host or target instance of > Eclipse). > > Eclipse wouldn't be shipping with p2, if it hadn't been tested and proven to > work. Your comment "I'm sure you don't want a full release cycle without a > possibility to update the Eclipse IDE's" is specious. Sorry :) we like to implement a silent non gui software update to our RCP. does this mean we can not debug and test the code, e.g. the P2Util examples ? (In reply to comment #15) > we like to implement a silent non gui software update to our RCP. > does this mean we can not debug and test the code, e.g. the P2Util examples ? > See http://wiki.eclipse.org/Equinox_p2_Getting_Started_for_Developers#Self_hosting |