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.
Got an an internationalized Java app?
Then the maven-rbc-plugin plugin can help you finding
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.