Community
Participate
Working Groups
Created attachment 198643 [details] Screenshot showing defective launch config Dlg +++ This bug was initially created as a clone of Bug #289107 +++ With the new rhino.ui bundle added through bug 289107, a dependency onto org.eclipse.jdt.launching was added to JSDT, which in turn drags in jdt.debug and jdt.core. As a result, when I start with the Indigo C/C++ package and then install PHP from Indigo (which includes JSDT), I get a Launch Configuration Dialog as in attached screenshot: - There's "Java Applet", "Java Application" and "Remote Java" Launch Configuration Types, but no respective icons - Trying to create such a launch brings up an error dialog ("No tab group defined") This is because the jdt.core extensions are present without their jdt.ui counterparts. I'm wondering whether the JDT dependency in the Rhino Launch could be avoided or at least be made optional? A quick check seems to indicate that RhinoLocalLaunchDelegate.java is the only class which drags in the extra JDT dependency.
(In reply to comment #0) > > I'm wondering whether the JDT dependency in the Rhino Launch could be avoided > or at least be made optional? A quick check seems to indicate that I agree whole-heartily this is a problem, but currently I can't think of any way to avoid this - to launch Rhino we have to use a VM, and jdt.launching controls all of that (specifically we use JavaRuntime, StandardVMType and SocketUtil). I am open to suggestions.
In our product we don't have a strong need for JavaScript debugging (editor / syntax highlighting are our main concerns). We already thought about removing the rhino.ui bundle entirely from our product. Not sure if that would deprive us from any debug capabilities entirely? A couple other thoughts that come to mind (not being a Javascript developer myself)... - In last year's version, there was no jdt dependency... is that Launch still available? Or would that make no sense at all? - Could the VM information be re-used that was used to launch the current Eclipse instance as a fallback? There's lots of System Properties which provide information about every aspect of the VM. - Could essential jdt.launching infrastructure be refactored out of JDT into a common bundle? With newer languages (like Scala) that execute on top of the VM that might be a good idea anyways. JDT dependencies came up in another context too (bug 271627 comment 19)
(In reply to comment #2) > In our product we don't have a strong need for JavaScript debugging (editor / > syntax highlighting are our main concerns). > > We already thought about removing the rhino.ui bundle entirely from our > product. Not sure if that would deprive us from any debug capabilities > entirely? A couple other thoughts that come to mind (not being a Javascript > developer myself)... > > - In last year's version, there was no jdt dependency... is that Launch still > available? Or would that make no sense at all? Yes. Last year all we had was the 'Remote JavaScript' launch configuration, if you removed the rhino.ui bundle all you would lose is the 'Rhino JavaScript' launcher / configuration / launch shortcut > > - Could the VM information be re-used that was used to launch the current > Eclipse instance as a fallback? There's lots of System Properties which > provide information about every aspect of the VM. > That would be one way to get rid of the dependency, and would involve some code copying from jdt.launching. > - Could essential jdt.launching infrastructure be refactored out of JDT into > a common bundle? With newer languages (like Scala) that execute on top of > the VM that might be a good idea anyways. JDT dependencies came up in > another context too (bug 271627 comment 19) That sounds quite reasonable to me, the major problem I see with that idea is that it would require a lot of API changes. Although I guess if jdt.launching re-exported the new bundle / APIs we would be ok.
*** Bug 351415 has been marked as a duplicate of this bug. ***
Moving this to JDT debug, all of the investigatory work for splitting jdt.launching will happen there anyway.
Ping, is this going to be followed up on ?
(In reply to comment #6) > Ping, is this going to be followed up on ? There is currently no one having time to do this.
Is this a duplicate, or related to, bug 259196 ?
Yes, it is a duplicate of bug 259196 *** This bug has been marked as a duplicate of bug 259196 ***
