[dev] Migrate to mhus-lib 3.6.3 - extract vaadin libs

 The main change in mhus-lib will be the extraction of mhu-lib-vaadin into a separate project mhus-vaadin.


In this project I started a library for vaadin 14+ but for preparation I moved the subproject of vaadin 8 to this project together. Also the vaadin bridge from mhus-osgi-tools is now located in the new repository.

The new project pass on the

The package declaration was not changed

Comments

Post a Comment

Popular posts from this blog

Creating a flux sync configuration referring a config map for substitution

 If you configure your k8s cluster with terraform one of the final steps is to install a fluxcd operator. The operator are responsible to manage the resources inside of the cluster. In this way a fully automatic creation process is possible. To install flux a terraform provider is available preparing a install and sync configuration which can be installed in k8s using the kubernetes/kubectl providers. In fluxcd itself it is possible to use substitution . This means you can use variables to prepare the k8s yaml files. This is useful for variable content like different cluster names and domain names for all stages. Or more specialised arn ids of created resources while creating the cluster in aws. To use substitution fluxcd offers to link the configuration to a config map. In the map a set of key values can be defined to replace variable values. The map can also be created with terraform and the kubectl provider. Do not store secrets in the config map. Try to use secrets instead. Applyi
Read more

[dev] 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.
Read more

Create Spring Boot Images in Jenkins/CI in K8s, Part 1

  Working out Jenkins/CI pipelines it is a common task to create Spring Boot Images. Doing this with kubernetes agents is a challenge since docker is no more available from inside of containers. The task is quiet simple, create a spring boot image with `mvn spring-boot:build-image` inside a kubernetes pod. By default this fails because spring try to execute 'buildpacks' but the needed docker service is not available. The docker service is needed to create the container image. With spring 2.6 and beneath it is not possible to use another service then docker. But it is possible to use buildpacks separately after creating the project jar file. As replacement of docker it is possible to use podman as service. podman is compatible with docker and also supports the docker.sock. Looking forward to spring boot 2.7 which supports also podman as alternative to docker I did not try to use 'kaniko'. Objectives of this post: Create a woking pod and script to create spring boot image
Read more