Bugzilla – Full Text Bug Listing
| Summary: | Breaking change in IVMInstall.getInstallLocation() | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Martin Aeschlimann <martinae> | ||||||||||
| Component: | Debug | Assignee: | Curtis Windatt <curtis.windatt.public> | ||||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||||
| Severity: | blocker | ||||||||||||
| Priority: | P3 | CC: | curtis.windatt.public, darin.eclipse, jeffmcaffer, jwross, Michael_Rennie, philippe_mulet | ||||||||||
| Version: | 3.3 | ||||||||||||
| Target Milestone: | 3.4 M3 | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | Windows XP | ||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Martin Aeschlimann
Not sure what we can do about this until Darin is back from vacation, the change wa PMC approved so I think it will stay... We can wait for Darin as I don't expect many users to use this feature. I'm not sure if the PMC was aware of the breaking API when this got approved. Bug 181026 is 3.4 bug for the change. Yes, the PMC was aware of the API change. A migration guide entry is still pending. The only other option for making this work is to add yet another IVMInstall(N) interface that has new, optional methods - such as set/getDefinitionFile(...). The other thing to note, is that the definition file allows for such a flexible VM installation, that there may not even be a "home" directory. For example, the definition file tells us where the VM executable and its libraries are, but they do not have to be in the same directory structure, or do not have to be relative to an install location (although, they usually are). We would perhaps have to add a "home directory" property to the definition file? or a javadoc command? seems like adding a java home directive in the ee definition would make sense. Not sure that it completely solves the problem though. If people are expecting to compute a location relateive to the install location then the install structure must be coherent somehow. Otherwise you have to enumerate the location of everything that people might have an interest in. Do you really need set/getDefinitionFile(...)? Or don't you just create a VMInstall from a definition file location but then all data is filled in? About adding a new IVMInstallX interface. You already have an abstract AbstractVMInstall, can't you just add the new API there? Our design leaves the format of the definition file up to the "vm type". In this case the "standard VM type" understands the "ee" file format. It's possible that other vm types would have another format (although, we encourage one standard format). So, we want the VM type and VM install to have access to the definition file so they can consume it (i.e. the dialog does not parse the file and create a VM with properties from the file). Looks like we'd need to add more methods to IVMInstallType (or AbstractVMInstallType), as well - in order to validate a definition file, and retrieve default libraries for a definition file. As well, it's important to have an API to allow others to create VMs from definition files. For example, we support VM install extensions (to populate a workspace with VM installs). This extension point not supports the specfication of a definition file as well (rather than VM properties). Created attachment 78364 [details]
patch
This patch avoids the breaking API change by adding a new VM type (EE VM Type). Using this approach, an EE file is used to create a VM install with a properties/attributes from the EE file. The EE file is then discarded (not remembered). Instead, the VM behaves much like a "standard VM" except that is has a custom set of libraries, VM args, etc., derived from the file.
Since the VM cannot be created the using the standard API (i.e. from an install location), an API is provided in JavaRuntime to create a VM from an ee File.
We should really extend the UI to allow VM types to provide a wizard to define/create/edit VM installs. The standard UI can be used when no custom UI is provided.
Plan to re-work the API changes in 3.4 M3. We won't advertise this as new and noteworthy feature yet. Nothing breaks/changes unless a user uses an .ee file (which is yet rare). Created attachment 79019 [details]
patch
updated patch. Still work in progress, but has initial draft using wizard for JRE install edit/create.
*** Bug 200245 has been marked as a duplicate of this bug. *** Created attachment 79587 [details]
patch
updated work in progress
Created attachment 79685 [details]
patch
Ready for final review.
Released to HEAD. API changes have been reverted. Unfortunately, and EE VM definitions in workspaces will be lost, as there is a new VM type for EE's and the 'Standard VM type' no longer recognizes EE files. However, the use of EE's was new and limited to a few, so I don't see the need for migration help. Please verify, Curtis. Open new bugs as required. Verified. Opened bugs for usability issues. |