Community
Participate
Working Groups
In 3.3 we did a mess of work around the launcher and support for different execution environments. Much of this is documented on the web at places like http://wiki.eclipse.org/index.php/Execution_Environment_Descriptions It would be extremely useful to be able to add Installed JREs based on the definitions found in these files. This would address problems we have today with targetting Foundation 1.1 and other configurations of J9 as well as alternate JRE configurations (e.g., Harmony, JRocket, ...). We envision some relatively simple support in the Add JRE dialog to allow the specification of an .ee file rather than a JRE Home dir. Then, rather than running the discovered JRE to interogate its class lib level, boot path, ... that information would be read directly from the declarative .ee file. Note that this also better facilitates cross platform development where the developers are writing code for a JRE that does not actually run on their development machine (think embedded scenarios).
In case there is any confusion, my PMC vote... +1
Created attachment 63738 [details] example ee file
Created attachment 63777 [details] work in progress Adds infrastructure to support JREs defined by .ee files. The UI is not hooked up yet, but you can type an .ee file name into the "Add JRE" dialog as a home location, and it works.
Created attachment 63794 [details] adds UI for selecting .ee file
Created attachment 63799 [details] more - added support to analyze class lib level, to recognize foundation1.0 and 1.1 configurations (for SDK compatible execution environments) - added support for source archive property (ee.src)
as a point of interest, what is the format for ee.src? the wiki page just says that it is the source archive but in practice that may be many zips/jars. Are we assuming that they are all together in one dir? comma separated list? of what?
Targeting for 3.4
Created attachment 74704 [details] updated for 3.4 Updated patch for 3.4. Modified to read raw roperties file to avoid use of "java.util.Properties" file format (which does escaping, etc).
Created attachment 74950 [details] patch Added support for generating default VM arguments from ee files. So default VM args can be initialized in the "Add VM" dialog (and other places we create VMs - searching, etc). Added method #getDefaultVMArguments() to AbstractVMInstallType (similar to contract for #getDefaultJavadocLocation()). Still need to update EEVMType to return default VM args from the ee file.
Created attachment 74960 [details] patch Updates to generate default VM arguments. All args in the ee definition file are passed through to the VM when invoked, and are set as default VM arguments in the UI.
Created attachment 75076 [details] patch Minor updates to the "add VM dialog". Renamed buttons, update button enablement based on VM type. The "Definition File..." button is only enabled for the "Standard VM Type".
Created attachment 75251 [details] compatible EE's Updated patch to compute compatible execution environments based on class.library.level entry in .ee file.
Created attachment 75772 [details] patch Updated Javadoc in IVMInstallType and IVMInstall to reflect that a description file (in addition to a directory) can be used to describe/validate the install location of a VM install.
Released initial support to HEAD along with tests. We also need to update the 'vmInstalls' extensin point to allow an extension to provide an '.ee' file when contributing a JRE.
Fixed. Update vmInstalls extension point documentation to note that VM definition files may also be referenced by the "home" attribute. Updated JavaRuntime to initialize default VM args from VM install type when no explicit args are specified by an extension.
Please verify, Curtis.
Also updated user doc to describe the new buttons on the Add JRE dialog.
Filed bug 200245, everything else looks good. Verified.
