Just so I’m sure I understand correctly, this problem is only when trying to build 4.x?
No, also with OH5, both fresh installs/clones
I notice that https: //bndtools.jfrog.io/bndtools/update-latest/ is used as update site, so not a specific version.
I created the OH4 setup by
- IDE setup for OH5
- then switch to the 4.3.x branch
which means in fact the IDE setup is derived from the OH5 repo.
I wouldn’t think that should make a difference, unless there is some incompatibility between BND versions and Eclipse plugin versions or similar…?
I’ll try to include the shelly binding in my current OH5 setup and see if I can make it run.
I think it‘s not related to the Shelly binding. I tried AVM Fritz and had the same problem. It must be something with the IDE setup, because the binding builds using cli
Yeah, but it’s a bit strange considering that you have done so many different IDE setups?
The “lifecycle mapping” issue does sound like a M2E problem, so you’re probably correct that it is some issue relating to M2E/Eclipse.
I need just one working 
(I meant that I did this 100 times in the past, not having 100 active ones :-))
It works without problems in my setup. I can’t test the binding because I don’t have any shelly devices, but the binding shows up, I can add devices manually, and in general: there’s nothing that indicates any problem.
I’m running:
- Eclipse
20241128-0757. - Bndtools
7.0.0.REL-202310060912-gb82dc86 - M2E
2.7.0.20241126-1642
ok, the automated setup is using bnd 7.1
I‘ll try to downgrade
I think that will most likely fix it. There’s a problem with 7.1 that has been fixed, but the fix won’t be released until 7.2 is released:
As I understand it, 7.1 is “broken”. This issue has also been discussed on this forum earlier:
that‘s what I remembered, but thought this is fixed in between, let‘s see
Just to be sure, this is the “problem”, right?
Have you tried to open the pom.xml in org.openhab.binding.shelly? When I look in mine, there’s nothing at line 7. I’m wondering where this “conflicting mapping” comes from.
mine looks like
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.openhab.addons.bundles</groupId>
<artifactId>org.openhab.addons.reactor.bundles</artifactId>
<version>5.0.0-SNAPSHOT</version>
</parent>
<artifactId>org.openhab.binding.shelly</artifactId>
<name>openHAB Add-ons :: Bundles :: Shelly Binding</name>
<properties>
<bnd.importpackage>org.eclipse.jetty.websocket.server</bnd.importpackage>
</properties>
</project>
so line 7 is the tag
Yeah, line 7 is <parent>
That line shouldn’t be very controversial or have a lot of potential for errors. Maybe it means that the “conflicting mapping” is somehow brought in by the parent POM. But, this doesn’t really make sense to me. I don’t think any of OHs POMs define M2E lifecycle mappings, at least not that I’ve seen.
Does the error still refer to Bnd 7.1, or is the new error reporting 7.0?
When you do Maven → Update Project, do you do that on the binding project, or on the “demo app” project? I’ve had luck at clearing up “strange errors” by selecting all open projects when doing “Update project”. It takes a while, but it can sometimes be what’s needed.
Now it’s complaining about something completely different, a xml-maven-plugin plugin. This sounds fishy, I’d recommend doing Maven → Update Project for all projects, and make sure that “Clean project” is enabled.
I tried OH5
- fresh install as usual
- downgrade to BND Tools 7.0
- Import Shelly binding as existing Maven project
- mvn clean install -T1C -DskipTests -DskipChecks -Dspotless.check.skip=true
- Maven:Update Project
- Project:Clean all projects
- I’m able to add the Shelly binding to demo app’s pom.xml, resolve dependencies is successful and the binding starts
- So even Eclipse shows the lifecycle mapping error I’m able to start and debug the binding
and OH4 (separate folder/instance of Eclipse)
- fresh install as usual from OH5 repo, downgrade to BND Tools 7.0
- Import Shelly binding as existing Maven project
- switch binding and demo app to 4.3.x branch
- change to 4.3.5-SNAPSHOT in demo app’s pom.xml (maybe that should be fixed by default)
- mvn clean install -T1C -DskipTests -DskipChecks -Dspotless.check.skip=true
- Maven:Update Project
- Project:Clean all projects
- Resolving dependencies work
- I’m able to add the binding to demo app’s pom.xml (manually), but afterwards I can’t search for it to add it to the dependencies
- Finally I’m not able to start and debug the binding
In both scenarios
- binding builds successful on cli
- Eclipse shows the Conflicting lifecycle mapping
- In OH5 I’m able to start+debug the binding (ignoring the error), in OH4 not
I noticed this when clicking on shelly pom->xml:parent->ignore (OH4)
For me that means
- all good when building on cli level
- something must be wrong in the lifecycle definition of the parent project, which causes that problem in Eclipse
Could anybody do a fresh install of the Eclipse IDE and verify that this doesn’t show any errors in the IDE?
Which repos do you run mvn clean install on? It’s not clear to me which repos you have checked out either. In my case core is among them, and core is the one that takes some time for which to run this.
If you don’t check out core, it means that it will have to download the 4.3.5-SNAPSHOT artifacts from a snapshot repository. If there is a problem with these files, you could get all kind of errors.
When I have all the repos locally and build/install them, I don’t have to worry about if there’s a problem with the artifacts on the snapshot repository.
This wasn’t what I meant. Instead, I meant that you’d click “Select All” in this window, and make sure that “Clean projects” were selected. I actually enable “Offline” as well when I run this. This is to avoid that Maven should get the idea that some of the snapshots in the snapshot repo is more recent than the ones I’ve built myself. That can only lead to problems, so I find that using “Offline” gives a less error-prone process.
I don’t follow - why do you click on “ignore” here? You shouldn’t have to do that, it indicates some kind of problem, and they rarely go away by being ignored, instead they will show up somewhere else.
I’m sorry, I’m not very keen on this. I generally don’t reinstall software when I have a problem, I try to solve it instead, and I fought with the OH Eclipse installation for quite a while before I got it to behave like I want to, it took days, and I don’t even remember all the things I did. Thus, I’m not keen on throwing this away now that I have it working. Also, checking out and building Core as part of the installation process takes hours…
It’s probably caused by:
If there is no m2e support for it you can tell it to be ignored here: