Bugzilla – Full Text Bug Listing
| Summary: | [target] Target Platform specifications without location mismatches with variable ${target_home} | ||
|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Thorsten Hoffmann <thorsten.hoffmann> |
| Component: | UI | Assignee: | PDE-UI-Inbox <pde-ui-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | ankur_sharma, curtis.windatt.public, darin.eclipse |
| Version: | 3.5 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | stalebug | ||
I didn't quite understand the problem. The Target Platform preference page shows all the locations for a target in the Locations sections. It even shows the variable and the resolved location. And, where do you expect the 'Up' and 'Down' buttons? On the 'Locations' tab or on 'Content'? Either way, how does the order of Locations or Plug-ins/Features matter? Also, reducing the severity to normal as no use case looks broken. This is a known problem, in the backing code, we still separate the locations into a primary location and secondary locations. For the most part, users cannot access the information (the preferences are internal), but this variable and in one api class we allow access. We want to move away from target's having a single location. A target may be a collection of bundles in folders and may not describe a single location. This means that we do not want to provide up/down buttons or the ability to choose a primary location. Eventually the backing preferences will be removed entirely and there will be no sense of a primary location at all. Most likely the target_home variable would be removed. Can you explain your use case in more detail? It would be helpful to understand any reasons why a primary location is required. (In reply to comment #2) > Can you explain your use case in more detail? It would be helpful to > understand any reasons why a primary location is required. We have four target platform location in our project. This worked well in Eclipse 3.3 and 3.4. In these versions, we specified the base directory, common to all four locations, as the location (field "Location" in Eclipse 3.4). This was referenced by the variable ${target_home}. Since 3.5 this field is no longer available for common developers. We use this variable to address our custom JRE version in our launch configurations, which is also located under the base directory, previously specified in the previously available "Location" field. We urgently need this information since not all colleagues have the same directory structure on their computers, so a variable is required that references some directores (JRE root here). Otherwise, we cannot commit those configuration file into our SVN our every labour has to re-design his/her directory struvcture and assure that it's conform to all others. But this causes problem since some labours are working on several projects and structures may collide. A sunstitution of windows directories is no alternative, because there are problems with it under Windows 7. Alternatively, a new "global" variable that references the root dir of the chosen JRE would also be helpful in our case. (In reply to comment #3) > Alternatively, a new "global" variable that references the root dir of the > chosen JRE would also be helpful in our case. Just an FYI - in 3.7 JDT just added support for ${ee_home:<id>}, where <id> is an execution environment ID such as "J2SE-1.4". The variable maps to the home location of the JRE. What sort of variable would you want? (In reply to comment #4) > > Just an FYI - in 3.7 JDT just added support for ${ee_home:<id>}, where <id> is > an execution environment ID such as "J2SE-1.4". The variable maps to the home > location of the JRE. > > What sort of variable would you want? That information will be helpful as soon as we use Eclipse 3.7 company-wide, thanks. But additionally, we need to set a VM argument for runtime that specifies a certain 3rd party library which is included in one of the target platform locations. This is done in a launch configuration via "-Djava.ext.dirs". With Eclipse 3.4 we used the ${target_home} variable to assemble the path to this library. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. Please remove the stalebug flag, if this issue is still relevant and can be reproduced on the latest release. |
In Eclipse 3.5 and 3.6, an "optimization" according to specifying target platforms has been made. In previous versions, there was a separate field for defining the target location (named "Location"). This was the value the variable ${target_home} referred to. In later versions, this field disappeared, so the developer cannot recognize that now the variable ${target_home} refers to the FIRST entry (directory, feature, etc.) for a target platform. This caused several hours of research for me this day. Furthermore, once the developer added several entries, he has no chance to reorder them, because there are no "Up", "Down" buttons available. So, the developer must remove all entries and re-add them in the wanted order. I'd suggest either to provide the old Location chooser components again or to provide at least some reorder buttons and a simple label that displays the value, {target_home} currently refers to.