If you ever wondered if RAP runs on the iPad, the answer is now YES. We fixed a number of iPad-related bugs for 1.4M2, and now it runs (almost) trouble-free. You can even start your RAP-application in fullscreen, making it look more like a native app. See for yourself with this video:
Well summer is finally over (Autumn is almost officially here), but it doesn’t mean that everyone has been slacking. Over the past few months the Eclipse Platform team managed to ship Helios (on time of course), ship Eclipse 4.0 (Early Adopter Release), and start-up the Eclipse 3.7 (Indigo) work. In fact, Milestone 1 shipped over a month ago, and now Eclipse 3.7 Milestone 2 is here.
There are a few new goodies like wrappable buttons:
Compare editor improvements:
And performance improvements to the way p2 sites are managed by the target definition editor.
You can download Eclipse 3.7 M2 from: http://download.eclipse.org/eclipse/downloads/drops/S-3.7M2-201009152024/index.php
or point p2 at the update site: http://download.eclipse.org/eclipse/updates/3.7milestones
Terracotta is a transparent clustering service that allows multiple Java processes on different JVMs to work together using pure objects and threading logic. Here’s how you can use it with Equinox.
Prerequisites: An installation of Java 1.6.0u20 or later (Java SE Downloads) and Terracotta (Open Source Option) Terracotta Download..
Install the downloaded Terracotta:
> tar xvfz terracotta-3.3.0.tar.gz > export TC_HOME=/opt/tools/terracotta-3.3.0
We wan’t Terracotta to integrate with Equinox. This is where Terracotta Integration Modules come into play:
Terracotta Integration Modules (TIMs) are sets of configuration elements and supporting Java classes packaged together as a single, includable module within the Terracotta configuration. A TIM allows you to integrate Terracotta DSO with the framework or platform that your application is based on.[1]
Let’s look how to include the TIM for Equinox 3.5.1 in the Terracotta configuration file $TC_CONFIG_HOME/tc-config.xml:
We create our own tc-config.xml in $TC_CONFIG_HOME based on a Terracotta sample configuration $TC_HOME/platform/samples/tc-config.xml. Add this snippet to the basic sample config:
Use the Terracotta helper tim-get.sh to install the TIM locally…
> $TC_HOME/bin/tim-get.sh install tim-equinox-3.5.1 1.2.0 Terracotta 3.3.0, as of 20100716-150712 (Revision 15922 by cruise@su10mo5 from 3.3) Installing tim-equinox-3.5.1 1.2.0... INSTALLED: tim-equinox-3.5.1 1.2.0 - Ok
Done. (Make sure to update your tc-config.xml with the new/updated version if necessary)
Now that we’ve configured the Equinox integration it’s time to tell Terracotta about our counter, a POJO:
public class Counter { private AtomicInteger counter; public int inc() { return counter.incrementAndGet(); } public int getCurrentCounter() { return counter.intValue(); } }
Our Terracotta ‘application’ configuration holds the simple root object (graph) : A “root” is the top of a clustered object graph as declared in the Terracotta configuration.[2]
com.eclipsesource.sovereign.terracotta.counter..*
com.eclipsesource.sovereign.terracotta.counter.Counter.counterLast we need a so called Terracotta “boot JAR”:
Some classes, however, are loaded too early in the lifecycle of the JVM for Terracotta to hook into their loading process. These are classes that are loaded by the boot classloader. Such classes cannot be instrumented at classload time, but must be pre-instrumented and placed in a special JAR file that is then prepended to the boot classpath.[2]
This is done with a Non-Standard Option of the JVM [3]
-Xbootclasspath/p:${TC_CONFIG_HOME}/boot JAR.jar
> $TC_HOME/platform/bin/make-boot-jar.sh -f $TC_CONFIG_HOME/tc-config.xml 2010-09-09 15:11:15,446 INFO - Terracotta 3.3.0, as ... ... 2010-09-09 15:11:27,456 INFO - Successfully created boot JAR file at ... > cp $TC_HOME/lib/dso-boot/dso-boot*jar $TC_CONFIG_HOME
Enough installation and configuration. Engage! We need a running Terracotta server instance.
Terracotta server instances together form a Terracotta server array, which is the heart of a Terracotta cluster. Each Terracotta server instance performs two basic functions:[2]
> $TC_HOME/bin/start-tc-server.sh -f $TC_CONFIG_HOME/tc-config.xml 2010-09-09 15:34:42,370 INFO - Terracotta 3.3.0, as of ... 2010-09-09 15:34:55,915 INFO - Terracotta Server instance has started up... successfully, and is now ready for work.
What’s a server without a client? We fire up the Equinox client with Pax Runner with some additional JAVA_OPTS:
> export JAVA_OPTS=-Dtc.install-root=${TC_HOME} -Dtc.config=${TC_CONFIG_HOME}/tc-config.xml -Xbootclasspath/p:${TC_CONFIG_HOME}/dso-boot-hotspot_linux_160_21.jar
One configuration file contains our counter OSGi bundle etc/counter-demo.pax:
mvn:com.eclipsesource.sovereign/terracotta.counter/0.1.0-SNAPSHOT
The second specifies platform, version, inProcess executor, bootDelegation, …
--platform=equinox --version=3.5.1 --executor=inProcess --bootDelegation=sun.*,com.sun.*,javax.xml.*,javax.xml.transform.*,... --systemPackages=javax.naming, javax.naming.directory, javax.naming.spi, ...
>$PAX_RUNNER_HOME/bin/pax-run.sh etc/counter-demo.pax --args=file:etc/runner.args 2010-09-09 17:14:23,435 INFO - Terracotta 3.3.0, as of 20100716-150712 (Revision 15922 by cruise@su10mo5 from 3.3) 2010-09-09 17:14:24,794 INFO - Successfully loaded base configuration from file at... 2010-09-09 17:14:30,101 INFO - Connection successfully established to server at ... __________ __________ \______ \_____ ___ ___ \______ \__ __ ____ ____ ___________ | ___/\__ \ \ \/ / | _/ | \/ \ / \_/ __ \_ __ \ | | / __ \_> < | | \ | / | \ | \ ___/| | \/ |____| (____ /__/\_ \ |____|_ /____/|___| /___| /\___ >__| \/ \/ \/ \/ \/ \/ Pax Runner (1.4.0) from OPS4J - http://www.ops4j.org ---------------------------------------------------- ...
Review the first lines showing that the Terracotta client successfully estalished it’s connection to the server. If those lines are missing please double check the path to your “boot JAR”.
We added some OSGi commands to interact with our clustered POJO counter:
osgi> help ... ---Sovereign counter commands--- inc - increment the global counter currentValue - show current counter value
osgi> inc 4 osgi> currentValue 4
Start another application and have fun with the clustered counter….
Sources:
[1] Terracotta Integration Modules Manual
[2] Concept and Architecture Guide
[3] Java SE Documentation – Java – the Java application launcher
Sometimes functional tests fail. If they do, I not only want to see the test and the error message, I also want a screenshot of the application in the state during the failing test.
I was astonished to find nothing in the SWTBot code or documentation that suggests how to automatically capture a screenshot when a SWTBot test fails. This is why I came up with a JUnit4 Rule that does this.
In your SWTBot test class include the field
public class MyTest {
@Rule
public CaptureScreenshotOnFailure screenshot = new CaptureScreenshotOnFailure();
@Test public void mytestmethod() {
SWTBot bot = new SWTBot(...);
// swtbot clicks and types
}
So, if now mytestmethod fails, a screenshot will be put in the current directory with the name mypackage.MyTest.mytestmethod.png
This is the rule, put it somewhere where your test classes can access it:
import org.eclipse.swtbot.eclipse.finder.SWTWorkbenchBot;
import org.junit.rules.MethodRule;
import org.junit.runners.model.FrameworkMethod;
import org.junit.runners.model.Statement;
public class CaptureScreenshotOnFailure implements MethodRule {
public final Statement apply(final Statement base,
final FrameworkMethod method, Object target) {
return new Statement() {
@Override
public void evaluate() throws Throwable {
try {
base.evaluate();
} catch (Throwable onHold) {
String fileName = constructFilename(method);
new SWTWorkbenchBot().captureScreenshot(fileName);
throw onHold;
}
}
private String constructFilename(final FrameworkMethod method) {
return "./"
+ method.getMethod().getDeclaringClass()
.getCanonicalName() + "."
+ method.getName() + ".png";
}
};
}
}
I think this makes writing tests with SWTBot more comfortable. Do you see ways to improve this rule?
During RCP application development the creation and maintenance of a Test Suite is a common annoyance. While solutions exist that we can live with, the current state of test suites is ennoyance enough that it was a topic for a talk at the Eclipse Testing day recently. Further down I’m presenting a way to create Test Suites that overcome most problems of the presented methods. But before that, I’ll discuss a bit background knowledge.
Good test suites
One way to create dynamic test suites is the ClassPathSuite. It goes through the classpath and adds all tests it can find to a test suite which is then executed. This approach has two problems that both come from loading all classes before inspecting them:
For OSGi applications there is another way to create a test suite dynamically, thats the BundleTestCollector from Patrick Paulin. It is a similar approach in that it goes through specified bundles and adds classes to a test suite, but has neither of the above drawbacks
Sounds almost perfect, doesn’t it? Hold your breath, it has some problems, too, but they are small against everything else I stumbled across.
First, Patricks version only works with JUnit 3. I used a modified version for a while now that works with JUnit 4 and has some more assertions than Patricks original version. The remaining problem is, when looking at the test results in the JUnit view, the stack trace is not linked to the workspace. A double-click fails, and I need to open the class and navigate to the line by hand.
The BundleTestCollector requires OSGi Bundles. You can’t just run it as JUnit test. In your IDE it must be started as PDE Test (or SWTBotTest), and in the continuous integration, you should use the Eclipse Testing Framework or the SWTBot test runners.
Patrick published his version of the BundleTestCollector under the EPL, so my modifications are EPL, too. Here is a zip containing the BundleTestCollector and it’s single dependency, an Activator. You’ll have to copy them into an actual bundle and adjust the namespace. JUnit4 must be on the bundle dependency path.
The BundleTestCollector picks up the tests by naming conventions. If your test doesn’t adhere to a naming convention, it won’t be picked up.
Here is how to define a TestSuite. It’s still a JUnit 3 test suite, but the actual tests may be both, JUnit 3 or JUnit 4.
public class MyTestSuite extends TestSuite {
public static Test suite() {
BundleTestCollector testCollector = new BundleTestCollector();
TestSuite suite = new TestSuite( "All Tests" );
testCollector.collectTests(suite, "my.bundle.namespace", "my.package.namespace", "*Test");
// add more lines collectTests(...) calls if necessary
return suite;
}
}
Hope that eases some of your test suite maintenance pains.
First, they are all Eclipse projects. But I think you already knew this. The second thing they have in common is that they are all part of the Eclipse Stammtisch on September 15th in Karlsruhe (Germany). It’s an honor to announce that all these projects will be presented by top developers who play an important role in their projects. I would believe that until the Eclipse Summit Europe this will be the last chance to hear this many first class talks. If you are in or around Karlsruhe on September 15th feel free to join us and take the opportunity to see all the mentioned technologies in action.
Who’s speaking at the Stammtisch?
How much does it cost?
What do you have to do to attend the Stammtisch?
I think this will be a unique opportunity to see these talks in the casual atmosphere of a Stammtisch. Thanks in advance to all speakers for agreeing to participate and for making this evening possible. It’s a great honor to have you all in Karlsruhe.
After the talks we will all go over to a small Italian restaurant and talk about the topics over a frosty beverage. You are free to join this round and network with the speakers and audience. If you’re not able to attend the Stammtisch you also have a second chance. I think all of the speakers submitted a proposal for the Eclipse Summit Europe. You can attend this event by following the steps described here.
Looking forward to meeting you at the Stammtisch. I will also be there and try to answer questions about RAP
If anybody is going to be in Dublin next Thursday (Sept 9th), I’ll be talking about OSGi, Software Modularity and Single Sourcing. Details of the event can be found here. If anybody is going to be in the area, let me know. I’d love to catch up with some Eclipse folks over a few frosty beverages.
I know Eclipse ‘Help’ is not a very exciting topic, but today I found myself working with a little known secret of Help. Most people know that you can setup context sensitive help (Press F1 and bring up help for the specific workbench part under focus). However, did you now you do the opposite? That is, activate code in your RCP application from a link in Help?
Here’s the use case: Say you have created a chat client built on the Eclipse RCP Platform. Like any good software engineer, you’ve created extensive help content. In addition to Instructions, you want to provide links that actually open the dialogs, or perform the actions. Active Help is the solution.
In this example, I’ve added a link that opens the “Add Contact” dialog, directly from the “Adding a Contact” Help page.
Doing this is extremely simple too. On the Java side, you simply need to implement the ILiveHelpAction. Then, on the help side you simply add the following JavaScript to your help contents:
<a href='javascript:liveAction( "org.eclipsercp.hyperbola", "org.eclipsercp.hyperbola.ActiveHelpOpenDialogAction", "")'>Click here for a Message.</a>
The only thing to keep in mind is that the Action is not executed on the UI thread, so you may need to synchronize this yourself.
(18) (4) (120) (57) (8) (54) (119) (35) (8) (10) (17) (10) (12) (7) (14) (3) (20) (5)