IDE Configuration

IDE Configuration

Having self-contained jlink-based applications is nice for deployment, but not suitable for development. IDEs usually provide more than one way to configure so-called  run- or debug-configurations. IntelliJ IDEA allows you to launch the application via maven or from within the IDE’s workspace.

The poms for the server, daemon and FX-client already contain the configuration for the maven exec plugin and you can run the applications from the console via mvn exec:java. This can also be used by IntelliJ as follows:

Please keep in mind that launching the application via mvn exec:java runs it in classpath mode, since maven itself is not modularized according to the JPMS. Tentackle applications can run on the modulepath, the traditional classpath or in an OSGi container. This is handled by Tentackle’s ServiceFinder that detects the operating mode and adapts accordingly.

As an alternative, you can create a so-called application config. Here is an example for the FX-client:

This is the preferred way to run or debug Tentackle applications on the modulepath in JPMS mode. Due to the additional checks by the java runtime in modular mode and the fact that not all packages of JavaFX have already been refactored and moved to the public API, the runtime must be told to export and open some non-public com.sun.*** packages. This can easily be configured in the field “VM Options” as follows:


Test scope

Resources and configurations for development and testing should not become part of the artifacts. The maven way to achieve this is to put them into test folders such as src/test. That’s why we need the extra -cp test-classes in the VM options above. For the server, we also need the path to the postgres JDBC driver. The server’s VM options look like this:

-cp test-classes:${HOME}/.m2/repository/org/postgresql/postgresql/42.2.9/postgresql-42.2.9.jar

You should also create a maven config for clean install, maybe clean as well. Some more configs are covered in the next chapters.


Tentackle can be configured to collect some statistics during execution. This comes at neglectable cost and helps to detect performance issues before the application goes into production.
Collected are the count and min/max/total execution times (in nanoseconds) for:

  1. SQL statements
  2. RMI calls
  3. Invocations of PDO- and operation methods (both persistence and domain)

Simply turn it on with the --statistics option as shown above.
For unix/linux users: in Tentackle’s source repository at Bitbucket there is a shell script called that collects the statistics from a logfile and converts it into a CSV file ready for import into a spreadsheet.