However, while both a Time Machine restore and a new OS X Snow Leopard installation ran fine, the disk was not in a bootable state afterwards. This is where I had to learn that these days you need to apply updates to hardware before being able to use it… Bumping the firmware from 3.02 to 3.55 using the firmware updater found at http://www.ocztechnology.com/ssd_tools/OCZ_Vertex_Plus/ did the trick.

Using Disk Utility, burn the Firmware Updater ISO to a CD/DVD, reboot, hold Option until the boot device selection comes up and apply the firmware update. Reboot, and the disk should be working fine.

ScriptEngineManager scriptEngineManager = new ScriptEngineManager();
ScriptEngine scriptEngine = scriptEngineManager.getByName("groovy");

However, in an OSGi-based application, the ScriptEngineManager fails to discover scripting engines located in installed bundles bundles, due to the way () it discovers engines available on the class path. Luckily, the Apache Felix project has already solved this problem, there are

• OSGiScriptEngineManager
• OSGiScriptEngineFactory
• OSGiScriptEngine

which provide an OSGi-compliant way to discover and load scripting engines installed as OSGi bundles.

ScriptEngineManager scriptEngineManager = new OSGiScriptEngineManager(bundleContext);
ScriptEngine scriptEngine = scriptEngineManager.getByName("groovy");

git config http.postBuffer 524288000

Maybe this helps someone else having the same problem.

mvn versions:display-dependency-updates versions:display-plugin-updates

From Maven Versions Plugin.

• Extracts the target platform (Eclipse in this case) and Jubula’s instrumentation plugin
• Deploys the plugins under test into the target platform (simple copy in this case, no p2 installation)
• Runs the Jubula tests usingtestexec
• Collects links to all test results in an index.html file that can be published using the Jenkins HTML Publisher plugin

Prolog

<project name="plugin-test" default="run">
	<!-- Locations -->
	<property name="testdata.dir" value="testdata" />
	<property name="report.dir" value="report/jubula"/>
	<property name="application.dir" value="/tmp/plugin-test/runtime"/>
	<property name="workspace.dir" value="/home/jenkins/.jubula/workspace"/>
	<property name="artifact.dir" value="target"/><!-- Location of plugins under test -->
	<property name="testexec" value="/home/jenkins/jubula/jubula/testexec"/>

	<!-- Derived properties -->
	<property name="deploy.dir" value="${application.dir}/eclipse/plugins"/>
	<property name="report.index" value="${report.dir}/index.html"/>

	<!-- Taskdefs -->
	<taskdef resource="net/sf/antcontrib/antcontrib.properties" classpath="lib/ant-contrib.jar"/>

	<!-- Main target -->
	<target name="run" depends="check, setup, prepare-runtime, deploy, test, report" />

	<target name="check" unless="application.archive" description="Check configuration">
		<fail message="The mandatory property application.archive pointing to a zipped Eclipse runtime is missing"/>
	</target>

	<target name="setup" description="Prepare directories">
		<delete dir="${report.dir}"/>
		<mkdir dir="${report.dir}"/>
		<delete dir="${testdata.dir}"/>
		<mkdir dir="${testdata.dir}"/>
		<delete dir="${application.dir}"/>
		<mkdir dir="${application.dir}"/>
		<mkdir dir="${artifact.dir}"/>
	</target>

Unpack the target runtime, copy instrumentation plugin and deploy plugins under test

	<target name="prepare-runtime" description="Unpack the runtime application to a working directory">
		<!-- Extract Eclipse -->
		<unzip dest="${application.dir}" src="${application.archive}" overwrite="true"/>
		<chmod perm="a+x" file="${application.dir}/eclipse/eclipse"/>
		
		<!-- Extract Jubula instrumentation plugin -->
		<unzip dest="${application.dir}/eclipse" src="${jubula.plugin.archive}" overwrite="true"/>
	</target>

	<target name="deploy" description="Copy all plugins (target/*.jar) directory to the runtime application's plugins directory">
		<copy todir="${deploy.dir}">
			<fileset dir="${artifact.dir}" includes="*.jar"/>
		</copy>
	</target>

Run Jubula tests using testexec

	<target name="test" description="Run the tests using testexec against an autagent">
		<property name="test.project" value="_your project name_"/>
		<property name="test.project.version" value="1.0"/>
		<property name="test.suite" value="_your test suite name_"/>
		<property name="test.aut.config" value="Eclipse_Helios"/>
		<property name="autagent.host" value="localhost"/>
		<property name="autagent.port" value="60000"/>
		<property name="db.scheme" value="_your DB scheme_"/>
		<property name="db.user" value="_your DB user_"/>
		<property name="db.pwd" value="_your DB pwd_"/>

		<exec executable="${testexec}" failonerror="true">
			<arg line='-project ${test.project} -version ${test.project.version} -testsuite ${test.suite}'/>
			<arg line='-server ${autagent.host} -port ${autagent.port} -autconfig ${test.aut.config}'/>
			<arg line='-datadir "${testdata.dir}" -resultdir "${report.dir}"'/>
			<arg line='-data "${workspace.dir}"'/>
			<arg line='-language en_US -dbscheme "${db.scheme}"'/>
			<arg line="-dbuser ${db.user} -dbpw ${db.pwd}"/>
		</exec>
	</target>

Generate index page with links to test results

	<target name="report" description="Create report index HTML page">
		<!-- Find report files -->
		<fileset id="html.fileset" dir="${report.dir}">
		    <include name="*.htm*" />
			<exclude name="index.html"/>
		</fileset>

		<pathconvert pathsep=";" property="html.filelist" refid="html.fileset">
		    <mapper type="flatten" />
		</pathconvert>

		<!-- Create index page header -->
		<echo file="${report.index}">
			&lt;html&gt;&lt;body&gt;&lt;ul&gt;
		</echo>

		<!-- Add links to all files -->
		<foreach list="${html.filelist}" delimiter=";" target="-print-report-link" param="report.file.name"/>

		<!-- Footer -->
		<echo file="${report.index}" append="true">
			&lt;/ul&gt;&lt;/body&gt;&lt;html&gt;
		</echo>
	</target>

	<target name="-print-report-link" description="Print a link to a Jubula report file into the index page">
		<!-- Strip file prefix -->
		<propertyregex input="${report.file.name}" property="report.file.title" regexp="executionLog-" replace=""/>
		<!-- Create file link in list -->
		<echo file="${report.index}" append="true" message="&lt;li&gt;  &lt;a href=${report.file.name}&gt; ${report.file.title}  &lt;/a&gt;  &lt;/li&gt;"/>
	</target>

</project>

While evaluating tools for doing functional tests for an Eclipse Plugin, I wanted to check out how easy it would be to integrate it into our Continuous Integration builds with Jenkins (the CI server formerly known as Hudson). It turned out there were a few pitfalls, but in the end it was pretty straightforward – hopefully this article will save you some time.

To get started, download and install Jubula from the download page. After installation (simply run setup.sh, and install it for example into /home/jenkins/jubula), you’ll have to prepare your target RCP or Eclipse Runtime by extracting rcp-support.zip from the Jubula installation to the RCP Application/Eclipse directory. This contains a plugin that needs to be available in the AUT (Application Under Test) for Jubula to be able to run the tests.

Pitfall: The provided Jubula installation package for Linux includes a 32-bit JRE and SWT in a 32-bit version that is used to run Jubula and its tools. The CI server being a 64-bit machine I had to install quite a few 32-bit shared libraries to get Jubula to run. To find out what libraries are missing, starting Jubula locally on the CI server with the -debug -console -consoleLog options helped. On the CI build server you might get away without this step if all you run locally is the autagent (see below).

Specifying a Test

Jubula comes with quite a good User Manual. For an introduction on how to create your first Jubula test, I’d recommend the excellent series of posts by Joachim.

This post assumes that you have a test project name MyTest with a test suite named AboutDialogTest and AUT configuration named Eclipse_Helios.

Pitfall: Make sure your test specifies either German (Germany) or English (United States) as the keyboard layout (see here). These are the only two keyboard layouts provided out-of-the-box by Jubula at the moment.

Test Executor

Running Jubula from the command line is done using the Test Executor (testexec). It’s command line options are documented here.

If, for example, you’re  testing an Eclipse Plugin, your testexec command line would look something like this:

$JUBULA_HOME/jubula/testexec -project MyTest -version 1.0 -testsuite AboutDialogTest 
-server localhost -port 60000 -autconfig Eclipse_Helios 
-datadir $WORKSPACE/testdata -resultdir $WORKSPACE/testresults
-data /home/jenkins/.jubula/workspace 
-language en_US -dbscheme "Default Embedded (H2)"
-dbuser sa -dbpw ""

This is using the default embedded database scheme. In a production environment, you’ll typically use a real database that is available to both testers specifying tests and the build server. Available DB schemes are configured in Jubula under Window/Preferences/Test/Database Connections. The -data parameter points to the workspace directory where the database configuration is stored. So you’ll have to either edit this locally on the server, or copy the workspace over to the server to somewhere Jenkins can see it.

The test executor can be configured to either

• Start a new AUT instance as shown above with the -autconfig parameter
• Connect to a running AUT instance that has been started using the -autid parameter

You can also pass all these options via a configuration file instead of command line parameters should you prefer.

AUT Agent

Before running the Test Executor, you’ll have to start the AUT Agent (Jubula daemon providing the bridge between the test executor and the Application Under Test) first.

The AUT agent can be started with

$JUBULA_HOME/server/autagent -p 60000 -v

• -p: Port
• -v: Verbose mode

As this this an UI test, the agent is started under X11. I haven’t yet explored the possibilities of running the AUT without having an active X11 session. Our CI server has an active X11 session all the time for driving an Extreme Feedback Panel anyways.

Pitfall: The AUT agent seems to accept only a single connection at a time, the test executor can’t connect to it while Jubula is still connected to the same AUT Agent.

Configuring Jenkins

1.) Create a new Job

2.) Add a step for creating necessary directories, and a step to run testexec

Note: The shell commands are just provided as an example. In a real job you would most probably replace this with something like an Ant script to prepare the environment, auto-deploy your plugin or the whole RCP application, run the the tests and then check the return code from testexec. Edit: This has been documented here

3.) Run the job

4.) Check out the results

The generated HTML report will look something like this:

Possible Job Improvements

• Auto-deploy plugin and/or RCP runtime
• Connect to a real database instead of the embedded Jubula instance
• This is simply a matter of configuring a new database in the workspace pointed to by the -data parameter (see above), and setting the -dbscheme parameter to the name of the DB configuration.
• Show screenshots taken by Jubula upon test failures directly in the test report
• This is currently only possible inside Jubula’s test result perspective. Would be nice to have the screenshot embedded into the HTML reports.

• Fixed class loading issues in standalone mode
• Added XPathAlternativesRequestIdProvider
• Added Tibco EMS connection factory provider
• Provide (default) option to not persist request history
• Show more request history entries in table
• Added replace option to import/export dialog
• Request History: Added timing informations
• Added environment replacement properties to settings
• Configurable amount of JMS consumers
• API supports request timestamp retrieval

Get it from http://code.google.com/p/masqueradesim/downloads/list

• You live in Europe and the UK mirror is faster for your
• repo1.maven.org is experiencing troubles

It was only yesterday when repo1.maven.org was down that I learned how to configure mirrors for Maven: Simply add the few lines below to your .m2/settings.xml:

<settings>
  ...
  <mirrors>
    <mirror>
      <id>UK</id>
      <name>UK Central</name>
      <url>http://uk.maven.org/maven2</url>
      <mirrorOf>central</mirrorOf>
    </mirror>
  </mirrors>
  ...

Service stubs can easily be implemented using Masquerade. Simply run Masquerade standalone using its embedded Jetty server or deploy it to an application server (e.g. Tomcat) of your choice, and configure your simulations using its web interface.

Service simulation is useful for example when

• Providing a service stub for integration or regression tests
• Doing functional tests against a system that is not (yet) available
• Providing a stub for functionality that is yet to be implemented in an agile project

Supports the following request listener channels in this first release:

• HTTP (using the servlet container and standalone on different port)
• JMS (queue/topic, connection factories for WSMQ and ActiveMQ included)
• File
• FTP

Contains simulation actions for various request/response scenarios, while quite a few of them support XML, any kind of response can be simulated. Response simulations are based on simulation scripts that contain actions such

• Template-based response
• Adding content to the response
• Groovy script step
• Ruby script step
• Java Script step
• Synchronous/asynchronous responses
• Wait step
• Variable management and substitution steps
• XML transformation steps

The simulator also provides an API to query for received requests (useful when asserting request contents in integration tests), and to specifiy expected responses externally before issuing requests.

The Source code repo is at https://github.com/matf/masquerade.

http://www.jorambarrez.be/blog/2011/04/28/howto-vaadin-addon-maven/

Our continuous integration turnaround time for Vaadin projects has dropped to a few seconds without the GWT compiler overhead, really helpful!