Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 370275

Summary: Rename or possibly remove the enableGenerate option from the EGLDD file and editor
Product: z_Archived Reporter: Ben Margolis <margolis>
Component: EDTAssignee: Project Inbox <edt.deployment-inbox>
Status: NEW --- QA Contact:
Severity: enhancement    
Priority: P3 CC: mheitz, svihovec
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows 7   
Whiteboard:

Description Ben Margolis CLA 2012-01-31 15:55:40 EST
The option does not enable generation of an output, but states whether to include an <egldd>-bnd.xml file during deployment.  If the option must stay, please (a) rename it to something like Deploy binding detail and (b) include the option on both the Add Binding page and the Resource Bindings Configuration page.

EDT shouldn't have an option that clutters the GUI and requires unnecessary thought: 

o  A developer might clear the check box to avoid deploying a file that references a workspace URL.  But the EGL deployer has access to the fact that a workspace URL is in use. The developer's input could be made irrelevant to this case.

o A developer might wants to retain the details of a service binding (whether for reference or for future use) and might clear the check box to avoid including the detail in the currently deployed output. But is the "deployed output" only a small XML file?  If so, isn't it cleaner to provide the file in every case?  If the detail is confidential, the developer can remove the binding and retain the detail in some other way.  

The EnableGenerate option came from COBOL gen, where a generation-time performance benefit was said to be present if the developer cleared the check box sometime after doing an initial generation. Seems not to apply here.
Comment 1 Matt Heitz CLA 2012-11-14 11:22:02 EST
Justin and I discussed this and we both think the enableGenerate option should be removed.  Here are Justin's comments from an IM chat:


it controls whether that particular binding is added to the bind file. it isn't an option for the other types, they should either all have it or none

i vote for none

the only place this is useful is if you don't want to clutter the file with workspace-only entries that have no meaning in a deployed app. however there's a bug to make the rest binding work for both deployed and workspace, like with SQL