| Summary: | [prov] IU to set launcher name in the product IU | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Pascal Rapicault <pascal> | ||||||
| Component: | p2 | Assignee: | Andrew Niefer <aniefer> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | dj.houghton, simon_kaegi | ||||||
| Version: | 3.4 | Flags: | dj.houghton:
review+
pascal: review+ |
||||||
| Target Milestone: | 3.4 RC2 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Pascal Rapicault
ping What is the problem if this is not fixed? Andrew to double-check if this is still an issue. There exists some cases where the launcher setter IU is generated and some where it isn't. However, in all cases, this launcher setter IU is not added to the product IU. Though it would get added to a root IU if a .product file is not used. This launcher name appears to be used by framework admin when generating the eclipse.ini file. When not set, 'eclipse' is the default value. The consequence of not fixing this is that for product with executables named something different, install results in an 'eclipse.ini' instead of an 'rcp.ini'. I think this should probably be fixed. Created attachment 101595 [details]
patch
Patch is trying to change as little as possible, so no changes are made to existing logic around the calls to generateLauncherSetter.
The patch adds one more attempt to create the launcher setter since there were cases (most obviously when os=win32) where no setter was being created.
The patch adds the resulting IU to the collection to be included in the product query.
There as also minor changes to the IU itself to set the proper filter and provide the correct self capability.
Created attachment 101650 [details]
updated patch
Further testing on linux showed the patch (while good) was insufficient. The existing code to guess a value for the launcher name took any root file/folder that didnt have an extension and we ended up with a configuration.ini file.
Updated patch checks the info.getExecutableLocation() first and only guesses if that did not point to an existing file.
New patch has been tested on linux & windows. Pascal can you please re-review the new patch and release if good. Patch released. |