How to make a local snapshot build

Development IDE & Build
1

I’m using the Eclipse dev environment, and it works fine for most things. But, the lack of some of the Karaf stuff makes it difficult at times. So, I want to be able to debug “a real installation”.

I’ve figured out that by starting a snapshot using start_debug, I can attach Eclipse’s debugger to the reported port and debug from Eclipse. However, for that to be useful, I need to build a “snapshot” using my local checked out code for core, addons, UI etc.

I’ve tried running mvn package from openhab-distro, but it seems to ignore my locally installed Maven artifacts and always pull them from the online snapshot repo. This is quite useless, I want to debug code that I have modified.

There must be a way to run “full OH”, in a Karaf environment, from locally built artifacts. I would think that was how those of you that don’t run Eclipse do it anyway - I just can’t seem to figure out how it’s supposed to be done.

What am I missing, how do I launch my local OH code without using “demo app”?

2

It seems that it does indeed use my locally installed Maven artifacts, it’s just that I unpacked it in the same location as a previous attempt, overwriting files. Apparently, that isn’t enough, probably because the bundles are already “installed” thus the old versions keep being used.

I’m not that familiar with Karaf, is there an easy way to “clear” this cache/force it to “reinstall all bundles”, or do I have to just wipe the folder structure completely between each go? The reason I ask is that when deleting the folder, I have to go through the startup wizard, create user, configure everything etc. each time I want to test updated code. It would be much easier if I could keep the configuration but only replace the code/bundles.

3

I’m somewhat surprised that there’s no response to this. All you that don’t use Eclipse out there must have a way to run/debug OH for testing what you’re doing, so I would expect some routine to exist already. Are everybody using the “demo app”, also those not using Eclipse?

I’ve come up with the following changes to make running a “full Karaf debug version” of OH less labor-intensive:

 distributions/openhab/pom.xml | 44 +++++++++++++++++++++++++++++++++++++++++++
 distributions/pom.xml         | 26 +++++++++++++++++++------
 pom.xml                       |  8 ++++++++
 3 files changed, 72 insertions(+), 6 deletions(-)

diff --git a/distributions/openhab/pom.xml b/distributions/openhab/pom.xml
index 62bdf6e..276e2f8 100644
--- a/distributions/openhab/pom.xml
+++ b/distributions/openhab/pom.xml
@@ -280,4 +280,48 @@
     </plugins>
   </build>
 
+  <profiles>
+    <profile>
+      <id>dev</id>
+      <build>
+        <plugins>
+          <plugin>
+            <artifactId>maven-clean-plugin</artifactId>
+            <executions>
+              <execution>
+                <id>delete-runtime</id>
+                <goals>
+                  <goal>clean</goal>
+                </goals>
+                <phase>initialize</phase>
+                <configuration>
+                  <excludeDefaultDirectories>true</excludeDefaultDirectories>
+                  <filesets>
+                    <fileset>
+                      <directory>target/${project.artifactId}-${project.version}/runtime</directory>
+                    </fileset>
+                  </filesets>
+                </configuration>
+              </execution>
+            </executions>
+          </plugin>
+          <plugin>
+            <groupId>org.apache.maven.plugins</groupId>
+            <artifactId>maven-assembly-plugin</artifactId>
+            <executions>
+              <execution>
+                <id>archive</id>
+                <configuration>
+                  <formats>
+                    <format>dir</format>
+                  </formats>
+                </configuration>
+              </execution>
+            </executions>
+          </plugin>
+        </plugins>
+      </build>
+    </profile>
+  </profiles>
+
 </project>
diff --git a/distributions/pom.xml b/distributions/pom.xml
index 1ce55bc..fcf188b 100644
--- a/distributions/pom.xml
+++ b/distributions/pom.xml
@@ -15,11 +15,25 @@
 
   <name>openHAB Distributions</name>
 
-  <modules>
-    <module>openhab-addons</module>
-    <module>openhab-demo</module>
-    <module>openhab</module>
-    <module>openhab-verify</module>
-  </modules>
+  <profiles>
+    <profile>
+      <id>dev</id>
+      <modules>
+        <module>openhab</module>
+      </modules>
+    </profile>
+    <profile>
+      <id>default</id>
+      <activation>
+        <activeByDefault>true</activeByDefault>
+      </activation>
+      <modules>
+        <module>openhab-addons</module>
+        <module>openhab-demo</module>
+        <module>openhab</module>
+        <module>openhab-verify</module>
+      </modules>
+    </profile>
+  </profiles>
 
 </project>
diff --git a/pom.xml b/pom.xml
index 4c7c286..a9e7317 100644
--- a/pom.xml
+++ b/pom.xml
@@ -285,6 +285,14 @@
         <pax.url.suffix/>
       </properties>
     </profile>
+    <profile>
+      <id>dev</id>
+      <properties>
+        <build.number>- development build -</build.number>
+        <online.repo>${oh.repo.releaseBaseUrl}/libs-snapshot</online.repo>
+        <pax.url.suffix>@snapshots</pax.url.suffix>
+      </properties>
+    </profile>
   </profiles>
 
 </project>

This creates a Maven dev profile that, when used, tweaks the build of the “distro” quite a bit, making it both much faster and more convenient.

First, it makes sure that only the openhab module is built, not openhab-addons, openhab-demo and openhab-verify. This is where most of the time saving lies, particularly in skipping the add-ons I assume. It means that making “a new Karaf build” takes only 30–40 seconds, assuming that the artifacts that you want to use are already installed in your local Maven repo. Those that aren’t found in your local Maven repo will be downloaded from “the latest jfrog snapshot”, so to use your own code, make sure to install them (`mvn clean build -pl :) from the repositories where they live first.

The second thing it does is to alter the assembly, so that instead of producing .zip and .tar.gz archives, a folder is generated under openhab-distro/distributions/openhab/target. The folder will be called whatever the version you’re building is, e.g. openhab-5.0.0-SNAPSHOT. In this folder, there’s a full Karaf “installation” of OH, that can be run directly from there. No moving/copying and extraction of files are required.

Since I haven’t gotten an answer to OSGi framework lifecycle, I have peeked at what the upgrade script does, and it seems to be merely to delete the whole runtime folder. This is necessary to prevent old versions of the bundles to be used when starting Karaf, since they are cached. So, the dev Maven build also deletes the runtime folder, so that when you start Karaf, it will always use the latest versions of the bundles. But, crucially, the rest of the system configuration remains intact, so you don’t have to create a user and configure stuff for each build.

So, to wrap it up, all I do is (from the openhab-distro repo):

 mvn package -Pdev

When that’s completed, the folder is created and ready to run. Please note that I don’t use clean, as that would erase the whole target folder and the configuration of this “OH installation” with it. I also use package because there’s no point in trying to “install” this in the local Maven repo - and it would also fail because a folder isn’t supported for installation (it has to be some kind of archive).

Then, from openhab-distro/distributions/openhab/target/openhab-5.0.0-SNAPSHOT (or what corresponds to the version you’re building) I simply run:

.\start_debug

…and OH starts with port 5005 available for debugging. I can then attach Eclipse’s debugger, and I assume and other compatible debugger, to localhost:5005 and work with breakpoints, watch etc.

If there is any interest in making this available to others, I could create a PR for “distro”…? All my changes only apply if one activates the dev profile, so it should have no implications for any existing routines/automated builds that exist.

4

What I did the last time I needed to do this, I build the Distro in the openhab-distro repo, then mvn installed my local bundles, and rebuild the distro.
This worked fine for me.

See Generic IDEs hints | openHAB. I followed this guide.

BTW there is also an Eclipse guide: Eclipse IDE | openHAB

5

Absolutely yes!

6

Thanks. I’m not sure the first you need to do the first “distro build” though. The build should automatically download any artifacts not found in your local repo.

I’m fairly familiar with the Eclipse guide, and I had some vague memory that the others existed as well, but I couldn’t actualy find them in the documentation when I tried recently (don’t ask how I managed to not find them).

Looking through the different guides, they all seem to do things slghtly differently. I must say that the Eclipse workflow is many times better once you get Eclipse to play ball - but that can be challenging because of the build loops with certain bundles and some other “strangeness”, particularly with BndTools.

The procedure I’ve found can be used independent of IDE, but from the guides it seems like both IntelliJ and VSCode can be used as debuggers in the same way as Eclipse, even though the way you configure the debuggers are different.

Debugging a “full Karaf installation” might not be required that often, but when you need it, it’s very much easier than trying to “guess”/imagine how the system works under Karaf.

It does require two builds after every code change (the bundle you modified + “distro”), but both builds should normally be fairly quick. Compared to the “normal Eclipse workflow” where you don’t have to do anything, you just edit the code and press F11 and it starts up using your new code, this is very “primitive”, but from what I see in the guides, it might not be that much different from the “demo app experience” with the other IDEs.

Ok, I’ll do that then. Ideally some documentation should be made to make it more accessible, but I’m not sure if I’m up to making that right now. I’ll see if I can convince myself to at least do something to let people know it’s there…

1 Like
7

PR created:

…and documentation:

1 Like
8

Thanks! Will take a look, but I am soon heading out to Aegypt, so will likely be in two weeks. The time till then I will focus on a few other openHAB things first-