Testing OSGi applications and services has always been a difficult challenge. Despite the development of several frameworks such as OPS4J Pax Exam, or junit4osgi, writing tests requires a non-negligible amount of code to manage the OSGi aspect of the test. Indeed, waiting and getting the service under test or releasing the service requires dealing directly with the OSGi framework and so the OSGi API. The OSGi Helper library is a small collection of classes to let tests focus on the behavior to verify instead of drowning the code in the depths of the OSGi development model.
The OSGi Helper library was developed by the Innovation department of akquinet, and was contributed to the OW2 Chameleon project.
This post explains the benefits brought by the library in comparison to plain OSGi tests.
Maven is a great build tool that has already proven its benefits. But sometimes, you need an extension for a custom task or need. Luckily, Maven is extensible and allows you to write plugins.
Now, when implementing a Maven plugin, you generally want to test it as well. If possible, we want do do that automatically. Those tests then run on your continuous integration server and you’re notified when, unfortunately, you (or someone else) broke something. Automatic Maven Plugin tests can be done with different approaches. This post focuses on a strategy suitable for integration tests.
Developing sophisticated Android applications is challenging. Despite tools provided with the SDK and the recommended ADT Eclipse Plugin, maintaining and developing an Android application is time-consuming.
This blog post introduces a series on the rationalization of Android application development. It aims to explain how the akquinet mobile team have changed the way to create Android applications to improve the efficiency and quality of the developed applications. This series covers several topics, from the utilization of Apache Maven, the integration with a continuous integration server to the customization of the logging framework.
akquinet has participated in the improvement of all the tools used and presented in this series and has also released several internally developed components as open-source projects.
The last post of this series has introduced a couple of useful options to manage built modules in a multi-module project. This post focuses on failure. Maven proposes three different way to manage failures in reactor builds: fail-fast (default), fail-at-end and fail-never which will be described in this post.