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.
E4/Scripting/bofecon12
Contents
Eclipse Scripting BoF session at EclipseCon 2012
Update:A mailing list has been created, see E4/Scripting.
Doing easy customizations and automation of common workflows is the bread-and-butter of pretty much every advanced editor such as Emacs, vi, Slickedit, Textmate or others. Office products such as LibreOffice or the Microsoft suite provide scripting and macro recording as essential capabilities for easy extension. JTAG debuggers such as Lauterbach Trace32 or Greenhills MULTI are even built around scripting.
But what about Eclipse ? What happened to Monkey, Command Shell and all the other ideas ?
Come join us for a BoF at EclipseCon 2012 if you care about making it easy to customize an Eclipse IDE.
Date: | Wed Mar 28, 2012 |
Time: | 7.30pm - 8.30pm (HTML | iCal) |
Room: | Regency Ballroom B |
All are invited, even if you didn't sign up :).
Attendees and Interests
- Martin Oberhuber (Wind River): What is the current state of scripting, why is it so fragmented, and how can we unify it ?
- Anna Dushistova (MontaVista)
- Leo Treggiari (Intel)
- Jeffrey Hiller
- Mohamed Hussein (Mentor Graphics)
- Andrew Eisenberg (SpringSource)
- Matej Spiller Muys (ComTrade)
- Aaron Spear, Vmware
Notes
- Existing Scripting
- Eclipse Monkey (archived)
- Groovy Monkey
- xored Q7 - ECL
- The new OSGi Shell
- Aptana: Rubles
- Emacs+
- TOPCASED
- GroovyEclipse (Editor scripting)
- DLTK - Console for running scripts
- Jython
- Javascript / Rhino engine
- BeanScripting foundation for WebSphere
- Scala etc in plugins
- Mohammed's old extension point infrastructure
- Properties of usable scripting
- Can be pretty pragmatic (scripts don't live too long)
- But if it's good it's going to remain ... people WILL leverage it for bigger things
- Should be self-documenting ("help")
- Eclipse Monkey was too hard to learn how to write something
- Should have escape mechanism into full Eclipse API's
- Ideally, new DOM / Simple API can be created inside the scripting language(s)
- Easy to share / deploy scripts (Monkey model is good)
- Can be pretty pragmatic (scripts don't live too long)
- Script WHAT - Use-Cases
- Simple automation eg Open a View
- Create a Project with certain properties, add some files / folders
- eg find-replace certain things in certain files
- Editor Macros
- Script HOW
- Button / Menu inside IDE
- Connect to running instance and make it do something
- bug 4922 implemented in 3.6 - open a file in eclipse from the command line - uses SWT window system communication
- OSGi shell supports opening telnet port to communicate
- Wind River proprietary socket communication eg eclipse -data someWS -runScript foo will run foo in existing instance if someWS is already open
- This could potentially be contributed
- Testcase from outside (launch Eclipse and do X)
- Automated Recording
- Not perfect, but may help finding ID's etc.
- SWTBot
- Jubula
- WindowTester
- Properties of the Scripts
- Allow multiple languages (eg those supported by JRE 6: JavaScript, Pyhton/Jython, Groovy, ...)