JSDT/Confcalls/Minutes 20160301

Logistics

See JSDT/Confcalls

Attendees

Alina, Patrik, Gorkem, Ilya, Adalberto, Mickael, Orlando, Ian, Victor, Alexey, Chuck

Notes

JSON Editor

Victor's load all fix is already in master Alina: In some points the JSON editor works like the XML one, and it shouldn't do that way. As an example in notes/annotations Victor: indeed, as you can see when removing last char - it will invalidate annotations Patrik to ask questions to capture the architecture using mattermost for communications

For JSON editor JUnit tests, the CQ is approved: http://dev.eclipse.org/ipzilla/show_bug.cgi?id=10998

Grunt and Gulp

Work is frozen. Ilya has created a video and writing a blog on these features. See https://www.youtube.com/watch?v=V7sZVTNHNYM

JS Debugger

Ilya: Chromium breakpoints are quite different wrt JSDT ones. The lifecycle is different Orlando polished and cleaned the code before reusing. The work is going to be using the "Nodejs paradigm" . Gorkem: in Gulp and Grunt Nodejs is just a tool; that's why cli delegation is there. (..) cli builds the bash delegation, after configuring the path correctly and makes the calls (CmdLIne). The Nodejs in a run configuration is different than CLI; it will be more like having a new JVM (like in run > run configurations..) Question: when the launcher should be enabled? > javascript project (JSDT nature) + Action available on package.json files. Mickael: it could be on R-Click > Run > Run As - it shouldn't be confusing having it on any package.json file Victor: package.json it can be in any folder. Should we check only in root folders, or in any folders? Mickael: tricky question: for modular projects it may be confusing Chuck: when you consider the enablement of the container, you should check the existence of the package.json at its root Ilya: Note: For Bower you can rename, but for NPM you can not rename the package.json file in the module root. We'll need to add a new plugin for this

ES6

Parser Committed, it has very good performances i.e. parsing in 30ms, but then the validator takes a couple of secs. Gorkem used Orlando work that really helped to nail down where the old ES-X compiler was used. Shane cleaned syntax highlighting: Nashorn extension plugin is needed (currently is a fragment extending system bundle) because Nashorn is not exposed to JRE. However, this does not work entirely, or better: on the extension plugin, we'll see some error, but it is only a visibility problem, (bad interaction Windows - JRE :) It is important to properly configure the classpath, Chuck: suggests finding a better way to put Nashorn on the classpath. Gorkem: warn that we should deal with OSGi specifics Mickael: there is already something, it sounds similar to the JavaFX issue

Code completion

Ian is getting focused on testing to make sure of the correctness of future code. Shane is going to remove project preferences for ES-X (as we, the team, decided) plus he is going to work on syntax highlighting for literals. Orlando will integrate his changes when the Esprima parser is released. Not sure if we should remove (or deprecate only) some API. Gorkem: deprecating seems the correct way. However, we should consider that most of the JSDT is provisional since a long time (years).

JS Libraries

Gorkem did a small demo on how we can show the js libraries to the user.

As an example, when we open a js project and look into the project > libraries. What you see now is obsolete, as the EcmaScript libraries are outdated. We need to update how we load libs. We should think thoroughfully

1. Look at the"Add Javascript Library" dialog, we can add JS libs here. This is a possible way to proceeed (but it is Old School).

On the opposite, we have a different category of lib resolution, where the IDE understands directly the JavaScript artifacts:

2. Understand Definitely Typed files. Pros: there are thousands of projects using them, so we can leverage a huge ecosystem. i.e. https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/cordova/cordova.d.ts 3. Make our Javascript project understands directly JSON files (and present it) i.e. Turn JS project (JSON) is interesting, also because there is a tool that converts Definitely Typed files to TURN ^^ The latter two options seem "the good way to go" for JSDT - Embracing the Javascript paradigm. Adalberto: what about versions ? does these approaches give stability on choosing versions ? Gorkem: yes, we can have stable versioning. i.e. definitely typed files have files Mickael, what about integration, and if the user wants to change the definition? Gorkem the two method presented can coexist, it is just a matter of priority.

(action) ->Gorkem is tocreate a bugzilla to follow up with libs and do some testing

JSDT and the community

Patrik released a video on how to setup JSDT dev env: https://www.youtube.com/watch?v=SFxfuudlau8 (not mentioned in the call) Patrik is also Interested in providing an Oomph installer. Trying to do this in next weeks (shared gdoc, editable https://docs.google.com/document/d/1pLW-HHVjymOQOG5M57M0m-jDpoMXQ05pWxZG_oUyR-A/edit) Documentation: want to make shared edits to contribution guide Contribution guide and main documentation, as an example split contribs page in arch and setup. Will ask in IRC and Mattermost (shared gdoc, editable: https://docs.google.com/document/d/1NNTZEVLsgg7ofgwtjt-se1mIH7rbH5zv_VTdslT_ckI/edit you can comment)

Packaging

Mickael: looking to Javascript IDEs, developers have not many choices, as an example IntelliJ WebStorm (free for 30 days, then pay). Should we consider to enter the market with an IDE, shipping Javascript package for Eclipse Neon? Gorkem: an EPP package is not a big pblm, isn't it ? Mickael: correct, it requires some effort, but it can be done. ( We already requested a Javascript Package, in the past, but now is not anymore actual)