How to deal with properties in Spring context tests?

public class MyTestConfig {

static {
System.setProperty("", "true"); 

/** properties loading */
public static PropertySourcesPlaceholderConfigurer properties() {
final PropertySourcesPlaceholderConfigurer pspc = new PropertySourcesPlaceholderConfigurer();
return pspc;


@SpringApplicationConfiguration(classes = MyTestConfig.class)
public class MySpringTest {

Java SSH Client

String hello = new Shell.Plain(
  new SSH(
    "", 22,
    "yegor", "-----BEGIN RSA PRIVATE KEY-----..."
).exec("echo 'Hello, world!'");

Java console program + Maven

Use “Assembler Plugin”:

How it looks:

$ mvn package appassembler:assemble
$ sh target/appassembler/bin/app
Hello World!

Linux renaming many files

My task was to rename many i18n files, because of technology migration. I found following solution:

rename 's/app_/messages_/' app*properties

Example of result: ->

DynamicReports – tool for generating Java reports pdf/docx/xlsx

Undoubtedly the most popular library for Java reporting is Jasper Reports. However in case of new projects is also nice to look for better approaches.

If you look at alternatives to Jasper Reports, you will find tones of similar products ->

I had a few picks, but decided to test only DynamicReports. Here is why:

After creating one pretty simple layout I find out some questions:

  • how to effectively test changes in layout design? I’ve used “;”, but I’m not sure it’s the best option.
  • is any way to share “JasperReportBuilder” across many threads and pass only some parameters when compiling reports? So far in header and summary section I was creating components initialized with data, which I think is not good for performance.
  • what is the right design pattern for class implementing reports with “JasperReportBuilder”? Example of class creating invoice report, called “”, has one huge method “build()” packed with styles and setup of “JasperReportBuilder”. I know it’s only demo, but also I was expecting some production-ready examples.


I like DynamicReports mainly because it’s pure Java. Support for JasperReports is also encouraging. If I develop answers for above questions, I’m sure I will use it in the future.