Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
JSDT/Confcalls/Minutes JSDT Debugger
Contents
Logistics
See JSDT/Confcalls
Attendees
Presenter: Dennis Participants: Dennis, Chuck, Max, Gorkem, Victor, Alexey, Adalberto Ilya, Orlando, Patrik, Mathieu
Notes
This Confcall is about Debugger : how it was contributed, how it works + info on current development status (at Neon M6)
Chrome dev tools was developed by Google and was released under Eclipse EPL
https://github.com/ChromeDevTools/cdt-java
Google changed license to EPL and this made the Eclipse CQ much faster, because the license was changed by source owner and released into original repository.
After CQ was done, the code was refactored to org.eclipse.wst.jsdt.chromium namespace and released to the JSDT git repository.
It actually works with most of the latest browsers:
- All browsers based on Chromium can debug JS in the same way as Chromium does (* i.e. Chrome, Opera)
- Safari is debuggable trough bridge developed by Google,
- IE is potentially debuggable via "IE Diagnostics Adapter"
- Firefox (as IE) is potentially debuggable via adapter, plus some implementations are already available on github.com
Supports Nodejs up to v.5.6.0 - see https://github.com/v8/v8/wiki
Chromium was forked from Webkit. so it supports WIP (webkit inspection protocol).
You can search developer.chrome > chrome debugger-protocol to see specs
The latest and greatest release, as ofi March 2016, s v 1.1 (Chrome 31)
Demo
Setup and Run chromium:
- Clone from eclipse git repository
- build via "mvn clean install --Pbuild-individual-bundles"
- install into latest eclipse using local update site from site/target/repository inside local git repo
Builds on it JSDT
create a local p2 repo declared wtp-parent/pom.xml - easy to use
- install Javascript Development Tools Chromium V8 remote debugger tests from that p2 repo
(you can start with Eclipse for Committers -> simple to start)
(*NB: javascript debugger bundle is in IDE workspace )
start node.js in debug mode
node -debug-brk app.js
eaxample: node -debug-brk my-helloworls-app.js
You will see the debugger listening to port XXX
Then it starts executing and it stops the executions at the specified line (the 1st)
(*)
launch config standalone V8 ...
... port 5858
And then the debugger (via WIP ) support exploring the JS object model in the application
it is not supporting all the use cases out of the box -> there are tricky use cases,
for long running apps can use the -debug key (opposite of -debug-brk)
for this you'll need chromium:
chromium --remote-debugging-port=9222 -user-data-dir=/<user-home>/somepath
this opens the browser with two tabs, on localhost:8080/app (in our case a simple angular app)
and running the app, we can debug it on eclipse.
In the current implementation, debugging sessions are seen in Eclipse as virtual file system, anc this causes problems (Update: solved via Bug 484597 )
the debugger allows basic interactions that the normal Eclipse debugger has like explore var, hover and see hints, etc..
in the demo application we have a button linked to a breakpoint, and it actually works, stopping to the breakpoint
Development Environment
Several Options
- JEE IDE as main env + JSDT git repo
- Committer IDE + JBosstools as TP (*)
- JSDT Target platform instead of JBoss one
- Oomph installer ( very quick )
(*JBoss tools .target as target platform -- it has all the dependencies needed from JSDT)
Option 4 it is a great candidate, as it can save a lot of time. Plus this is simpler --> more people involved
Action: bugzilla issue https://bugs.eclipse.org/bugs/show_bug.cgi?id=488343
Bundles, are easy to understand looking at the slides , as example:
".V8" manage tabs; ".debug" is for branding, ".debug.core" is the core;
".jsdtbridge" is a simple bridge between chromejs and JSDT (couple of classes)
etc...
Chromium Remote Debugger features: easy to understand, and self explained
For the High level arch. see the image on the slides
There are currently 3 implementations to work with remote debugger: V8, WIP 1.0 and WIP 1.1
Communication is based on messages, formatted as json
Notes on JSON Parser
The ChromeDevTools JSON parser is a Dynamic parser based on Java Proxy and Reflection. It generates a static parser, which is faster to process, but it is generated only at build time (design decision) The specification of the (old) message-based protocol is specified here: https://github.com/v8/v8/wiki/Debugging-Protocol
Challenges / Actions
- Support new V8 releases
- support <script> tag in html
- integration tests with real browsers
- statically generated parsers have problems in handling scripts loaded dynamically (e.g. mocha)
- replace manual WIP Protocol selection with auto
- Currently, the iOS debug is not convenient. We want it more convenient having some out-of-the-box support for safari with ios-webkit-debug-proxy
- Compare the performance of static and dynamic JSON parser impl and switch to fastest.
- Hot deploy for changed js files https://bugs.eclipse.org/bugs/show_bug.cgi?id=488344
There are a lot of items to complete before Neon release. All the possible help is really appreciated !
A bit of discussion
CB: it can be a challenge using a VFS, instead of the standard source (?)
DG: it was used (probably) to make simpler the communication between Eclipse and Chromium
CB: so editing in the debugger seems it is not going to happen :(
IB: seems V8 debugger is more important than WIP
CB/AK: seems you're not going to launch debug from Eclipse
What if having a launch config for each Node application ? ( or for any Runtime environment that Eclipse understands for Nodejs)
GE: This Java runtime config. JSDT has that concept, but there is nothing for Node js (part 1)
Then launch conf that will use those runtime configs "that Eclipse understands"
--> how to define those runtime configs.
We need the option to use the JSDT Editor to set or breakpoints.
Question: is the VFS that breaks our breakpoint synch ?
DG: probably yes (I have reason that let me think so)
we don't have much time, prioritize some work, and focus as the deadline is 26 of March (M6 for WTP ???)
TEAM, [ACTION AGREED] -> Focus on Nodejs
According to: https://wiki.eclipse.org/Neon/Simultaneous_Release_Plan The deadlines are: M6 (API Freeze) M7 (Feature Freeze)
VR: usually all features should be completed by M6 [API Freeze] - In our case:
- it should be for M6 : around March 25 (for WTP) <-- but JSDT Deadline precedes WTP, and it is march 17 for JSDT
- it might be possible to have exceptions, and deliver by M7 (this will move the deadine to May)
IB: https://bugs.eclipse.org/bugs/show_bug.cgi?id=484597
GE: https://bugs.eclipse.org/bugs/show_bug.cgi?id=359436
CB: When we use the VFS we're kind of tricking the "real breakpoint". With VFS open we can not execute particular actions, like "content assist".
In the short time we have before M7, we'll need to understand and fix the Virtual File System. (* this could be a cool reason to ask an exception and deliver by M7)
CB: quick reference to https://mattermost-test.eclipse.org/eclipse/channels/webtools