Californium removed?

[Lolodomo]

@Nadahar

This is the same old gotcha with OH - while participation is slim on the forum, it’s even worse on GitHub. I’ve got issues on GitHub that’s never gotten as much as a comment, and PRs can remain untouched for weeks or months.

Maintainers are following GitHub. PRs are reviewed, yes sometimes with delay.
RFC can be sometimes not answered if your request does not interest any contributor.
Your few issues are I believe very technical and in that case require someone with advanced OH skills to be answered. We avoid answering in GitHub if our answer will be of no value. You can add a comment to make them more visible again.

[Lolodomo]

@Nadahar

but at least the public areas seem more or less dead.

During the last month, you can like me see that 56 PRs were merged in core framework and 112 in add-ons. This is not what I call “dead”.

[Nadahar (Nadar)]

@Lolodomo

PRs are reviewed, yes sometimes with delay.

I have no problem with the reviews themselves taking some time, I’ve done quite a few myself, and it can be a lot of work. But, some feedback, thoughts, whether it is wanted or not, potential conflicts etc. would be very helpful in that you get a feeling that you’re just not posting into a void.

@Lolodomo

RFC can be sometimes not answered if your request does not interest any contributor.

This I think is problematic, somebody should at least find the time to answer that “there is no interest and don’t expect to get an answer”.

@Lolodomo

Your few issues are I believe very technical and in that case require someone with advanced OH skills to be answered. We avoid answering in GitHub if our answer will be of no value.

I would probably have made many more had there been any response. As it is now, it just feels futile, like a waste of time. I guess that’s part of the problem with GitHub, it’s a bit “too formal”, and you’re not supposed to say anything unless you have something useful to contribute. The result is that things are just “left to rot”, with no hints as to what approach “might make it more interesting” or no discussion as to whether this is something to care about or not.

@Lolodomo

You can add a comment to make them more visible again.

Sure, you can make a fuzz and maybe get some attention. But, for me personally at least, that’s not desirable. I don’t want to “push my will”, so if there’s no interest in what I have to offer or suggest, I normally won’t try to “force” it. It feels disrespectful to “bumb your way”, just as it feels disrespectful to be ignored.

@Lolodomo

During the last month, you can like me see that 56 PRs were merged in core framework and 112 in add-ons. This is not what I call “dead”.

I’m not saying that OH is dead, I can clearly see that there’s a lot of activity. I’m just saying that the public facing part of GitHub feels quite dead, at least from my point of view. I don’t know why this is, if it’s because things are agreed upon in some hidden forum, it people use other forms of communication or PMs, or if it simply depends on who you are. “From the outside” all I can do is guess.

What I know is that I have quite a lot of code that I wrote during the winter that I’ve decided not to even try to offer using a PR. I’ve even given up finishing it, because it seems like a waste of time. When I can’t get simply things through, it feels completely unrealistic to get more sophisticated/complex things through. With no communication, it’s also impossible to get the necessary “guidance” as to what direction to choose when making changes. Which makes it even less likely to ever be merged.

So, my description of “dead” isn’t about OH itself, but about the process you’re supposed to follow to contribute/get things fixed. Maybe it’s just me, but I at least have given up. The only thing I’ve had any success with is very, very tiny fixes.

[Lolodomo]

You gave up too fast I believe.
I will open all your issues again and see if I can be of any help

[Nadahar (Nadar)]

BndTools might not be a problem anymore, since 7.2 was released yesterday: 7.2.0-20250427

From the Oomph setup file, I found:

      <repository
          url="https://bndtools.jfrog.io/bndtools/update-latest/"/>
      <repository

…which I assume means that as of now, 7.2 is installed, which should have the fix. Somebody should probably verify that it works though.

[Nadahar (Nadar)]

Regarding the PDE connector problem, I’m not sure at all, but I suspect that the problem might be a result of this commit:

https://github.com/eclipse-m2e/m2e-core/commit/c464287c68fe7930c95cc133c3ae6c36de4346fc

As such, it would be useful to see if this problem exists in M2E 2.7 also, or if it’n new M2E 2.8, which the above commit is a part of.

[Nadahar (Nadar)]

@markus7017

To avoid installing the Maven for Eclipse (M2E) PDE integration with Eclipse Oomph

I’ve been trying to figure out how to tweak the Oompg config to not install the PDE Integration, but I’m struggling to understand exactly where it’s coming from. I think it’s in here somewhere:

    <setupTask
        xsi:type="setup:VariableTask"
        id="eclipse.target.platform"
        name="eclipse.target.platform"
        value="Full"/>
    <setupTask
        xsi:type="setup.p2:P2Task">
      <requirement
          name="org.eclipse.wst.xml_ui.feature.feature.group"/>
      <requirement
          name="org.eclipse.m2e.feature.feature.group"/>
      <requirement
          name="org.eclipse.m2e.logback.feature.feature.group"/>
      <requirement
          name="org.eclipse.wst.jsdt.feature.feature.group"/>
      <requirement
          name="org.eclipse.wst.web_ui.feature.feature.group"/>
      <requirement
          name="bndtools.m2e.feature.feature.group"/>
      <requirement
          name="org.lastnpe.m2e.feature.feature.group"/>
      <requirement
          name="com.ianbrandt.tools.m2e.mdp.feature.feature.group"/>
      <requirement
          name="org.sonatype.m2e.buildhelper.feature.feature.group"/>
      <repository
          url="https://bndtools.jfrog.io/bndtools/update-latest/"/>
      <repository
          url="https://github.com/tesla/m2eclipse-buildhelper/releases/download/latest/"/>
      <repository
          url="https://ianbrandt.github.io/m2e-maven-dependency-plugin/"/>
      <repository
          url="https://www.lastnpe.org/eclipse-external-annotations-m2e-plugin-p2-site/m2e_2/"/>
    </setupTask>

..but they have made it hard to figure out what these “features” really contain. Maybe it comes from the “Full” eclipse.target.platform for all I know. It’s not obvious to me how to exclude single components, especially when I haven’t even found exactly what is pulling it in.

[wborn (Wouter Born)]

@Nadahar

<requirement
          name="bndtools.m2e.feature.feature.group"/>

This “requirement” adds all that bndtools bundles.

Looks like you can also set a version range to prevent the buggy version from being installed:

EclipseSource.setup

[Nadahar (Nadar)]

@wborn

This “requirement” adds all that bndtools bundles.

There’s one fundamental thing that eludes me here: There are two different, conflicting configurations for bnd-maven-plugin (this is what’s causing the error). I don’t know how this came to be, but this seems to be a problem that exist outside of OH. Both bndtools.m2e and org.eclipse.m2e.pde.connector has their own definition.

In my slightly older setup, org.eclipse.m2e.pde.connector wasn’t installed, so I assume that we don’t actually need this - which is why the “simplest fix” seems to be to not install it. But, for this to make any sense, there must be two different teams working, without coordination, that has caused this conflict in the first place. I assume that the “M2E team” is behind org.eclipse.m2e.pde.connector and the “Bnd team” is behind bndtools.m2e. That might be wrong though, I’m only trying to make sense of it. But, if that’s the case, isn’t it strange that these artifacts/components are pulled in by the same feature definition? If that’s the case, it would mean that this is currently broken for everybody that use this “feature group”. Shouldn’t that have been discovered and corrected already if that’s the case?

In any case, my assumption is that these two conflicting components are pulled in by different “feature groups”, but since I haven’t been able to figure out exactly what comes with what, I can’t verify my assumption.

I’m not sure we can easily avoid it by locking the setup to a previous version, especially when it’s not clear exactly where this stems from. If we could find the exact change that lead to this, it would be easier to know “what to avoid” - now it would have to come down to “randomly” trying to fix different versions and find a combination that works. But, such a solution would likely be short lived, as other things are pulled in by the latest version, and I bet it wouldn’t take too long before the combination of “latest” for some components and a specific version for others would break.

[markus7017 (Markus Michels)]

@Nadahar

From the Oomph setup file, I found:

      <repository
          url="https://bndtools.jfrog.io/bndtools/update-latest/"/>
      <repository

…which I assume means that as of now, 7.2 is installed, which should have the fix. Somebody should probably verify that it works though.

Nope, a fresh install this morning also install BND 7.1

I checked JFrog and it does not include release 7.2.0, so Frog seems not yet updated.

Also Releases · bndtools/bnd · GitHub does not show release 7.2.

[Nadahar (Nadar)]

@markus7017

I checked JFrog and it does not include release 7.2.0, so Frog seems not yet updated.

Also Releases · bndtools/bnd · GitHub does not show release 7.2.

You’re right, it can’t be “officially released” yet. But, more or less all the bndtools packages got a 7.2 version April 27, so when I saw that, I just assumed that it was actually released. Looking closer at those packages, it turns out they are just “snapshots”, so they don’t say anything about when 7.2 will be released. I’m sorry for jumping the gun.

[markus7017 (Markus Michels)]

no problem, once there is a RC1 I could try that to see if the problem is fixed

[Nadahar (Nadar)]

When I look at their release schedule in the past, it’s often quite a long time between releases. Since this is a known flaw that breaks a lot of stuff, I don’t understand why they can’t do a 7.1.1 release with this fix, instead of letting things stay broken for a long time. It’s quite frustrating, it’s this kind of attitude that makes it so frustrating to work with many of these open-source tools.

So, I don’t think we can wait for it, 7.2 could arrive next week or next year. I think we must try to lock the version for bndtools to 7.0 in the meantime.

[Nadahar (Nadar)]

I’ve set up a Windows 10 VM where I’ve made a snapshot before running the Eclipse installer. I then do an installation and then reset everything by reverting to the snapshot. It’s a bit cumbersome, but this way I know that everything I see is from this one installation.

I’ve been tweaking the Oomph file slightly, and this is my findings this far:

      <!--requirement
          name="org.eclipse.m2e.feature.feature.group"/-->

Commenting out this one results in an installation without the M2E PDE integration, but it’s also without most other parts of M2E. So, omitting it obviously isn’t an option, this was only to confirm that this indeed is the “source” of the problematic M2E PDE connector. I still have no idea how to exclude specific packages from such a “feature group”.

      <requirement
          name="bndtools.m2e.feature.feature.group"
		  versionRange="[7.0.0,7.1.0)"/>

This does not work as I hoped, instead the installation is aborted by the following error:

ERROR: org.eclipse.equinox.p2.director code=10053 Cannot complete the install because one or more required items could not be found.
  at org.eclipse.oomph.util.OomphPlugin.coreException(OomphPlugin.java:296)
  at org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl.resolve(ProfileTransactionImpl.java:446)
  at org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl.commit(ProfileTransactionImpl.java:356)
  at org.eclipse.oomph.setup.p2.impl.P2TaskImpl.perform(P2TaskImpl.java:916)
  at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.doPerformNeededSetupTasks(SetupTaskPerformer.java:3876)
  at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performNeededSetupTasks(SetupTaskPerformer.java:3804)
  at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.performTriggeredSetupTasks(SetupTaskPerformer.java:3785)
  at org.eclipse.oomph.setup.internal.core.SetupTaskPerformer.perform(SetupTaskPerformer.java:3663)
  at org.eclipse.oomph.setup.ui.wizards.ProgressPage$9.run(ProgressPage.java:592)
  at org.eclipse.oomph.setup.ui.wizards.ProgressPage$11$1.run(ProgressPage.java:721)
  at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
  ERROR: org.eclipse.equinox.p2.director code=0 Software being installed: artificial_root 1.0.0.v1746049006222
  ERROR: org.eclipse.equinox.p2.director code=0 Missing requirement: Bndtools m2e 7.0.0.REL-202310060912-gb82dc86 (bndtools.m2e.feature.feature.group 7.0.0.REL-202310060912-gb82dc86) requires 'org.eclipse.equinox.p2.iu; org.eclipse.m2e.feature.feature.group 2.0.0' but it could not be found
  ERROR: org.eclipse.equinox.p2.director code=1 Cannot satisfy dependency:
    ERROR: org.eclipse.equinox.p2.director code=0 From: artificial_root 1.0.0.v1746049006222
    ERROR: org.eclipse.equinox.p2.director code=0 To: org.eclipse.equinox.p2.iu; bndtools.m2e.feature.feature.group [7.0.0,7.1.0)

The above error turned out to be because the Eclipse installer had defaulted to install Eclipse Neon for some strange reason, and those packages didn’t exist back then and thus couldn’t be found. When using 2025-03 instead, it worked.

[Nadahar (Nadar)]

With this modification to the Oomph file, it turns out to work when I’m testing:

      <requirement
          name="bndtools.m2e.feature.feature.group"
		  versionRange="[7.0.0,7.1.0)"/>

The full section I changed is here

    <setupTask
        xsi:type="setup.p2:P2Task">
      <requirement
          name="org.eclipse.wst.xml_ui.feature.feature.group"/>
      <requirement
          name="org.eclipse.m2e.feature.feature.group"/>
      <requirement
          name="org.eclipse.m2e.logback.feature.feature.group"/>
      <requirement
          name="org.eclipse.wst.jsdt.feature.feature.group"/>
      <requirement
          name="org.eclipse.wst.web_ui.feature.feature.group"/>
      <requirement
          name="bndtools.m2e.feature.feature.group"
		  versionRange="[7.0.0,7.1.0)"/>
      <requirement
          name="org.lastnpe.m2e.feature.feature.group"/>
      <requirement
          name="com.ianbrandt.tools.m2e.mdp.feature.feature.group"/>
      <requirement
          name="org.sonatype.m2e.buildhelper.feature.feature.group"/>
      <repository
          url="https://bndtools.jfrog.io/bndtools/update-latest/"/>
      <repository
          url="https://github.com/tesla/m2eclipse-buildhelper/releases/download/latest/"/>
      <repository
          url="https://ianbrandt.github.io/m2e-maven-dependency-plugin/"/>
      <repository
          url="https://www.lastnpe.org/eclipse-external-annotations-m2e-plugin-p2-site/m2e_2/"/>
    </setupTask>

I’ve done a clean install using the above file on a “clean” Windows 10 VM where I enabled “openHAB Development” and “openHAB Add-ons”. After installation, I imported the shelly binding as a project, added it to the “demo app”, resolved and ran it. No errors, and the binding showed up as installed.

I then did the same on a macOS 12 VM, in case this was an issue specific to macOS, but the result was the same.

Neither of these installations have the “M2E PDE Connector”, and thus they don’t suffer from the conflicting configuration. This is very mysterious to me, since the only difference is that Bndtools are held back to 7.0. Why should that impact whether “M2E PDE Connector” is installed? I have no idea, but it seems to work with this tweak.

[markus7017 (Markus Michels)]

Interesting progress

Could you provide me the modified config file and how to use/integrate it? Then I could try in my setup.

Could you check if the checkbox Eclipse:Settings:Maven:Download Artifact Javadoc is ticked? I have to do this manually, otherwise I get an error in the header section of binding‘s pom.xml, because external downloads of the schema files are disabled.

From my pov the installation should reference a specific bnd version, not latest. Who knows if 7.2 works as expected or has some other side effects.

[Nadahar (Nadar)]

@markus7017

Could you provide me the modified config file and how to use/integrate it? Then I could try in my setup.

Here is the file itself. I had to add .txt for the forum to accept it, remove that again after downloading, it’s supposed to be called just openHAB2.setup.

openHAB2.setup.txt (219.5 KB)

After having saved the file somewhere, you start the Eclipse Installer as usual, select “Eclipse IDE for Java developers”, Next and then when you get here:

..you click the little + button that I’ve tried to point out, which leads to this dialog:

Select “Github Projects” under “Catalog” (it won’t work without something there), and either Browse File System or enter/paste the full URL to the .setup file. After clicking OK, you will have a new openHAB project under <User>, and this is the tweaked .setup file. Select and continue as usual from there.

@markus7017

Could you check if the checkbox Eclipse:Settings:Maven:Download Artifact Javadoc is ticked? I have to do this manually, otherwise I get an error in the header section of binding‘s pom.xml, because external downloads of the schema files are disabled.

It’s not ticked, at got the same behavior on macOS (not Windows AFAICR), what I did is go to the POM in Eclipse, hover over the URL address that’s underlined in red, and then an option “Force download..” showed up. I clicked that, and the error was gone.

@markus7017

From my pov the installation should reference a specific bnd version, not latest. Who knows if 7.2 works as expected or has some other side effects.

The problem with that is that everything else points to “latest”. If you lock down the version of just one component but let the others use the latest, problems are bound to occur some time in the not to distant future. If you locked down everything with compatible versions, it would continue to work, but you would miss “new features” like Java 24 support etc. once they become available.

I also hate the “latest” strategy, because it is so random and everybody basically have to be beta-testers for everything. But, you can’t have it both ways, so unless somebody would like to maintain a “known good combination” of versions, I think “latest” is the only realistic option long term. But, it means that users will be bitten by new bugs as they arrive..

[Nadahar (Nadar)]

@markus7017 Did you get a chance to test this? If it works, I could submit a PR with the “fix”.

[Nadahar (Nadar)]

I’d like to add that I have tested my “fix” on both Windows 10 and macOS VMs, so I’m relatively confident that it works. I’d like if @markus7017 could also test it before creating a PR, but if that doesn’t happen, should I still create a PR?

It’s not ideal if the documented setup of a development environment currently doesn’t work.