8. December, 2014
If you see this error while running the code from Eclipse, check the .classpath file for this line:
<classpathentry exported="true" kind="con" path="GROOVY_SUPPORT"/>
In this case, Eclipse adds version 2.1.8 to the classpath and Maven adds 2.1.9. At runtime, Groovy detects both versions and aborts since this will cause subtle bugs.
Solution: Delete the line above in the .classpath file.
If you see a line which contains GROOVY_DSL_SUPPORT, then you can leave that in – the Groovy plugin will use the JARs which Maven adds to the classpath.
3. November, 2014
RCP Testing Tool (RCPTT) is an Open Source tool for UI testing of Eclipse-based applications. During the demo by Ivan Inozemtsev, I got the impression that they thought of everything:
- There is a recorder so you can quickly create a test case by clicking thought the application
- There is an assertion builder where you can say “this element should be red”, “this checkbox needs to be checked”, “this image must be visible”
- There is special support for all kinds of widgets like text editors where “position” is row/column (i.e. cursor position) instead of mouse coordinates or character offsets. The test API allows for checks like “is styled like a keyword”.
- If the UI is resized after the tests have been recorded, the tool will try to calculate the relative click point. Unless the UI element is special (like a graph editor) where it has different heuristics (like when you clicked in an empty area but now, there is something below at the coordinate). If everything else fails, the testing tool will try to resize the UI element to the recorded size.
- There is a compact, extensible DSL to describe the test cases. The DSL supports procedures so you can reuse test code.
The tool was fast and stable during the demo. It could reset Eclipse’s workspace to a certain state (open perspective, open editors, open projects) – I’m currently thinking about using it to create the default workspace for our development team.
One more things from the demo: Black box testing is a myth or at least a dream. A testing tool for anything complex needs to know internal details (like Eclipse’s background jobs). Otherwise the tests will either fail randomly when some background job didn’t complete in time or they will be slow (since each of them will be sprinkled with “WAIT 1 MINUTE” instructions) or they will be sprinkled with application specific “wait” instructions.
3. November, 2014
The last two talks were about testing.
“Automating user interface tests with behavior-driven development (BDD)” by Jose Badeau and Dietmar Stoll used an Xtext-based DSL to connect requirements, wireframes and test descriptions so they can validate each other. In the example, they removed a field from the wireframe mockup and the Eclipse editor for the test cases showed errors where they were used in the DSL.
The demo showed once again how much power lies in connecting information from different sources. If you remember, then this was the key feature which set Eclipse apart from all the other Java tools in 2001: It could bring you to the place where something was defined by pressing F3 or Ctrl+Click. If you changed one file, it would instantly compile all the other files and show you any problems it would find. Having a tool which actively searches for problems saved and still saves a lot of time.
3. November, 2014
Thomas Schuetz from Protos Software showed some surprising similarities between embedded and finance systems: Both need to run a long period of time without human interaction, they shouldn’t show “odd” behavior, and you can’t simply shut them down to look for a bug.
Granted, lives are much less at risk when a financial software crashes (as opposed to, say, a pacemaker). So at first glance, the strict safety rules which apply to embedded systems seem too strict for financial software. But safety is built on top of reliability. And we very much want reliability in any system we build.
An important tool here is tracing. Tracing is the pedantic brother of logging. The goal is to collect enough data to simulate the state of the system at any point in time.
In a demonstration, he showed a demo for project eTrice. In a mix of a textual and UI editors, he created a simple application with two objects that could send data back and forth. Since everything is based on EMF, changes on one side are immediately reflected on the other. As a free bonus, you get a sequence diagram of the whole process by clicking a button after the application has finished.
3. November, 2014
Etienne Juliot from Obeo, demonstrated Sirius, a tool to create your own modeling tools in Eclipse. Under the hood, the new UI editors work on EMF models. If you struggled with EMF (and it’s … uh … “basic” set of default editors), you should definitely have a look.
The tools also work well with Xtext, so you have a mix of textual (detail) and graphical editors (overview) in your product. The magic sauce in EMF makes sure that updates on one side propagate to the other.
6. August, 2012
If you’re like me, then you’re spending a lot of time using console windows because some tasks are just so much more efficient (recalling old commands, pipes, …). If you use Eclipse, you will always struggle to squeeze the terminal window on the screen somewhere.
To help with this situation, Google has developed a plug-in to embed a command-line terminal into your workspace: ELT
It currently supports Linux (x86 32 and 64 bit) and Mac OS X (PPC, x86 32 and 64 bit) only. ANSI escape sequences (incl. color codes) are supported as well a hyperlinks.
20. July, 2012
When a project is young and dashing, mistakes are made. The PDE build process is such a mistake. If you ever tried to build Eclipse (or at least some of the older parts), then you know that this is brittle and the error messages are more like mysterious ramblings of an angry deity than helpful.
Enter stage CBI. From the FAQ:
The CBI build of the Eclipse platform is intended to produce the same output as the PDE build, and thus facilitate packaging without noticeable change. The noticeable difference the CBI build of the platform makes is ease of use to build the platform. For example, the prototype has consistently demonstrated that a newcomer without prior experience can build the Eclipse platform with under 30 minutes of effort on a machine with a supported JDK & Maven.
What can I say?