currently I try to build my pythonscripting addons with openhab 5.2.1-SNAPSHOT, but I found 2 problems.
in the pom.xml, is still 5.3.0-SNAPSHOT referenced.
If I change this to 5.2.1-SNAPSHOT, I got the following compilation error
[ERROR] Failed to execute goal on project org.openhab.automation.pythonscripting: Could not resolve dependencies for project org.openhab.addons.bundles:org.openhab.automation.pythonscripting:jar:5.2.1-SNAPSHOT: The following artifacts could not be resolved: org.openhab.core.bom:org.openhab.core.bom.compile:pom:5.2.1-SNAPSHOT (absent), org.openhab.core.bom:org.openhab.core.bom.openhab-core:pom:5.2.1-SNAPSHOT (absent), org.openhab.core.bom:org.openhab.core.bom.test:pom:5.2.1-SNAPSHOT (absent): org.openhab.core.bom:org.openhab.core.bom.compile:pom:5.2.1-SNAPSHOT was not found in https://openhab.jfrog.io/openhab/libs-snapshot during a previous attempt. This failure was cached in the local repository and resolution is not reattempted until the update interval of openhab-snapshot has elapsed or updates are forced -> [Help 1]
is it possible, that org.openhab.core.bom is not uploaded yet as version 5.2.1-SNAPSHOT?
I’m not sure how your build environment looks, but you must have distro, core and addons “in sync” version wise. I don’t rely on downloading artifacts, I build things myself. If you check out these repos to a 5.2.1 version, and then build core, the add-on should build fine afterward. You generate the BOM yourself when you build core.
edit: Building core without tests and checks takes some 5-7 minutes on my laptop, faster machines will do it even faster. From the root of the core repo, run:
Dmarkdownlint.skip=true isn’t needed for core, but is for addons, so I just keep it as a part of my “build command”. It does no harm on core, since the property doesn’t exist there. If under PowerShell, an extra argument is needed to prevent PowerShell from trying to interpret the arguments:
At this early stage of 5.3 a 5.3 snapshot might work on 5.2?
Some time ago when facing a similar situation a flag was suggested -Dohc.version=5.x.0 to add to the mvn clean install. I recall the name would still be 5.x+1, but was compatible with 5.x.
It compiles too and the result is still a kar file. But it is this time 10mb.
I figured out that the kar file contains a lot of karaf and osgi classes, which should not be there.
If I copy this kar file to my addons folder, everything messed up completely.
I get the error
2026-07-20 16:49:50.047 [WARN ] [internal.service.FeaturesServiceImpl] - Can't load features repository mvn:org.openhab.core.features.karaf/org.openhab.core.features.karaf.openhab-core/5.3.0-SNAPSHOT/xml/features
java.lang.RuntimeException: Error resolving artifact org.openhab.core.features.karaf:org.openhab.core.features.karaf.openhab-core:xml:features:5.3.0-SNAPSHOT: [Could not find artifact org.openhab.core.features.karaf:org.openhab.core.features.karaf.openhab-core:xml:features:5.3.0-SNAPSHOT] : mvn:org.openhab.core.features.karaf/org.openhab.core.features.karaf.openhab-core/5.3.0-SNAPSHOT/xml/features
at org.apache.karaf.features.internal.service.RepositoryImpl.load(RepositoryImpl.java:123)
at org.apache.karaf.features.internal.service.RepositoryImpl.<init>(RepositoryImpl.java:51)
at org.apache.karaf.features.internal.service.RepositoryCacheImpl.create(RepositoryCacheImpl.java:51)
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.getFeatureCache(FeaturesServiceImpl.java:611)
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.getFeaturesById(FeaturesServiceImpl.java:645)
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.refreshFeatures(FeaturesServiceImpl.java:1236)
at org.openhab.core.karaf.internal.FeatureInstaller.processConfigQueue(FeatureInstaller.java:199)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)
my python script says ModuleNotFoundError, No module named 'scope.osgi'
my guess that the osgi classes inside my kar file are the reason. It breaks openhab osgi/karaf…
btw. the compiled jar files are still ~130kb, which is ok.
But I depend on the kar file. Otherwise the grallvm feature dependencies are not resolved if I install my addon.
I’m not really comfortable with the KAR process myself, so I can be of limited help, but it sounds as if the feature definitions point to 5.3.0 features, not 5.2.1. That could explain why it includes so many dependencies in the JAR (since they aren’t resolvable “natively”), and why things clash. I’d double-check that you have your features also pointing to the correct version.
A JAR file doesn’t care about features, it simply ignores them. KAR takes features into account. Maybe there’s a problem with the 5.2.1 branch, but it doesn’t cost much to check org.openhab.automation.pythonscripting/src/main/feature/feature.xml. It looks to mostly use variables for versions, so my guess is then that one of those variables are wrong.
In particular, these two variables should be checked: ${ohc.version} and ${project.version}.
The project version inside the pythonscripting addon pom file is 5.3.0-SNAPSHOT
The project version inside the the root pom file is 5.3.0-SNAPSHOT
The ohc.version inside the root pom file is still 5.3.0-SNAPSHOT
so everything looks ok.
But if I compile my unmodified pythonscripting addon bundles/org.openhab.automation.pythonscripting, the KAR file contains theese unneeded OSGI classes.
Ok, then I have no idea. Various things have been upgraded, so this is probably another one of the bugs brought in because of that then. You’ll just have to try to dig in and figure out why they are included when they didn’t use to. I think we upgraded the Karaf version recently, which might have to do with the change in behavior.
It also looks that the last successfull compile from my side was May 4, 2026, when I tested my last contribution before the final release.
Directly after… on May 6, 2026, karaf was updated to 4.4.11. Maybe that rings a bell for someone.
Unfortunately, I can no longer compile that last working version, as it is so old that many other dependencies no longer exist.
So the question is, why are the karaf classes included in the KAR files, as they are not defined as additional dependencies in pythonscripting.
*** UPDATE ***
JSScripting has the same problem. KAR file is ~10MB and includes karaf classes. So it looks, it is not pythonscripting releated. It looks like a general problem.
If you install this KAR file into the addon folder, the karaf classes collides with the already active classes and this stoppes openhab working.
This is exactly why I hate the whole upgrade-mania. It’s so difficult to properly assess what breaks, that by the time you discover it, it’s often no way to back out, and you’re stuck with some new problem that is either unsolvable or require some hefty workarounds.
Since it’s brought on by this upgrade, I’d guess that you can find others that have experienced similar problems outside OH. If you’re lucky, somebody out there already has the explanation, and if you’re really lucky, also the solution. Maybe there’s a new option that must be enabled to not include these files for example.
But as I’m not a maven expert. Maybe someone with more knowledge can double check, that this is the correct solution. … Because, I have no answer, why it works before.
At least for me, the new compiled version works on my production systems. So you can expect a new release of pythonscripting soon
provided is usually a very bad hack that should be avoided unless you know for a fact that it will always be. What it does is say to Maven: “Forget about this dependency, don’t try to resolve or check it, we will make sure that it’s always available. Just take our word for it.” It rarely turns out well.
What is needed is to figure out why the behavior has changed, and how it can be corrected without “hacks” like provided.
