Bugzilla – Full Text Bug Listing
| Summary: | version 0.0.0 for .target resolves to '0 plug-ins available' when newer plug-ins are available in other software sites | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Ralf Ebert <ralf> | ||||||||||||
| Component: | UI | Assignee: | Curtis Windatt <curtis.windatt.public> | ||||||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||||||
| Severity: | normal | ||||||||||||||
| Priority: | P3 | CC: | aniefer, ankur_sharma, curtis.windatt.public, darin.eclipse, Mike_Wilson | ||||||||||||
| Version: | 3.6.1 | Flags: | Mike_Wilson:
pmc_approved+
darin.eclipse: review+ |
||||||||||||
| Target Milestone: | 3.6.1 | ||||||||||||||
| Hardware: | All | ||||||||||||||
| OS: | All | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Bug Depends on: | |||||||||||||||
| Bug Blocks: | 324344 | ||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Ralf Ebert
Created attachment 178076 [details]
rcp.target
Created attachment 178078 [details]
rcp_0.0.0_fail.target
This seems to be caused by the version number '0.0.0' which I entered manually in the .target to express 'the newest version available in this software site'. Eclipse seems to interpret this as 'the newest version available in any known software site'. If I explicitly specify '3.6.0.I20100608-0911' it works again and resolves to 61 plugins. But then when I-builds are cleared from the software site, the .target will break. IMHO '0.0.0' in a .target should resolve to the newest version in this one repository location only. It also only happens with the slicer: 0.0.0 with slicer = 0 plug-ins 3.6.0.I20100608-0911 with slicer = 60 plug-ins 0.0.0 with planner = 61 plug-ins 3.6.0.I20100608-0911 with planner = 61 plug-ins The problem is that when specifying 0.0.0 (not a supported use case), the slicer returns a warning status. There are three different behaviours in 3.6.0, 3.6.1 and 3.7. 3.6.0 - Status is ignored completely, resolve continues, returns results 3.6.1 - Status is found, an empty status was returned (changed in bug 313409) 3.7 - Status is found and reported (changed in bug 323910) Proposed fix for 3.7: If an error status is returned, report it If a warning status is returned and result is empty, report it If a warning status is returned and result is not empty, continue Proposed fix for 3.6.1: Ignore the status completely so the resolve continues. Keep the null checking aspect of bug 313409, but remove the status checking. Reminder that using 0.0.0 is not something we support (I wasn't even aware you could do that). In 3.7 (bug 276326) we added code to lookup info from the saved profile over looking at the remote repos. I suspect that using 0.0.0 as the version will fail to work more than once, as we will always assume the the information in the profile is up to date. If possible please test it out using 3.7 M2 and file another bug. Created attachment 178086 [details]
rcp_3.6.0_fail.target
Sorry for the confusion, I must have misread the output while trying different variants. It doesn't seem to be related to the 0.0.0 version but only to using the slicer. Attached 'rcp_3.6.0_fail.target' also fails in a clean workspace despite listing the explicit version number '3.6.0.I20100608-0911'.
Created attachment 178087 [details]
3.6.1 Fix
Couldn't the resolve continue (so it works as in 3.6.0) AND the warning be reported as per bug 323910 (so that I'm at least aware that I'm walking on thin ice here)? 0.0.0 appeared to work for me in 3.6.0, but I might just have had luck, if there is only one version available, 0.0.0 is not that complicated to handle :) Is there a bug report that says 'support 0.0.0 for .targets'? Such a feature is really helpful when working with software sites that are updated frequently (like nightly builds) - I don't want to manage these manually but just say 'use the latest version'. Created attachment 178092 [details]
3.6.1 Fix
McQ, can we please get approval to fix this in 3.6.1? The 3.6.1 fix restores the 3.6.0 behaviour, while still checking for a null result (bug 313409). +1 for 3.6.1. This is the simplest fix for 3.6.1 - check for a null slice (new in 3.6.1) and continue to disregard status (the same as 3.6.0). For 3.7, we can improve this - a new bug should be opened to track the work. I tried the patch on org.eclipse.pde.core R3_6_maintenance and that restored the old 3.6.0 behavior. Still it would be good to know what's causing the problem that's suppressed by this, if only in the Error Log. (In reply to comment #9) > Couldn't the resolve continue (so it works as in 3.6.0) AND the warning be > reported as per bug 323910 (so that I'm at least aware that I'm walking on thin > ice here)? Not currently. Right now the resolve either returns a set of bundles or throws an exception. > 0.0.0 appeared to work for me in 3.6.0, but I might just have had luck, if > there is only one version available, 0.0.0 is not that complicated to handle :) > > Is there a bug report that says 'support 0.0.0 for .targets'? Such a feature is > really helpful when working with software sites that are updated frequently > (like nightly builds) - I don't want to manage these manually but just say 'use > the latest version'. There is no bug to support 0.0.0 (I didn't even know this was possible in the p2 world). There is a request to have target's updatable (bug 182373). How about adding this to the fix:
if (!slicer.getStatus().isOK()) {
// Ignoring errors is 3.6.0 behavior that should not be changed in 3.6.x
// Therefore errors are only logged
PDECore.log(slicer.getStatus());
}
In my example, this results in a very helpful error message I'd really like to know about:
-- Problems resolving provisioning plan.
---- Unable to satisfy dependency from org.eclipse.rcp.configuration.feature.group 1.0.0.I20100608-0911 to org.eclipse.equinox.launcher.motif.solaris.sparc [1.1.0.v20100503].
...
The log is not an appropriate place to inform the user that something is wrong in the target definition they are editing. The user has no reason to think to look there and having odd dependency problems in the log will make users think there is something wrong with their installation. The 3.6.1 fix is simple and fixes the regression, which is important as it is late in 3.6.1 (RC3). We can discuss more elaborate solutions for 3.7. I have created a clone of this bug to continue the 3.7 discussion in: Bug 324344 3.6.1 fix has been applied to the branch. Thanks McQ for looking at it. It's not the right place but it's certainly better than throwing away a potentially helpful warning. And if something goes wrong, an Eclipse developer would look to the Error log sooner or later. And the !status.isOK() check was almost in there already in 3.6.1. Pleeease. :) (In reply to comment #18) > It's not the right place but it's certainly better than throwing away a > potentially helpful warning. And if something goes wrong, an Eclipse developer > would look to the Error log sooner or later. And the !status.isOK() check was > almost in there already in 3.6.1. Pleeease. :) There were no errors reported in 3.6.0. For 3.6.1 we are simply fixing the NPE. Additional error reporting is not a critical fix for a maintenance release. As said, we'll improve this in 3.7. Verified in M20100902-1717 |