| Summary: | Feature based launch ignores version numbers | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Ankur Sharma <ankur_sharma> | ||||
| Component: | UI | Assignee: | Ankur Sharma <ankur_sharma> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | curtis.windatt.public, ekke, ralf | ||||
| Version: | 3.6 | Flags: | curtis.windatt.public:
review+
|
||||
| Target Milestone: | 3.6 RC1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 284887 | ||||||
| Attachments: |
|
||||||
|
Description
Ankur Sharma
There isn't the time left in M7 to fix this, moving to RC1 This is how the logic will work 1. if the feature is not tied to specific plug-in version, then pick the highest one 2. If the feature mentions specific version and plugin resolution is workspace, then pick one from workspace whichever version it is 3. if workspace doesn't has it or plugin resolution is external, then check the target. If an exact match is found, pick that, if not pick the highest. Created attachment 166657 [details]
Patch
The logic was always there but it was broken. It was failing if the first plug-in was the exact match.
(In reply to comment #2) > This is how the logic will work > > 1. if the feature is not tied to specific plug-in version, then pick the > highest one > 2. If the feature mentions specific version and plugin resolution is workspace, > then pick one from workspace whichever version it is > 3. if workspace doesn't has it or plugin resolution is external, then check the > target. If an exact match is found, pick that, if not pick the highest. this sounds really good :) I'll test if available in I-Build +1 Committed to HEAD. I'm also committing a javadoc comment to explain usage of the getBestCandidateModel() method. The patch fixes the logic error. The method should be refactored as it has duplicate logic and other problems that make it harder to follow. However, it is RC1 and not worth the risk. Ekke, if you could try out the change in your use case it would be appreciated. (In reply to comment #5) > +1 Committed to HEAD. I'm also committing a javadoc comment to explain usage > of the getBestCandidateModel() method. The patch fixes the logic error. > > The method should be refactored as it has duplicate logic and other problems > that make it harder to follow. However, it is RC1 and not worth the risk. > > Ekke, if you could try out the change in your use case it would be appreciated. thanks - I'll test it with one of the next I-Builds I', at the JAX 2010 conference until thursday - so perhaps won't find time before friday back home ekke (In reply to comment #5) ... > > Ekke, if you could try out the change in your use case it would be appreciated. did some tests at the weekend. but couldn't make it run. target platform with active ide + some update sites then wanted to launch, but couldn't launch because org.eclipse.sdk.ide couldn't be found, I got the error: Application "org.eclipse.ui.ide.workbench" could not be found in the registry and Validating the launch config fails was reported per ex: missing constraint - required bundle org.eclipse.emf.common, but the feature org.eclipse.emf.common was selected all tried using I-Build from 20100506 will setup a new installation and do some more tests to figure it out what happens but at first have to do some work for customer - hopefully this evening I can test more |