Community
Participate
Working Groups
Currently launching a test bundle to try the new JavaScript debugger is non-trivial to say the least. The launching story should be polished such that: 1. we can support single-click launching - deploy a script from an editor for example 2. we can support deploying a project (bundle) of scripts in a single / few clicks 3. we can support attaching to a framework running a bundle of scripts - we currently support this method, but it is overly complicated and prone to errors
it also needs to be more clear how to add a browser/web document environment to js -- or preferably to have it added by default. Because without this you get a zillion "object not defined" errors when writing javascript code for the browser DOM -- which is the normal use scenario. Can't image what I'd do with a stand-alone js program, seems a pretty rare usage, so feel that Browser DOM config ought to be the default instead of something that must be discovered as to how to add it. I never did figure out how to debug js inside of eclipse and was not willing to devote a zillion hours to figuring it out. Firebug is adequate and can be figured out in about ten minutes without reading any docs. Eclipse JS debugging needs to be at least as easy to use as Firebug and able to figure out in 15 minutes or less, would expect it to use the same/similar debugging system as PDT.
Erik, more browser-oriented javascript debugging can be found in Eclipse ATF project, where we use Mozilla engine and you can simply Debug any HTML file similarly to Firebug. Hopefully e4.javascript and ATF will eventually merge into one.
(In reply to comment #2) > Hopefully e4.javascript and ATF will eventually merge > into one. That would be awesome
Created attachment 160547 [details] launch shortcut This patch provides the launch shortcut hooks for us. It currently does not provide resource mappings for configurations - so context launching is not supported. The shortcut is available for the project explorer, the JavaScript editor and the JavaScript outline view. When used the shortcut will open the launch dialog on the MRU JavaScript configuration or the JavaScript configuration type if there are no existing used configurations
applied patch to HEAD
(In reply to comment #1) > it also needs to be more clear how to add a browser/web document environment to > js -- or preferably to have it added by default. A) In eclipse helios, i'm getting "d:/eclipseHelios_workspace/test-html/webcontent/inter.js", line 3: uncaught JavaScript runtime exception: ReferenceError: "alert" is not defined. " when loading in rhino a function like: function inter(){ alert("x"); } So practically for static web project development-time js debug, helios rhino console is not yer suitable, right? B) Also, i see that the load command copies any loaded js file in "External Javascript Source" folder in Project Explorer. Then only the breakpoints set in these files, not in the original ones in the js projects, are visible. So Rhine synchronizes with the breakpoints in these files. Although in the js debug config you can add projects in the Source tab, projects whose script breakpoints Rhino should synchronize with. Excuse me if i'm wrong or a work in progress. Thank you.
Hello all, Its good to see that great effort is being put into making Eclipse work with JavaScript. My original expectation was to quickly tinker with some standalone JavaScript but that did not happen as expected. Originally I looked to the JSDT documentation for help on what to do but it seems that is in development. Then I tried FreeNode and was lucky to meet a few friendly developers. I was given instructions on how to get things going by Michael Rennie. This allowed me to use Rhino and enjoy its Java bindings. I am happy to be off the ground but this experience was not what I was hoping for. I was hoping for a JavaScript VM to be launched and run immediately after clicking Rhino without all the setup. So I am eagerly awaiting this feature as well as launchers for Firefox/SpiderMonkey, Chrome/V8 and additional VM's.
Things can't be done over night for us, the users. I see it as an opprotunity to see, in general, how a future successful product looks like in the early stages. Personnaly i congratulate all those who work on open-source code for others to use. It is a worl in progress, some things are not done, and many are.
Created attachment 175601 [details] WIP This zip contains an entire project org.eclipse.wst.jsdt.rhino.ui that provides single click launching for Rhino analogous to JDT Java applications. Available in the project: 1. Separate launch configuration type for Rhino 2. refactoring hooks for the configurations 3. configs can be created to launch an entire project of scripts, a single script (from anywhere) or a single script from a given project. 4. there is a killer Rhino icon 5. resource mappings are supported on the configurations, so context launching will be added 6. new configurations initialize based on current IJavaScriptElement context There is a lot of polishing to be done: 1. computing a scope of scripts is not done - the launch will not actually interpret a script, currently it simply launches the Rhino debugger back-end and auto-connects the client debugger to it 2. while refactoring hooks have been added they are not complete - no updates are performed currently 3. There is a problem with re-launching, where the debugger seems to wait indefinitely. 4. needs a launch shortcut for context launching
marking bug 306227 as a dep, as the fix for the single-click launching will be provided in a new Rhino UI bundle
Created attachment 176066 [details] wip2 This patch resolves all the issues with the last bundle.
(In reply to comment #9) > Created an attachment (id=175601) [details] > WIP > This zip contains an entire project org.eclipse.wst.jsdt.rhino.ui that provides > single click launching for Rhino analogous to JDT Java applications. > Available in the project: > 1. Separate launch configuration type for Rhino > 2. refactoring hooks for the configurations what is a refactoring hook - how can i see it at work? > 3. configs can be created to launch an entire project of scripts, a single > script (from anywhere) or a single script from a given project. > 4. there is a killer Rhino icon > 5. resource mappings are supported on the configurations, so context launching > will be added what does it mean "resource mappings are supported on the configurations" > 6. new configurations initialize based on current IJavaScriptElement context > There is a lot of polishing to be done: > 1. computing a scope of scripts is not done - the launch will not actually > interpret a script, currently it simply launches the Rhino debugger back-end > and auto-connects the client debugger to it isn't this in opposition with point 3 who says "launch an entire project of scripts, a single script ... "? pls. help me understand. > 2. while refactoring hooks have been added they are not complete - no updates > are performed currently what upadates? > 3. There is a problem with re-launching, where the debugger seems to wait > indefinitely. > 4. needs a launch shortcut for context launching
(In reply to comment #9) > Created an attachment (id=175601) [details] > WIP > This zip contains an entire project org.eclipse.wst.jsdt.rhino.ui that provides > single click launching for Rhino analogous to JDT Java applications. > Available in the project: > 1. Separate launch configuration type for Rhino > 2. refactoring hooks for the configurations > 3. configs can be created to launch an entire project of scripts, a single > script (from anywhere) or a single script from a given project. > 4. there is a killer Rhino icon > 5. resource mappings are supported on the configurations, so context launching > will be added > 6. new configurations initialize based on current IJavaScriptElement context sorry but i don't catch the notion of a "configuration intializing on a context" in practice what does it mean. thank you > There is a lot of polishing to be done: > 1. computing a scope of scripts is not done - the launch will not actually > interpret a script, currently it simply launches the Rhino debugger back-end > and auto-connects the client debugger to it > 2. while refactoring hooks have been added they are not complete - no updates > are performed currently > 3. There is a problem with re-launching, where the debugger seems to wait > indefinitely. > 4. needs a launch shortcut for context launching
> what is a refactoring hook - how can i see it at work? A refactoring hook in this context refers to a contribution to the Rename / Move extension point so that I can update script names / project names when a refactoring is done: i.e. if you rename a script that is set as the script attribute on a launch configuration it will update automatically for you > what does it mean "resource mappings are supported on the configurations" This is an implementation detail for launch configurations. It allows the platform to contextually launch an existing (or auto-create a new) configuration based on the current selection in the IDE when you invoke the the debug command (from the keybinding or the toolbar icon). > isn't this in opposition with point 3 who says "launch an entire project of > scripts, a single script ... "? pls. help me understand. I fixed this up in the latest WIP to only allow you to launch a script from anywhere OR a script from a project; I removed the ability to just specify a project to launch. > what upadates? See the comment above about the refactoring hooks: these updates automatically change the names of refactored projects / scripts in the launch configurations > sorry but i don't catch the notion of a "configuration intializing on a > context" > in practice what does it mean. The context is referring to a JavaScript item selection in the IDE. If you have, for example, a script selected in the either the editor or the package explorer and you create a new launch configuration (either via the launch dialog or Ctrl+clicking the toolbar button) you will get a new launch configuration that is initialized to the selected script and the project of the selected script. A note on the refactoring, I realized I did not include it in the latest WIP, which is OK because I found a bug in my code anyways :)
Thank you very much for the responses.
Created attachment 176573 [details] wip 3 further updates include: 1. all refactoring working 2. a new 'include' tab on the launch configurations that allow you to specify exactly what scripts / folder of scripts to launch with 3. better source containers that track the 'include' entries
Created attachment 176574 [details] patch to JSDT help This is a patch that stubs out / hooks in the help topics for the new Rhino UI bundle
sorry to come back to an early question. You said 2 things that contradict: A) [...] 3. configs can be created to launch [...] a single script (from anywhere) or a single script from a given project. [...] B) 1. computing a scope of scripts is not done - the launch will not actually interpret a script, currently it simply launches the Rhino debugger back-end and auto-connects the client debugger to it Question 1) So a launch config can "launch a script", on one hand (see A), and on other hand a launch config just launches the rhino and the client debugger without the script playing any role at all (see B). Question 2) what is "computing a scope of scripts"?
> 3. better source containers that track the 'include' entries Question: what is to "track the 'include' entries" ?
(In reply to comment #18) > A) > 3. configs can be created to launch [...] a single > script (from anywhere) or a single script from a given project. Yes. In the launch dialog you can specify just a script OR a project and a script > > B) > 1. computing a scope of scripts is not done - the launch will not actually > interpret a script, currently it simply launches the Rhino debugger back-end > and auto-connects the client debugger to it This is working now - albeit crudely. The main hurdle is that I have no way to compute that two (or more) scripts are related. For example if you have a.js and b.js consider: (1) a.js references an element from b.js or (2) a.js refs b.js and b.js refs a.js (a cycle). In this example Rhino just throws a JavaScript exception saying a referenced element cannot be found (not terribly useful). > Question 1) > So a launch config can "launch a script", on one hand (see A), and on other > hand a launch config just launches the rhino and the client debugger without > the script playing any role at all (see B). In its current state it launches whatever script you specify, those comments were for the work in progress - at that particular time I did not have launching a script AND the framework done. It is done now. > Question 2) > what is "computing a scope of scripts"? Computing a 'scope' is referring to all of the scripts that should be interpreted along with the one you are launching to ensure you do not get JavaScript exceptions about 'unknown references'. In its current state, by default, I compute the scope to be the folder that the script you are launching resides in - so if there are more scripts in that folder they too are interpreted when you launch. Using the 'include' tab you can add more locations / scripts to the scope. > Question: what is to "track the 'include' entries" ? Basically, the source path will automatically update when you add and entry on the 'include' tab. For example, say you add /home/you/scripts to the include path, you will get (automatically) and corresponding entry on the source tab.
Thank you so much for these responses.
committed new Rhino UI bundle containing the launching story to HEAD + the help patch + updates to the JSDT feature. Marking this bug as fixed. Any additional bugs / polishing can be in their own bug reports
It should be noted that the new Rhino UI bundle uses brand new API from platform debug, so until the next I-build (or N-build) for the platform you will need platform debug in your workspace. The API was provided in bug 322676.
