Change of MHU Version String Definition

After defining the version strings in Januar and a look back I decided to change the version string definitions and use the common way of version counting.

In Wikipedia the definition major.minor[.maintenance[.build]]  looks good and is similar to my current definition: <core>.<major>.<minor>[.<hotfix>]

So I will remove the core component because it was not changing in the last 10 years and add the hotfix component as non optional part of the version string. By the way I will do the same as the big players - removing the unused parts from version string like java 1.8 is becoming Java 8.

To migrate all the projects I will remove the first number for the next iteration. So mhu-lib 3.6.3 will be 6.3.0 after the next release. The next snapshot is 6.4.0-SNAPSHOT.

10.Jan.2019 - MHU Version String Definition

In the last years I see a wide range of different version string definitions. In the last years more and more one digit only versioning becoming more and more popular. See also Wikipedia.

I prefer the notation with three or more numbers but in a different meaning as common: <core>.<major>.<minor>[.<hotfix>]

The core version describes a common structure or technology change. Most of the time it's the same. The core version only changes if the central structure or idea is changed. E.g. if switching from 'all in one' to a modular architecture.

The major version will increase if for example all dependencies are updated and the project must be reorganised therefore.

The minor version will change for every bundle of hot fixes and changes.

The hotfix version will only be set if a small important fix is needed without to update the hole project.

Migrate to mhus-osgi-tools 1.6.3

In osgi tools 1.6.3 are some breaking changes.

To divide api from implementation I created a new project mhu-osgi-api and moved the api interfaces and utilities into to new project. Therefore the package declaration of classes changed.

To fix it in dependent classes it is necessary to organise imports again. In Eclipse this is simply by using the function for the complete source folder. Before you do it you have to change the dependency artefact. Change in you pom from mhu-osgi-services to mhu-osgi-api.

One more change is to do. If you define jms data sources in a blueprint. You have to change the used interfaces and classes.

I found only the following changes to do:

"" to
"" to

vaadin 14 with osgi and karaf

After vaadin changed to the new flow technology it needs more effort to migrate to a new major version then 8.

In my case it means to test how to get vaadin in karaf working.

Unfortunately there is no direct karaf support in vaadin and there is no example or documentation how to do it. But I found OSGi support since vaadin 13. An example project was not working as described in the documentation ( Even with different branches and tags I get dependency exceptions in the OSGi framework.

So I started creating a new configuration and project from scratch.

I used my docker image with karaf 6.2.6 installed and java 11.0.3 to create a sample project and a bundle configuration.

You can checkout the project within my example project ( in folder vaadin-flow/mhu-vaadin-examples1. Compile the sources with maven:

git clone
cd mhus-examples/vaadin-flow/mhu-vaadin-examples1

Migrate to vaadin 8

Since Vaadin 7 will no more supported in 2019 I need to migrate to a newer version of the library. I migrated to Vaadin 8 in mhu-lib 3.4.0, mhu-osgi-tools 1.4.3 and mhu-ports 1.3.6.

The new version no more supports tables (I will discuss pro and contra in another post) but a set of legacy packages will do it for the moment. There are also some other changes but they are more or less handy.

The migration of the application can be done by a tool. The tool will modify all java imports to the new - correct - packages. I was using the standalone tool (alternatively you can use a maven goal). Download the sources from and compile the project afterwards you can use the jar file to migrate your projects. Change location into your project home directory and execute the jar file

java -jar $HOME/.m2/repository/com/vaadin/framework8-migration-tool/8.0-SNAPSHOT/framework8-migration-tool-8.0-SNAPSHOT.jar

If you use maven you need to change the vers…

uptime command for karaf

A tool that I love for unix is uptime. Showing the current and last runtimes. Now I invested 60 minutes to implement id in karaf also. Showing the current and last runtime records or the karaf server as the original.

Use 'uptime' to see the current records

karaf@root()> uptime  Status        | Runtime           | Start                     | Pid         | System               -------------------------------------------------------------------------------------------------- CLOSED        | 00 12:14:52       | 2018-08-03 22:26:43       | 24703       | 02 02:18:00         
CURRENT       | 00 00:39:39       | 2018-08-04 10:41:37       | 26418       | 02 02:58:00         
Using -u you can order it by uptime.
It also shows the system uptime and pid of the records. It's a nice tool for analysing.
Have fun ...

Modified Log Tail in karaf

A long time the command .mhu:log console' was created to tail the log from log file in runtime, means in the background while typing in the current session.

Now I created a new command 'mhus:logtail'. I copied the original 'log:tail' from and modified it to work in background.

The goal is that it will listen to the appenders and not to the log file. In this way it is possible to check the logging thread. With the option '-c' (console thread) it is possible to filter only log messages created by the current session thread. In this way you get feedback for your executed commands only and not all the logs of a running system.