Org.jsoup.jsoup 1.23.1 missing from jfrog

jimtng · August 5, 2026, 11:09pm

org.jsoup.jsoup 1.23.1 is needed in the latest snapshot

pom.xml

239bfdc2b


      
          <asm.version>9.9.1</asm.version>
          <bnd.version>7.3.0</bnd.version>
          <bouncycastle.version>1.85</bouncycastle.version>
          <commons.codec.version>1.17.1</commons.codec.version>
          <commons.net.version>3.9.0</commons.net.version>
          <eea.version>2.4.0</eea.version>
          <jackson.annotations.version>2.21</jackson.annotations.version>
          <jackson.version>2.21.4</jackson.version>
          <jna.version>5.18.1</jna.version>
          <json.version>20251224</json.version>
          <jsoup.version>1.23.1</jsoup.version>
          <karaf.version>4.4.11</karaf.version>
          <mockito.version>5.23.0</mockito.version>
          <netty.version>4.1.133.Final</netty.version>
          <graalvm.version>25.0.1</graalvm.version>
          <okhttp3.version>4.12.0</okhttp3.version>
          <okio.version>3.17.0</okio.version>
          <gson.version>2.13.2</gson.version>
          <kotlin.version>1.9.23</kotlin.version>
          <sat.version>0.18.0</sat.version>
          <slf4j.version>2.0.17</slf4j.version>

but missing from jfrog.

pinging @kai

jimtng · August 5, 2026, 11:10pm

From time to time, I’ve come across this situation. We might need some sort of automated check.

jimtng · August 5, 2026, 11:24pm

Note: as a workaround, I added maven to the list of repositories in my userdata/etc/org.ops4j.pax.url.mvn.cfg

org.ops4j.pax.url.mvn.repositories= \
        https://openhab.jfrog.io/openhab/libs-snapshot@id=openhab@snapshots, \
        https://repo1.maven.org/maven2/@id=central

florian-h05 · August 8, 2026, 9:31am

It would be great if the Karaf feature check in the add-on build could be limited to only use our JFrog and not access Maven Central. This way every missing artefact would be immediately noticed.

florian-h05 · August 8, 2026, 10:35am

I’ve just uploaded it to JFrog.

jimtng · August 8, 2026, 11:04am

I can understand hosting osgiified bundles on jfrog.

I don’t understand the policy of mirroring everything else, manually into jfrog instead of adding maven central as a second repository source like what I did.

florian-h05 · August 8, 2026, 11:10am

There are two reasons for doing this:

An openHAB server should not depend on any external service (i.e. not controlled by the openHAB project).
Maven Central isn’t meant as a place where you host artefacts that your deployed software downloads. Sonatype has quite a few blog posts explaining that rogue CI pipelines without caching already hammer central‘s servers with requests, having every single openHAB instance fetch artefacts from central would be very unfriendly against central. Note that openHAB‘s bundle cache is cleared on every upgrade.

wborn · August 8, 2026, 3:40pm

Would it make sense to add Maven Central as a remote repository in JFrog and only give CI “Deploy/Cache” permission on it?
Then CI could automatically fetch and cache new dependencies when they are introduced, while normal openHAB users would only have “Read” access and could only download artifacts that are already cached. That would avoid the recurring manual uploads without exposing JFrog as a general Maven Central proxy.

wborn · August 8, 2026, 3:53pm

It could even be only enabled for main/patch branches so PRs cannot be abused to fill it. When it’s not in the cache the builds would fail instead of users having to find out about it months later in “production”.

florian-h05 · August 8, 2026, 4:32pm

Maybe only give this right to our Jenkins builds and keep it completely out of GitHub.

wborn · August 9, 2026, 5:37am

I’ve updated the issue for this:

github.com/openhab/openhab-distro

Add-on dependencies are often missing from the openHAB Maven repo

opened 05:55PM - 07 Sep 24 UTC

wborn

Add-ons sometimes fail to install because one of the bundles referenced by their… Karaf features is not available from the openHAB JFrog Maven repository. This is not necessarily caught by the build today because Maven can resolve the artifact directly from Maven Central, while an openHAB runtime intentionally only resolves such artifacts through the openHAB-controlled JFrog repository. A recent example was `org.jsoup:jsoup:1.23.1`, discussed here: https://community.openhab.org/t/org-jsoup-jsoup-1-23-1-missing-from-jfrog/170026/9 ## Rationale There are good reasons for keeping the openHAB repository as the only remote Maven repository used by openHAB installations: - An openHAB installation should not depend directly on an external service that is outside the control of the openHAB project. - Maven Central should not effectively become a CDN for deployed openHAB installations. Sonatype explicitly states that [Maven Central should not be in your runtime path](https://central.sonatype.org/faq/429-tooling-provider/#maven-central-should-not-be-in-your-runtime-path) and recommends putting a repository manager/cache between production systems and Maven Central. - Having every openHAB installation download runtime dependencies directly from Maven Central would create unnecessary traffic, especially because dependencies may need to be downloaded again after an openHAB upgrade. Adding Maven Central to `org.ops4j.pax.url.mvn.repositories` therefore works as a temporary user workaround, but should not be the actual solution. ## JFrog proxy/cache JFrog is already configured with a remote repository that proxies Maven Central and caches requested artifacts. The official `openhab-distro` snapshot, milestone, and release builds can use this proxy configuration and have sufficient access to cause previously uncached artifacts to be fetched from Maven Central and added to the JFrog cache. This gives us a controlled way to automatically populate JFrog with dependencies needed by the distribution instead of having to upload missing artifacts manually whenever an add-on dependency changes. An artifact does not need to be explicitly deployed into the remote repository. When one of these distro builds requests an uncached artifact through the proxy, JFrog fetches it from Maven Central and stores it in the remote cache. The cached artifacts can then be served through the JFrog repository used by openHAB installations, so production installations continue to depend only on openHAB infrastructure and never directly on Maven Central. ## Keep the proxy scoped to official distro builds The Maven Central proxy should deliberately only be used for the official `openhab-distro` snapshot, milestone, and release builds that are intended to populate the runtime dependency cache. It should **not** be used by: - pull request builds; - normal `openhab-addons`, `openhab-core`, or other repository builds; - regular developer builds. Those builds should continue resolving their normal build dependencies directly from Maven Central. Otherwise the openHAB JFrog cache would effectively become a general Maven Central proxy and would gradually fill with every dependency, Maven plugin, test dependency, and transient artifact encountered by CI or development builds. Restricting cache population to the official distro builds keeps the cache reasonably close to the dependency set actually needed to produce an openHAB distribution. It will still not be a perfect representation of the production runtime dependency set. A distro build can resolve artifacts that are only needed while building, testing, or packaging the distribution, so the cache may become somewhat larger than strictly necessary for production installations. That seems like an acceptable trade-off compared with either manually maintaining the repository or proxying Maven Central for all openHAB builds. ## Proposed fix The build and JFrog configuration should work together as follows: 1. Continue using the JFrog Maven Central proxy/cache from the official `openhab-distro` snapshot, milestone, and release builds. 2. Allow those builds to populate the JFrog cache when previously unseen dependencies are encountered. 3. Do not use the Maven Central proxy for PR builds, regular developer builds, or normal builds of the individual openHAB repositories. 4. Make the cached artifacts required at runtime available through the JFrog repository used by openHAB installations. 5. Verify the generated Karaf features against the same repository view available to a normal openHAB runtime, without Maven Central as a fallback. The last step is important: after the distro build has had the opportunity to populate the cache, feature verification should fail if a runtime dependency still cannot be resolved from the repository that an actual openHAB installation uses. This would make missing dependencies either automatically enter the controlled JFrog cache during an official distro build or fail that build, instead of first being discovered when a user tries to install an add-on. Until a missing artifact is available from JFrog, users can install the offline `openhab-addons` KAR, which already contains the add-on dependencies.