Generation 7 - Remove unused prefixes from artifact names

In Generation 7 (all versions with miner 7 version) all needless prefixes are removed. This means if the artifact name includes the name of the main project - most of all the prefix 'mhu'.

For example in the project 'mhus-lib' there was the package 'mhu-lib-core'. The prefix is now removed and the package is name 'lib-core'. The second prefix is left to specify the project.

Migrate mhus-sop to mhus-rest and mhus-micro

For reorganisation I split the project mhus-sop to mhus-rest and mhus-micro and parts in the existing mhus-osgi-tools. Now mhus-sop (service orientated platform) is depecated.

The parts to handle rest interfaces is moved to mhus-rest. Why another rest framework? Because this rest is prepared to handle deep rest structures instead of for example jax-rs.

The parts for Operations and Operation providers are moved to mhus-micro. This is the central framework to work with micro services. It's able to combine different micro service frameworks to one interface.

The part AAA and ADB Service is moved into mhus-osgi-tools.

Some interfaces are moved directly in mhus-lib. The tool IdentUtil will return the current ident without big actions.

Use of felix healtchecks in karaf 4.2.6

I tried to investigate in the felix healthcheck framework to create kubernetes health and ready checks.

I found that the healthcheck can be used in karaf even. You have to install it manually with

install -s mvn:org.apache.commons/commons-lang3/3.9
install -s  mvn:org.apache.felix/org.apache.felix.healthcheck.api/2.0.2
install -s  mvn:org.apache.felix/org.apache.felix.healthcheck.core/2.0.2
install -s  mvn:org.apache.felix/org.apache.felix.healthcheck.generalchecks/2.0.2

And the webconsole:

feature:install webconsole
install -s  mvn:org.apache.felix/org.apache.felix.healthcheck.webconsoleplugin/2.0.0

Now you can see the check results with:


The source is available under

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