Community
Participate
Working Groups
Add Eclipse automation. The early scripting prototype included in Eclipse 1.0 attempted to directly expose Eclipse APIs to script writers, which made scripts as hard to write and debug as a plug-in, and lead to internal class loading contortions. These difficulties (and other factors) led us to withdrawn scripting for Eclipse 2.0. Nevertheless, users should be able to script Eclipse actions at some useful level. Eclipse should provide an automation API and make it easy to programmatically trigger Eclipse actions. For example, Eclipse automation could be accessible from Javascript code used within HTML pages displayed by the Eclipse Help browser (or an Eclipse- embedded HTML widget) to trigger actions in Eclipse. [Platform] [Theme: User experience]
The problem I see is that scripting should not just be using Jython or JavaScript to write plug-ins. Scripting should be something that ties all active plug-ins together at once. It's a layer above the plug-in architecture. Experience with the GEF and with our own GUI builder framework (that is based partially on the GEF's design) suggests that some variation on GEF's edit policy framework might help here. The trick is to allow edit policies to define and trigger their own events that can in turn be processed by any edit policy. Then the edit policies can act as event transformers that consume events (or sometimes merely observe them and react to them) and in turn generate new higher-level events about actions that must occur in response to those events. The reason why I think that this might be a good fit for scripting is because edit policies don't know or care who generated an event that they want to consume. The event could come from low-level SWT or it could be a resource change delta or it could be an event coming from the JDT compiler or a selection change event, etc. The edit policy is blissfully ignorant of all this. Similarly, edit policies can be blissfully ignorant of what other edit policies consume events that they generate. In this way, edit policies can operate at a level above the entire plug-in framework, yet at the same time unify it. All of this means that edit policies can afford to take a very global perspective on the Eclipse environment while at the same time not becoming tightly coupled with large numbers of other things. They are kind of like aspects in AOP in that each edit policy can focus on servicing exactly one concern and delegate everything else to other edit policies (or plug-ins: see below) by generating new events. The result is that you may start out with edit policies that process really low-level events (For example, in GEF and SWTworkbench, the lowest-level mouse events haven't even done hit testing yet). However, you wind up with collections of events that are very high-level and abstract. The other result is that the edit policies themselves are very loosely coupled. They normally don't know about the existence of anything other than the events that they are trying to process and the events that they generate in return. Or they just know about the events that they are trying to process and the APIs that they will call to cause some side-effect to happen when an event occurs. Advantages and disadvantages of this approach: This basically has all the advantages and disadvantages of the Observer pattern, but at a much larger scale. Advantages: Extremely loose coupling amoung components. Disadvantages: Without a careful design to minimize firing of events to edit policies that will simply ignore them, this design will not scale. In the average case, you have an n * m algorithm where n is the number of edit policies and m is the average number of events that are triggered by a single native Eclipse event. This isn't 2^n or even n^2, but it's still very bad when n and m get large. I believe that this disadvantage can be mitigated by requiring edit policies to state (possibly in a public static final String[]) the names of the events that they process. Then the event dispatcher will maintain a HashMap or a TreeMap associating each event to a LinkedList of the edit policies that can process it. When an event occurs, the event dispatcher will just walk the LinkedList and fire the event for the interested edit policies only. What does this have to do with scripting? Scripting could be implemented using an edit policy-like framework on top of the existing Eclipse infrastructure. Existing Eclipse events--SWT events all the way up to the SelectionService events--will be wrapped by the edit policy event dispatcher. To bootstrap the process, the scripting plug-in would manually add itself to ISelectionChangedListener, resource change delta listener and other existing system events. The scripting plug-in would also provide an extension point that plug-ins could extend to add additional event types to provide scripting support for their plug-in. These events would then be wrapped inside something like an "IEditPolicyEvent" object and dispatched to the interested edit policy scripts. I would like to see the interface to edit policy scripts use the Jakarta Bean Scripting Framework. This way we can avoid at least a portion of the scripting language holy wars. It also would provide a response to those who complain about their favorite scripting language not being supported (ie: Make it support the BSF, then we'll automatically support it). Edit policy scripts, for their part, would be able to handle any edit policy event in which they declared interest and/or generate edit policy events of their own. Lastly, the scripting plug-in should provide an API so that plug-ins can add themselves as listeners for specific edit policy events. This way, scripts can contribute back to the Eclipse plug-in environment as well as extend it. Thoughts?
Please consider providing automation API for another use case (besides scripting): whitebox GUI unit test, e.g. for test-driven development (TDD). SWT/JFace has many advantages over AWT/Swing, but one disadvantage is unit test. One can currently do blackbox testing of SWT/JFace UIs, e.g. with RobotJ (now XDE Tester), but refactoring is painful, and these tools lack JUnit integration. By contrast, there are several open-source tools providing whitebox, JUnit-integrated testing of AWT/Swing UIs, notably Abbot, Jemmy (part of NetBeans), and jfcUnit. (See http://www.superlinksoftware.com/cgi-bin/jugwiki.pl?TestingGUIs for a more complete list.) Note that a key component of these tools, java.awt.Robot, is not AWT-specific, and could be extended for SWT. An SWTized Robot would need to be able to, given an instance of an SWT Widget, * find that widget's location in displayspace (global display coordinates) * provide methods to interact with (click or type in) that widget Such a Robot could then be extended to provide more complex actions composed of more basic events. See http://sourceforge.net/forum/forum.php?thread_id=790404&forum_id=168263 for notes regarding current efforts with Abbot.
A while back Scott Rutledge posted the following comment to eclipse-dev, which I wanted to capture here: In order to avoid starting any scripting language wars, Eclipse should simply include a BSF (Bean Scripting Framework) binding, so that any number of scripting languages can be used. See http://jakarta.apache.org/bsf/.
Real Scripting(tm) via a BSF binding would be excellent. But * there will probably always be a need to script UI events for their own sake: e.g. a script author might want to popup a dialog for user input. * the ability to drive the UI would probably be useful in TFD or TDD of Real Scripting, e.g. to ensure that the output of one's script actions (e.g. a Java class) matched the output of the UI that currently provides such output (e.g. the Java class wizard). Accordingly, please allow me to pitch Abbot and "Abbot for SWT" for use in providing, or at least developing, this feature. The OSS Abbot project http://sourceforge.net/projects/abbot builds upon java.awt.Robot to * automate AWT/Swing UIs * do test-first development of AWT/Swing UIs * automate regression testing of AWT/Swing UIs using robust, refactorable JUnit testcases and suites Abbot also provides a record/play capability, enabling more rapid development of testcases and suites for existing code, as well as basic blackbox-style testing. For more detail, see this recent JDJ article: http://www.sys-con.com/java/articleprint.cfm?id=1940 as well as the documentation available from the Abbot site. "Abbot for SWT" https://w3.opensource.ibm.com/projects/abbotforswt/ is an Eclipse plugin which seeks to extend Abbot ... for SWT (but you guessed :-) Since abbotforswt currently includes Abbot, and our intent is to contribute abbotforswt back to Abbot, an appropriate automation API would allow a user to automate either a SWT or an AWT/Swing UI. To demonstrate abbotforswt's feasibility, we have taken scenario 2 from the JDJ article above, recoded its SUT (a dialog) in SWT, and designed and implemented an API targeting SWT equivalent to Abbot's existing API targeting AWT/Swing. For more details, see our release notes @ http://w3.opensource.ibm.com/project/shownotes.php?release_id=597 Sound interesting? Try it out! However, first note: * abbotforswt is currently available only from the IBM Internal Open Source Bazaar, a "walled garden" version of SourceForge inaccessible outside IBM. * Non-IBMers: please note that our IIOSB residence is intended to be temporary. We are currently in IBM Open Source Steering Committee pre-review, and therefore hope to open our extensions sometime this millenium :-) * IBMers: if you have NOT already completed your "OSPG training," please read the Open Source Participation Guidelines http://ltc.linux.ibm.com/open_source/ospg.html before you check out any code. * We intend to contribute most or all of our extensions back to Abbot, but are open to contributing portions to Eclipse where useful and permissible. * For convenience, abbotforswt contains both Abbot code, which is currently LGPL, and IBM code (developed by my team). If Abbot's LGPL status concerns you, stay away from code in abbotforswt/{src, test}/abbot/*. * Abbot's developer, Timothy Wall, has been very helpful to our project. He is also considering releasing Abbot under CPL. You have 2 installation options. Instructions are for Eclipse/ WebSphere Studio users: 0 Install the release zip. Goto our release page http://w3.opensource.ibm.com/project/showfiles.php?group_id=1023 read the "IMPORTANT NOTICE", then follow the instructions in the release notes http://w3.opensource.ibm.com/project/shownotes.php?release_id=597 Note that you need not register for IIOSB to get the release, but we hope you will, because you're a fine human being. (Apologies for speciesism to all the fine non-human programmers http://www.newtechusa.com/PPI/pressroom.asp#higher out there :-) 1 Install from CVS. This is a good first step toward becoming an abbotforswt contributor! - Run your development workbench (devbench) with either Target Platform pointing to a WSAD build (which is how I tested), or just import org.apache.xerces (should work, but not tested). - Create a new CVS repository location with host=cvs.opensource.ibm.com repository path=/cvs/abbotforswt user=anonymous no password connection type=pserver and check out HEAD/abbotforswt. - Browse to our release notes http://w3.opensource.ibm.com/project/shownotes.php?release_id=597 Search or scroll to "run the demo", and skip to step 4 The demo can then be run in each of 3 ways, all of which are documented in the release notes: * using Test Collector in a launched WebSphere Studio build (For more information on Test Collector, contact Jason Sholl.) * using pde.junit to launch an Eclipse or WS build * using Eclipse's JUnit to launch just the UI HTH, Tom Roche, IBM WebSphere Studio Model2 Tooling
Please note that * Abbot http://sourceforge.net/projects/abbot is available under CPL. * abbotforswt has received all preliminary approvals to OSS (to Abbot), and goes for final approval 27 Jan 04. * a binary plugin for Abbot (AWT/Swing) 0.11.0 is available @ http://prdownloads.sourceforge.net/abbot/abbot-0.11.0-eclipse.zip?download https://w3.opensource.ibm.com/frs/viewRelease.php?release_id=545&group_id=1023 * a binary plugin for abbotforswt (containing our SWT-ized Robot) is @ https://w3.opensource.ibm.com/frs/viewRelease.php?release_id=545&group_id=1023 It prereqs the Abbot plugin. * EA users report success with abbotforswt on both Windows and Linux. (Abbot is widely used on many platforms.)
deferring
What's the difference between this one and bug 37936?
They're similar but not identical. This one is about scripting; bug 37936 is about macros. The technical challenges are very similar for both.
It seems to me, that a remote access api for registered services might be useful for a lot of applications. So, why not decoupling automation from some kind of service management. Maybe it's just an extension of the osgi registry. Maybe there is already a platform to be useful for service managment. Corona project looks to me, like it will produce useful output. Just an idea Holger
This is no longer a plan item.
*** Bug 36163 has been marked as a duplicate of this bug. ***
Recently the EASE project was created within the e4 incubator. it deals with integration of script languages into Eclipse. if there are still people interested in this bug this is a chance to work on this topic.
