It has been a while since the last release in the Citrus universe. It took us some time to get the new Citrus release 2.7.2 ready for you.
Of course we were not being lazy in that time. Besides the new Citrus 2.7.2 release we are proud to announce a new player in the Citrus team. The Citrus administration UI is a
web-based user interface that helps you to manage your Citrus projects and test cases.
Often users complained about the complexity of having to learn all about Citrus and the Spring framework in particular as Citrus uses Spring for configuration and dependency injection.
Especially non-developers had problems to master the learning curve for Citrus and Spring when starting to use the framework. Also people asked for a way to have a user interface for managing
components and tests.
We heard you and introduced a new administration user interface for Citrus! There is a detailed Citrus Admin documentation (which is still ongoing).
However I would like to outline the main features of that web UI here in a short post for you.
The ELK-Stack is a good option to aggregate and visualize distributed logging-data. It basically based on
The core of the most ELK applications is the Logstash configuration. A user defines here which data (inputs) is processed, how (filter) the data is processed and where it will go afterwards (outputs). Especilly this configuration contains a lot of logic which is unfortunally not easy to test. In this article I want to show you how to setup a testing environment for your Logstash configuration.
TestNG groups add great flexibility to the Citrus test execution. We are able to divide all tests into several groups reaching a sophisticated seperation of concerns in our test setup. As an example I want to classify some of my functional Citrus tests as “long-running”. These tests may not apply to continuous execution every time I package my project. Instead of this I want to set up a scheduled integration build to execute those long-running tests in a time schedule.
In larger projects usually a team of testers is working on Citrus integration tests. This means that we need to localize the citrus.properties for testing on different machines, as each tester executes test cases with individual environment settings. In this post I’d like to share an easy way to localize the Citrus settings with Maven.
Labs got its own maven repository now:
Add the repos to your project POM. Here’s an example for the release repository:
</p> <repository> <id>consol-labs-release</id> <url>http://labs.consol.de/maven/repository/</url> <snapshots> <enabled>false</enabled> </snapshots> <releases> <enabled>true</enabled> </releases> </repository> <repository> <id>consol-labs-snapshots</id> <url>http://labs.consol.de/maven/snapshots-repository/</url> <snapshots> <enabled>true</enabled> <!-- Policy: always, daily, interval:xxx (xxx=#minutes, 60*24*7=10080), never --> <updatepolicy>interval:10080</updatepolicy> </snapshots> <releases> <enabled>false</enabled> </releases> </repository> <p>
Simply add this profile to your project, and activate it when deploying:
</p> <profile> <id>dist-labs</id> <distributionmanagement> <repository> <id>consol-labs-release</id> <url>scpexe://labs.consol.de/home/maven-repository/www/htdocs/repository</url> </repository> <snapshotrepository> <id>consol-labs-snapshots</id> <url>scpexe://labs.consol.de/home/maven-repository/www/htdocs/snapshots-repository</url> </snapshotrepository> </distributionmanagement> </profile> <p>
</p> <server> <id>consol-labs-release</id> <username>maven-repository</username> </server> <server> <id>consol-labs-snapshots</id> <username>maven-repository</username> </server> <p>
<br /> mvn clean install deploy -Pdist-labs<br />
In a multi module Maven project, it seems non trival to reference the project root location from the sub modules deeper down in the module hierarchy. The following approach describes how to configure a plugin referencing a root POM relative file.