My new book on TDD, Build Automation and Continuous Integration

2 Replies

I haven’t been blogging for some time now. I’m getting back to blogging by announcing my new book on TDD (Test-Driven Development), Build Automation and Continuous Integration.

The title is indeed, “Test-Driven Development, Build Automation, Continuous Integration
(with Java, Eclipse and friends)” and can be bought from https://leanpub.com/tdd-buildautomation-ci.

The main goal of the book is to get you started with Test-Driven Development (write tests before the code), Build Automation (make the overall process of compilation and testing automatic with Maven) and Continuous Integration (commit changes and a server will perform the whole build of your code). Using Java, Eclipse and their ecosystems.

The main subject of this book is software testing. The main premise is that testing is a crucial part of software development. You need to make sure that the software you write behaves correctly. You can manually test your software. However, manual tests require lots of manual work and it is error prone.

On the contrary, this book focuses on automated tests, which can be done at several levels. In the book we will see a few types of tests, starting from those that test a single component in isolation to those that test the entire application. We will also deal with tests in the presence of a database and with tests that verify the correct behavior of the graphical user interface.

In particular, we will describe and apply the Test-Driven Development methodology, writing tests before the actual code.

Throughout the book we will use Java as the main programming language. We use Eclipse as the IDE. Both Java and Eclipse have a huge ecosystem of “friends”, that is, frameworks, tools and plugins. Many of them are related to automated tests and perfectly fit the goals of the book. We will use JUnit throughout the book as the main Java testing framework.

it is also important to be able to completely automate the build process. In fact, another relevant subject of the book is Build Automation. We will use one of the mainstream tools for build automation in the Java world, Maven.

We will use Git as the Version Control System and GitHub as the hosting service for our Git repositories. We will then connect our code hosted on GitHub with a cloud platform for Continuous Integration. In particular, we will use Travis CI. With the Continuous Integration process, we will implement a workflow where each time we commit a change in our Git repository, the CI server will automatically run the automated build process, compiling all the code, running all the tests and possibly create additional reports concerning the quality of our code and of our tests.

The code quality of tests can be measured in terms of a few metrics using code coverage and mutation testing. Other metrics are based on static analysis mechanisms, inspecting the code in search of bugs, code smells and vulnerabilities. For such a static analysis we will use SonarQube and its free cloud version SonarCloud.

When we need our application to connect to a service like a database, we will use Docker a virtualization program, based on containers, that is much more lightweight than standard virtual machines. Docker will allow us to

configure the needed services in advance, once and for all, so that the services running in the containers will take part in the reproducibility of the whole build infrastructure. The same configuration of the services will be used in our development environment, during build automation and in the CI server.

Most of the chapters have a “tutorial” nature. Besides a few general explanations of the main concepts, the chapters will show lots of code. It should be straightforward to follow the chapters and write the code to reproduce the examples. All the sources of the examples are available on GitHub.

The main goal of the book is to give the basic concepts of the techniques and tools for testing, build automation and continuous integration. Of course, the descriptions of these concepts you find in this book are far from being exhaustive. However, you should get enough information to get started with all the presented techniques and tools.

I hope you enjoy the book 🙂

How to install Linux on a USB drive using Virtualbox

3 Replies

In this tutorial I’m going to show how to install Linux on a USB drive using Virtualbox. I find this useful to test a LInux distribution. Note that using a live distribution only allows you a small testing experience, while installing Linux on a USB drive will give you the full experience (and if the USB drive is fast it’s almost like using Linux on a standard computer).

You can use this procedure to install Linux on any USB drive, that is, both a USB stick or an external USB hard drive.

You could burn a live image on a USB stick, boot it, and then install Linux on a second USB stick from the live system, but using Virtualbox is faster and does not require you to create a live USB stick just to install it on a second USB stick.

I’m going to use Ubuntu (17.10) as the main system and install Fedora on a USB stick (I’ve already downloaded the 27 iso).

First of all, let’s install Virtualbox:

sudo apt install virtualbox virtualbox-guest-additions-iso virtualbox-ext-pack

1	sudo apt install virtualbox virtualbox-guest-additions-iso virtualbox-ext-pack

Add your user to the Virtualbox users, or you won’t be able to use USB 3 in the virtual machine: run this command and reboot:

sudo usermod -aG vboxusers ${USER}

1	sudo usermod -aG vboxusers ${USER}

Then run Virtualbox and create a new Linux machine (increase the memory a bit, depending on your actual physical memory).

Since we’ll use this machine only for booting the live iso, there’s no need to create a disk

Now let’s go to Settings of the newly created machine, and in “USB” select USB 3.0:

In “Storage” select the “Empty” disk icon and in “Optical Drive” “Choose a virtual optical disk file…” and select the iso image of the Live distribution you want to boot the machine (in my case the Fedora 27 ISO I’ve already downloaded), then check the “Live CD/DVD” checkbox

Now “Start” the virtual machine (which will boot the Live ISO).

You’ll be asked to confirm the virtual optical disk file you had previously specified in the settings.

From now on, you’ll boot the live system into the virtual machine, and this depends on the distribution you choose (in my case Fedora). You should be already familiar with that procedure if you’ve installed a Linux distribution before starting with a Live system.

For example, we choose “Try Fedora” and we can perform some tests (for instance, that we can access the Internet from the virtual machine; being able to access the Internet might be crucial later when installing the distribution on the USB stick since the installation might want to download some upgrades).

Now let’s connect the USB stick where we want to install Linux; then in the Devices menu of the Virtualbox machine, you should select the USB stick you’ve just inserted (in my case it’s a SanDisk):

Now the USB stick is mounted in the virtual machine, and it will be the target disk of our installation.

We can now start the Fedora installation in the virtual machine; again, this assumes you’re familiar with the installation of this distribution. The important part will be to select the USB stick as the target of the installation. Actually, the USB stick should be the only available option (unless you manually mounted other drives in the virtual machine):

Continue the installation and once it’s done, you can reboot the computer and make sure to boot from the USB stick.

Enjoy your new Linux installation on the USB stick 🙂

Eclipse tested with a few Gnome themes

Analyzing Eclipse plug-in projects with Sonarqube

1 Reply

In this tutorial I’m going to show how to analyze multiple Eclipse plug-in projects with Sonarqube. In particular, I’m going to focus on peculiarities that have to be taken care of due to the standard way Sonarqube analyzes sources and to the structure of typical Eclipse plug-in projects (concerning tests and code coverage).

The code of this example is available on Github: https://github.com/LorenzoBettini/tycho-sonarqube-example

This can be seen as a follow-up of my previous post on “Jacoco code coverage and report of multiple Eclipse plug-in projects. I’ll basically reuse almost the same structure of that example and a few things. The part of Jacoco report is not related to Sonarqube but I’ll leave it there.

The structure of the projects is as follows:

Each project’s code is tested in a specific .tests project. The code consists of simple Java classes doing nothing interesting, and tests just call that code.

The project example.tests.parent contains all the common configurations for test projects (and test report, please refer to my previous post on “Jacoco code coverage and report of multiple Eclipse plug-in projects for the details of this report project, which is not strictly required for Sonarqube).

This is its pom

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>example</groupId>
    <artifactId>example.parent</artifactId>
    <version>0.0.1-SNAPSHOT</version>
  </parent>

  <artifactId>example.tests.parent</artifactId>
  <packaging>pom</packaging>

  <properties>
    <!-- this will be overridden in jacoco profile with tycho.testArgLine, 
      which, in turn, will be set by Jacoco prepare-agent goal. This property can 
      then be used in argLine for custom tycho-surefire configuration, both when 
      Jacoco is used and when it is not used. -->
    <additionalTestArgLine></additionalTestArgLine>
    <jacoco-version>0.7.9</jacoco-version>
  </properties>

  <profiles>
    <profile>
      <id>jacoco</id>
      <activation>
        <activeByDefault>false</activeByDefault>
      </activation>
      <properties>
        <!-- This will be set by Jacoco prepare-agent goal -->
        <additionalTestArgLine>${tycho.testArgLine}</additionalTestArgLine>
      </properties>
      <build>
        <plugins>
          <plugin>
            <groupId>org.jacoco</groupId>
            <artifactId>jacoco-maven-plugin</artifactId>
            <version>${jacoco-version}</version>
            <configuration>
              <excludes>
                <exclude>**/plugin1/Main.class</exclude>
              </excludes>
            </configuration>
            <executions>
              <execution>
                <goals>
                  <goal>prepare-agent</goal>
                </goals>
              </execution>
            </executions>
          </plugin>
        </plugins>
      </build>
    </profile>
  </profiles>

</project>

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

<groupId>example</groupId>

<artifactId>example.parent</artifactId>

<version>0.0.1-SNAPSHOT</version>

</parent>

<artifactId>example.tests.parent</artifactId>

<!-- this will be overridden in jacoco profile with tycho.testArgLine,

which, in turn, will be set by Jacoco prepare-agent goal. This property can

then be used in argLine for custom tycho-surefire configuration, both when

Jacoco is used and when it is not used. -->

<jacoco-version>0.7.9</jacoco-version>

</properties>

<id>jacoco</id>

<activeByDefault>false</activeByDefault>

</activation>

<additionalTestArgLine>${tycho.testArgLine}</additionalTestArgLine>

</properties>

<build>

<groupId>org.jacoco</groupId>

<artifactId>jacoco-maven-plugin</artifactId>

<version>${jacoco-version}</version>

<exclude>**/plugin1/Main.class</exclude>

</excludes>

</configuration>

<goals>

<goal>prepare-agent</goal>

</goals>

</execution>

</executions>

</plugin>

</plugins>

</build>

</profile>

</profiles>

</project>

Note that this also shows a possible way of dealing with custom argLine for tycho-surefire configuration: tycho.testArgLine will be automatically set the jacoco:prepare-agent goal, with the path of jacoco agent (needed for code coverage); the property tycho.testArgLine is automatically used by tycho-surefire. But if you have a custom configuration of tycho-surefire with additional arguments you want to pass in argLine, you must be careful not to overwrite the value set by jacoco. If you simply refer to tycho.testArgLine in the custom tycho-surefire configuration’s argLine, it will work when the jacoco profile is active but it will fail when it is not active since that property will not exist. Don’t try to define it as an empty property by default, since when tycho-surefire runs it will use that empty value, ignoring the one set by jacoco:prepare-agent (argLine’s properties are resolved before jacoco:prepare-agent is executed). Instead, use another level of indirection: refer to a new property, e.g., additionalTestArgLine, which by default is empty. In the jacoco profile, set additionalTestArgLine referring to tycho.testArgLine (in that profile, that property is surely set by jacoco:prepare-agent). Then, in the custom argLine, refer to additionalTestArgLine. An example is shown in the project example.plugin2.tests pom:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>example</groupId>
    <artifactId>example.tests.parent</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <relativePath>../example.tests.parent</relativePath>
  </parent>

  <artifactId>example.plugin2.tests</artifactId>
  <packaging>eclipse-test-plugin</packaging>

  <build>
    <plugins>
      <plugin>
        <groupId>org.eclipse.tycho</groupId>
        <artifactId>tycho-surefire-plugin</artifactId>
        <version>${tycho-version}</version>
        <configuration>
          <!-- additionalTestArgLine is set in the parent project with the 
            Jacoco agent when the jacoco profile is active (and it will be empty when 
            jacoco profile is not active). This way, you can customize argLine without 
            overwriting the jacoco agent set by jacoco:prepare-agent. -->
          <argLine>${additionalTestArgLine} -DbuildingWithTycho=true</argLine>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

<groupId>example</groupId>

<artifactId>example.tests.parent</artifactId>

<version>0.0.1-SNAPSHOT</version>

<relativePath>../example.tests.parent</relativePath>

</parent>

<artifactId>example.plugin2.tests</artifactId>

<packaging>eclipse-test-plugin</packaging>

<build>

<groupId>org.eclipse.tycho</groupId>

<artifactId>tycho-surefire-plugin</artifactId>

<version>${tycho-version}</version>

<!-- additionalTestArgLine is set in the parent project with the

Jacoco agent when the jacoco profile is active (and it will be empty when

jacoco profile is not active). This way, you can customize argLine without

overwriting the jacoco agent set by jacoco:prepare-agent. -->

<argLine>${additionalTestArgLine} -DbuildingWithTycho=true</argLine>

</configuration>

</plugin>

</plugins>

</build>

</project>

You can check that code coverage works as expected by running (it’s important to verify that jacoco has been configured correctly in your projects before running Sonarqube analysis: if it’s not working in Sonarqube then it’s something wrong in the configuration for Sonarqube, not in the jacoco configuration, as we’ll see in a minute):

mvn clean verify -Pjacoco

1	mvn clean verify -Pjacoco

Mare sure that example.tests.report/target/site/jacoco-aggregate/index.html reports some code coverage (in this example, example.plugin1 has some code uncovered by intention).

Now I assume you already have Sonarqube installed.

Let’s run a first Sonarqube analysis with

mvn clean verify -Pjacoco sonar:sonar

1	mvn clean verify -Pjacoco sonar:sonar

This is the result:

So Unit Tests are correctly collected! What about Code Coverage? Something is shown, but if you click on that you see some bad surprises:

Code coverage only on tests (which is irrelevant) and no coverage for our SUT (Software Under Test) classes!

That’s because jacoco .exec files are by default generated in the target folder of the tests project, now when Sonarqube analyzes the projects:

it finds the jacoco.exec file when it analyzes a tests project but can only see the sources of the tests project (not the ones of the SUT)
when it analyzes a SUT project it cannot find any jacoco.exec file.

We could fix this by configuring the maven jacoco plugin to generate jacoco.exec in the SUT project, but then the aggregate report configuration should be updated accordingly (while it works out of the box with the defaults). Another way of fixing the problem is to use the Sonarqube maven property sonar.jacoco.reportPaths and “trick” Sonarqube like that (we do that in the parent pom properties section):

    <!-- Always refer to the corresponding tests project (if it exists) otherwise 
      Sonarqube won't be able to collect code coverage. For example, when analyzing 
      project foo it wouldn't find code coverage information if it doesn't use 
      foo.tests jacoco.exec. -->
    <sonar.jacoco.reportPaths>
      ../${project.artifactId}.tests/target/jacoco.exec
    </sonar.jacoco.reportPaths>

<!-- Always refer to the corresponding tests project (if it exists) otherwise

Sonarqube won't be able to collect code coverage. For example, when analyzing

project foo it wouldn't find code coverage information if it doesn't use

foo.tests jacoco.exec. -->

<sonar.jacoco.reportPaths>

../${project.artifactId}.tests/target/jacoco.exec

</sonar.jacoco.reportPaths>

This way, when it analyzes example.plugin1 it will use the jacoco.exec found in example.plugin1.tests project (if you follow the convention foo and foo.tests this works out of the box, otherwise, you have to list all the jacoco.exec paths in all the projects in that property, separated by comma).

Let’s run the analysis again:

OK, now code coverage is collected on the SUT classes as we wanted. Of course, now test classes appear as uncovered (remember, when it analyzes example.plugin1.tests it now searchs for jacoco.exec in example.plugin1.tests.tests, which does not even exist).

This leads us to another problem: test classes should be excluded from Sonarqube analysis. This works out of the box in standard Maven projects because source folders of SUT and source folders of test classes are separate and in the same project (that’s also why code coverage for pure Maven projects works out of the box in Sonarqube); this is not the case for Eclipse projects, where SUT and tests are in separate projects.

In fact, issues are reported also on test classes:

We can fix both problems by putting in the tests.parent pom properties these two Sonarqube properties (note the link to the Eclipse bug about this behavior)

    <!-- Workaround for https://bugs.eclipse.org/bugs/show_bug.cgi?id=397015 -->
    <sonar.sources></sonar.sources>
    <sonar.tests>src</sonar.tests>

<sonar.sources></sonar.sources>

<sonar.tests>src</sonar.tests>

This will be inherited by our tests projects and for those projects, Sonarqube will not analyze test classes.

Run the analysis again and see the results: code coverage only on SUT and issues only on SUT (remember that in this example MyClass1 is not uncovered completely by intention):

You might be tempted to use the property sonar.skip set to true for test projects, but you will use JUnit test reports collection.

The final bit of customization is to exclude the Main.java class from code coverage. We have already configured the jacoco maven plugin to do so, but this won’t be picked up by Sonarqube (that configuration only tells jacoco to skip that class when it generates the HTML report).

We have to repeat that exclusion with a Sonarqube maven property, in the parent pom:

    <!-- Example of skipping code coverage (comma separated Java files). -->
    <sonar.coverage.exclusions>
      **/plugin1/Main.java
    </sonar.coverage.exclusions>

<sonar.coverage.exclusions>

**/plugin1/Main.java

</sonar.coverage.exclusions>

Note that in the jacoco maven configuration we had excluded a .class file, while here we exclude Java files.

Run the analysis again and Main is not considered in code coverage:

Now you can have fun in fixing Sonarqube issues, which is out of the scope of this tutorial 🙂

This example is also analyzed from Travis using Sonarcloud (https://sonarcloud.io/dashboard?id=example%3Aexample.parent).

Hope you enjoyed this tutorial and Happy new year! 🙂

Formatting Java method calls in Eclipse

2 Replies

Especially with lambdas, you may end up with a chain of method calls that you’d like to have automatically formatted with each invocation on each line (maybe except for the very first invocation).

You can configure the Eclipse Java formatter with that respect; you just need to reach the right option (the “Force split” is necessary to have each invocation on a separate line):

and then you can have method calls formatted automatically like that:

How to add Eclipse launcher in Gnome dock

7 Replies

In this post I’ll show how to add an Eclipse launcher as a favorite (pinned) application in the Gnome dock (I’m using Ubuntu Artful). This post is inspired by http://blog.ttoine.net/en/2016/06/30/how-to-add-eclipse-neon-launcher-in-gnu-linux-menus-and-launchers/.

First of all, you need to create a .desktop file, where you need to specify the full path of your Eclipse installation:

[Desktop Entry]
Version=Oxygen
Name=Eclipse Java
Comment=Eclipse is an IDE
Exec=/home/bettini/eclipse/java-latest-released/eclipse/eclipse
Icon=/home/bettini/eclipse/java-latest-released/eclipse/icon.xpm
Terminal=false
Type=Application
Categories=Utility;Application;Development;

[Desktop Entry]

Version=Oxygen

Name=Eclipse Java

Comment=Eclipse is an IDE

Exec=/home/bettini/eclipse/java-latest-released/eclipse/eclipse

Icon=/home/bettini/eclipse/java-latest-released/eclipse/icon.xpm

Terminal=false

Type=Application

Categories=Utility;Application;Development;

This is relative to my installation of Eclipse which is in the folder /home/bettini/eclipse/java-latest-released/eclipse, note the executable “eclipse” and the “icon.xpm”. The name “Eclipse Java” is what will appear as the launcher name both in Gnome applications and later in the dock.

Make this file executable.

Copy this file in your home folder in .local/share/applications.

Now in Gnome Activities search for such a launcher and it should appear:

Select it and make sure that Eclipse effectively runs.

Unfortunately, in the dock, there’s no contextual menu for you to add it as a favorite and pin it to the dock:

But you can still add it to the dock favorites (and thus pin it there) by using the corresponding contextual menu that is available when the launcher appears in the Activities:

And there you go: the Eclipse launcher is now on your dock and it’s there to stay 🙂

Touchpad gestures in Linux KDE with Libinput-gestures

14 Replies

This post is based on my Dell M3800 with Linux Neon.

KDE already does a good job with touchpad gestures (e.g., two fingers for scrolling, 3 finger tap for pasting, etc.) but it does not support 3 finger swype gestures like in MacOs, e.g., for displaying all the windows or for showing the desktop.

Today I tried this utility, Libinput-gestures, which works like magic! The utility comes with good default for typical gestures (including pinch) but I configured that to fit my needs (in particular, I wanted to mimic MacOs behavior for 3 finger swypes: up = display all windows, down = display all windows of the same class and for pinch out = show desktop.

The installation of Linput-gestures is really easy (just follow the instructions at its web page).

Remember that, first of all, your user must be in the input group, so first run

sudo gpasswd -a $USER input

1	sudo gpasswd -a $USER input

Then logout from your current session, and login again.

Then, in Ubuntu, it’s just a matter of running

sudo apt-get install xdotool wmctrl libinput-tools

1	sudo apt-get install xdotool wmctrl libinput-tools

and install the software like this (you need git):

git clone http://github.com/bulletmark/libinput-gestures
cd libinput-gestures
sudo ./libinput-gestures-setup install

git clone http://github.com/bulletmark/libinput-gestures

cd libinput-gestures

sudo ./libinput-gestures-setup install

You can already start the program like this

libinput-gestures-setup start

1	libinput-gestures-setup start

and if you want it to be started at login time, then run

libinput-gestures-setup autostart

1	libinput-gestures-setup autostart

The default gestures are in /etc/libinput-gestures.conf. If you want to create your own custom gestures then copy that file to ~/.config/libinput-gestures.conf and edit it.

These are the lines I changed in my configuration (remember that each time you modify the configuration you need to restart libinput-gestures, i.e., instead of start in the command line above, just use restart):

# KDE: Present Windows (current desktop)
gesture swipe up	xdotool key ctrl+F9

# KDE: Present Windows (Window class)
gesture swipe down	xdotool key ctrl+F7

# KDE: Show desktop
gesture pinch out xdotool key ctrl+F12

# KDE: Present Windows (current desktop)

gesture swipe up xdotool key ctrl+F9

# KDE: Present Windows (Window class)

gesture swipe down xdotool key ctrl+F7

# KDE: Show desktop

gesture pinch out xdotool key ctrl+F12

You only need to know the keyboard shortcuts of the actions you want to associate to mouse gestures. With that respect, you might want to have a look at the current shortcuts in KDE Settings (the interesting components are “KWin” and “Plasma”):

This is a video demoing the gestures:

Happy gestures! 🙂

JaCoCo Code Coverage and Report of multiple Eclipse plug-in projects

17 Replies

In this tutorial I’ll show how to use Jacoco with Maven/Tycho to create a code coverage report of multiple Eclipse plug-in projects.

The code of the example is available here: https://github.com/LorenzoBettini/tycho-multiproject-jacoco-report-example.

This is the structure of the projects:

Each project’s code is tested in a specific .tests project. The code consists of simple Java classes doing nothing interesting, and tests just call that code.

The Maven parent pom file is written such that Jacoco is enabled only when the profile “jacoco” is explicitly activated:

<profile>
	<id>jacoco</id>
	<activation>
		<activeByDefault>false</activeByDefault>
	</activation>
	<build>
		<plugins>
			<plugin>
				<groupId>org.jacoco</groupId>
				<artifactId>jacoco-maven-plugin</artifactId>
				<version>${jacoco-version}</version>
				<configuration>
					<excludes>
						<exclude>**/plugin1/Main.class</exclude>
					</excludes>
				</configuration>
				<executions>
					<execution>
						<goals>
							<goal>prepare-agent</goal>
						</goals>
					</execution>
				</executions>
			</plugin>
		</plugins>
	</build>
</profile>

<id>jacoco</id>

<activeByDefault>false</activeByDefault>

</activation>

<build>

<groupId>org.jacoco</groupId>

<artifactId>jacoco-maven-plugin</artifactId>

<version>${jacoco-version}</version>

<exclude>**/plugin1/Main.class</exclude>

</excludes>

</configuration>

<goals>

<goal>prepare-agent</goal>

</goals>

</execution>

</executions>

</plugin>

</plugins>

</build>

</profile>

This is just an example of configuration; you might want to tweak it as you see fit for your own projects (in this example I also created a Main.java with a main method that I exclude from the coverage). By default, the jacoco-maven-plugin will “prepare” the Jacoco agent in the property tycho.testArgLine (since our test projects are Maven projects with packaging eclipse-plugin-test); since tycho.testArgLine is automatically used by the tycho-surefire-plugin and since we have no special test configuration, the pom.xml of our test projects is just as simple as this:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<parent>
		<groupId>example</groupId>
		<artifactId>example.parent</artifactId>
		<version>0.0.1-SNAPSHOT</version>
	</parent>
	<artifactId>example.plugin1.tests</artifactId>
	<packaging>eclipse-test-plugin</packaging>

</project>

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

<groupId>example</groupId>

<artifactId>example.parent</artifactId>

<version>0.0.1-SNAPSHOT</version>

</parent>

<artifactId>example.plugin1.tests</artifactId>

<packaging>eclipse-test-plugin</packaging>

</project>

if you need a custom configuration, then you have to explicitly mention ${tycho.testArgLine} in the <argLine>.

Now we want to create an aggregate Jacoco report for the classes in plugin1 and plugin2 projects (tested by plugin1.tests and plugin2.tests, respectively); each test project will generate a jacoco.exec file with coverage information. Before Jacoco 0.7.7, creating an aggregate report wasn’t that easy and required to store all coverage data in a single an .exec file and then use an ant task (with a manual configuration specifying all the source file and class file paths). In 0.7.7, the jacoco:report-aggregate has been added, which makes creating a report really easy!

Here’s an excerpt of the documentation:

Creates a structured code coverage report (HTML, XML, and CSV) from multiple projects within reactor. The report is created from all modules this project depends on. From those projects class and source files as well as JaCoCo execution data files will be collected. […] This also allows to create coverage reports when tests are in separate projects than the code under test. […]

Using the dependency scope allows to distinguish projects which contribute execution data but should not become part of the report:

compile: Project source and execution data is included in the report.

test: Only execution data is considered for the report.

So it’s just a matter of creating a separate project (I called that example.tests.report) where we:

configure the report-aggregate goal (in this example I bind that to the verify phase)
add as dependencies with scope compile the projects containing the actual code and with scope test the projects containing the tests and .exec data

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<parent>
		<groupId>example</groupId>
		<artifactId>example.parent</artifactId>
		<version>0.0.1-SNAPSHOT</version>
	</parent>
	<artifactId>example.tests.report</artifactId>

	<packaging>pom</packaging>

	<profiles>
		<profile>
			<id>jacoco</id>
			<activation>
				<activeByDefault>false</activeByDefault>
			</activation>
			<build>
				<plugins>
					<plugin>
						<groupId>org.jacoco</groupId>
						<artifactId>jacoco-maven-plugin</artifactId>
						<version>${jacoco-version}</version>
						<executions>
							<execution>
								<phase>verify</phase>
								<goals>
									<goal>report-aggregate</goal>
								</goals>
							</execution>
						</executions>
					</plugin>
				</plugins>
			</build>
		</profile>
	</profiles>

	<dependencies>
		<dependency>
			<groupId>example</groupId>
			<artifactId>example.plugin1</artifactId>
			<version>${project.version}</version>
			<scope>compile</scope>
		</dependency>
		<dependency>
			<groupId>example</groupId>
			<artifactId>example.plugin2</artifactId>
			<version>${project.version}</version>
			<scope>compile</scope>
		</dependency>
		<dependency>
			<groupId>example</groupId>
			<artifactId>example.plugin1.tests</artifactId>
			<version>${project.version}</version>
			<scope>test</scope>
		</dependency>
		<dependency>
			<groupId>example</groupId>
			<artifactId>example.plugin2.tests</artifactId>
			<version>${project.version}</version>
			<scope>test</scope>
		</dependency>
	</dependencies>
</project>

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

<groupId>example</groupId>

<artifactId>example.parent</artifactId>

<version>0.0.1-SNAPSHOT</version>

</parent>

<artifactId>example.tests.report</artifactId>

<id>jacoco</id>

<activeByDefault>false</activeByDefault>

</activation>

<build>

<groupId>org.jacoco</groupId>

<artifactId>jacoco-maven-plugin</artifactId>

<version>${jacoco-version}</version>

<phase>verify</phase>

<goals>

<goal>report-aggregate</goal>

</goals>

</execution>

</executions>

</plugin>

</plugins>

</build>

</profile>

</profiles>

<groupId>example</groupId>

<artifactId>example.plugin1</artifactId>

<version>${project.version}</version>

<scope>compile</scope>

</dependency>

<groupId>example</groupId>

<artifactId>example.plugin2</artifactId>

<version>${project.version}</version>

<scope>compile</scope>

</dependency>

<groupId>example</groupId>

<artifactId>example.plugin1.tests</artifactId>

<version>${project.version}</version>

</dependency>

<groupId>example</groupId>

<artifactId>example.plugin2.tests</artifactId>

<version>${project.version}</version>

</dependency>

</dependencies>

</project>

That’s all!

Now run this command in the example.parent project:

mvn clean verify -Pjacoco

1	mvn clean verify -Pjacoco

and when the build terminates, you’ll find the HTML code coverage report for all your projects in the directory (again, you can configure jacoco with a different output path, that’s just the default):

/example.tests.report/target/site/jacoco-aggregate

Since, besides the HTML report, jacoco will create an XML report, you can use any tool that keeps track of code coverage, like the online free solution Coveralls (https://coveralls.io/). Coveralls is automatically accessible from Travis (I assume that you know how to connect your github projects to Travis and Coveralls). So we just need to configure the coveralls-maven-plugin with the path of the Jacoco xml report (I’m doing this in the parent pom, in the pluginManagement section in the jacoco profile):

<plugin>
	<groupId>org.eluder.coveralls</groupId>
	<artifactId>coveralls-maven-plugin</artifactId>
	<version>4.3.0</version>
	<configuration>
		<jacocoReports>
			<jacocoReport>${project.basedir}/example.tests.report/target/site/jacoco-aggregate/jacoco.xml</jacocoReport>
		</jacocoReports>
	</configuration>
</plugin>

<groupId>org.eluder.coveralls</groupId>

<artifactId>coveralls-maven-plugin</artifactId>

<jacocoReport>${project.basedir}/example.tests.report/target/site/jacoco-aggregate/jacoco.xml</jacocoReport>

</jacocoReports>

</configuration>

</plugin>

And here’s the Travis file:

sudo: false

language: java

jdk: oraclejdk8

cache:
  directories:
  - $HOME/.m2

install: true

script:
 - mvn -f example.parent/pom.xml clean verify -Pjacoco coveralls:report

sudo: false

language: java

jdk: oraclejdk8

cache:

directories:

- $HOME/.m2

install: true

script:

- mvn -f example.parent/pom.xml clean verify -Pjacoco coveralls:report

This is the coveralls page for the example project https://coveralls.io/github/LorenzoBettini/tycho-multiproject-jacoco-report-example. And an example of coverage information:

That’s all!

Happy coverage! 🙂

The second edition of the Xtext book has been published

4 Replies

The second edition of the Xtext book, Implementing Domain-Specific Languages with Xtext and Xtend, was published at the end of August: https://www.packtpub.com/web-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition. So… get it while it’s hot 🙂

Please, see my previous post for details about the novelties in this edition.

Sources of the examples are on github: https://github.com/LorenzoBettini/packtpub-xtext-book-2nd-examples.

Hope you’ll enjoy the book!

The forthcoming second edition of the Xtext book

5 Replies

The second edition of the Xtext book should be published soon! In the meantime it is already available for preorders. At the time of writing, you can benefit for discounts and preorder it at 10$.

I’ll detail the differences and novelties of this second edition.

But, first things first! A huge thank you to Jan Köhnlein, for reviewing this second edition, and a special thank you to Sven Efftinge, for writing the foreword to this second edition. I am also grateful to itemis Schweiz, and in particular, to Serano Colameo for sponsoring the writing of this book.

While working on this second edition, I updated all the contents of the previous edition in order to make them up to date with respect to what Xtext provides in the most recent release (at the time of writing, it is 2.10).

All the examples have been rewritten from scratch. The main examples, Entities, Expressions and SmallJava, are still there, but many parts of the DSLs, including their features and implementations, have been modified and improved, focusing on efficient implementation techniques and the best practices I learned in these years. Thus, while the features of most of the main example DSLs of the book is the same as in the first edition, their implementation is completely new.

Moreover, In the last chapters, many more examples are also introduced.

Chapter 11 on Continuous Integration, which in the previous edition was called “Building and Releasing”, has been completely rewritten and it is now based on Maven/Tycho and on Gradle, since Xtext now provides a project wizard that also creates a build configuration for these build tools. Building with Maven/Tycho is described in more details in the chapter, and Gradle is briefly described. This new chapter also briefly describes the new Xtext features: DSL editor on the web and also on IntelliJ.

I also added a brand new chapter at the end of the book, Chapter 13 “Advanced Topics”, with much more advanced material and techniques that are useful when your DSL grows in size and features. For example, the chapter will show how to manually maintain the Ecore model for your DSL in several ways, including Xcore. This chapter also presents an advanced example that extends Xbase, including the customization of its type system and compiler. An introduction to Xbase is still presented in Chapter 12, as in the previous edition, but with more details.

As in the previous edition, the book fosters unit testing a lot. An entire chapter, Chapter 7 “Testing”, is still devoted to testing all aspects of an Xtext DSL implementation.

Most chapters, as in the previous edition, still have a tutorial nature.

Summarizing, while the title and the subject of most chapters is still the same, their contents have been completely reviewed, extended and, hopefully, improved.
If you enjoyed the first edition of the book and found it useful, I hope you’ll like this second edition even more.

Cookie	Duration	Description
cookielawinfo-checkbox-analytics	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional	11 months	The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy	11 months	The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.

Lorenzo Bettini

My Home Page

My new book on TDD, Build Automation and Continuous Integration

How to install Linux on a USB drive using Virtualbox

Eclipse tested with a few Gnome themes

Analyzing Eclipse plug-in projects with Sonarqube

Formatting Java method calls in Eclipse

How to add Eclipse launcher in Gnome dock

Touchpad gestures in Linux KDE with Libinput-gestures

JaCoCo Code Coverage and Report of multiple Eclipse plug-in projects

The second edition of the Xtext book has been published

The forthcoming second edition of the Xtext book