FWIW The reason that I'm trying to update sonar-collector's docker image is that I discovered that sonar-collector actually has a user, and that user uses the docker image which suddenly stopped working: https://github.com/steinarb/sonar-collector/issues/5
The way I've created the docker image is that I've started with the official docker image and then have just added LATEST of sonar-collector's feature repository to karaf's boot repository list and then have added the PostgreSQL JDBC driver and sonar-collector itself to the list of boot features. The idea was to create one image that always pulled the latest sonar-collector from maven central. That works fine, I guess, until I start building for a newer Java version. I'm currently building and releasing on java 17, and the official karaf 4.4.4 image is running on java 11, so that might be a problem. Curiously the issue above isn't from Java version, it seems to be the OSGi version? My current sonar-collector docker image is based on the 4.2.8 official karaf image, which is OSGi 6 and Java 8. As I said I'm currently building for and with java 17 and OSGi 8. Surprisingly the error message seems to be related to running an OSGi 8 application on OSGi 6. It's surprising, because I would have thought binary incompatibility from using a newer version byte code would have stopped it before that...? Ah well, one step at a time. The current blocker is that when creating a new docker image on top of the official karaf 4.4.4 image, I keep getting arm64 docker images even though I'm running on amd64. And for the curious that has read this far: sonar-collector is a very simple application that is intended as a webhook to be called by sonarqube and/or sonarcloud, and for each call writes a row in a PostgreSQL database table with some key values from that analysis. It is intended for making long term statistics. The sonar-collector was created and used when maintaining a set of applications with, well, not so good numbers, to prove that for each iteration we made those applications slightly better instead of slightly worse. Sonarqube didn't offer an API to read out those statistics, and typing them in was a chore, writing a webhook was the suggestion made by sonarqube, so that's what I did.
