Community
Participate
Working Groups
This is needed to support batch programs as well as services running on the test server. One suggestion is to ues an IResourceChangeListener to detect when a *.egldd file has been modified. When this happens, create a <ddname>-bnd.xml file using GenerateServiceBindXMLFileOperation (or DeploymentDescUtil.toBindXML()). The Java runtime already handles includes from the DD. Joe will be updating DeploymentDescUtil.toBindXML() to add the includes to the -bnd.xml file soon. There is no need to update the deployment results view since this is just writing out some XML. If anything goes wrong (cannot read the DD file, cannot write the XML file) then log the error so that it shows up in the Errors view (.log file).
Note that this should only be done for projects with the Java nature. The XML file should go into a Java source folder. For RUI we just provide the DD information on the fly for preview/debug so we don't need to autodeploy the -bnd.js file. This is strictly a Java application requirement.
I assume this is only for the default DD of the project. The <ddname>-bnd.xml will be updated when 1. The content of default dd file is updated 2. A new default dd file is set 3. Default dd file is removed (this should clear <ddname>-bnd.xml). Generated <ddname>-bnd.xml will be put to the default package of Project's javagen output folder.
Can one of the subscribers put together a small design 'document' and schedule a design review meeting on this topic?
In reply to Tony's comment, this needs to be done for all DD files not just the default DD. A DD can import other DDs, and also a user can specify a DD name in their code for syslib.getResource(). The development-mode DD is the default when they do not specify a specific file. I'll start on a design writeup.
This has changed to the following: No autodeployment is performed. The test server and batch Java applications will have their environment configured such that they will be able to locate and use the *.egldd files right from the EGL source folders. They will use the project's default DD when no property file name is passed to syslib.getResource(). The test environments will be given the port number on which EvServer is running, so that they can contact the IDE to dynamically resolve workspace:// URIs (and any other special URIs in the future). The test server will automatically update when DD files are modified, so that it does not need to be restarted. Batch programs may need to be restarted to pick up DD changes. We will create a new launch type for batch applications. You must use our "EGL Java" launch type if you want this test-environment resolution of DDs (and support for workspace:// URIs). If you run a regular Java launch then it will be running the "deployed" version of the program.
The test server and Java runtime have been updated to support this new design. Changes made to edt.ide.rui and edt.runtime.java. Leaving this open since batch programs still need to be addressed.
Batch program support has been released. If you want "test environment" support, you must launch from the .egl file. If you want to test your Java program in "deploy mode", you launch the .java file.
Verified
