That seems very likely, yes. I haven’t updated my addons since this was merged, which probably explains why I haven’t experienced it. If so, the “ignore” lifecycle mapping should definitely be merged as well, so that people don’t all have to deal with this themselves.
I’ve updated my addons repo, and I now have all kind of build problems. Currently I’m fighting with minidns:
[ERROR] Failed to execute goal on project org.openhab.binding.ecovacs: Could not resolve dependencies for project org.openhab.addons.bundles:org.openhab.binding.ecovacs:jar:5.0.0-SNAPSHOT
[ERROR] dependency: org.minidns:minidns-core:jar:0.3.4 (compile)
[ERROR] org.minidns:minidns-core:jar:0.3.4 was not found in https://openhab.jfrog.io openhab/libs-release during a previous attempt. This failure was cached in the local repository and resolution is not reattempted until the update interval of openhab-release has elapsed or updates are forced
I have no idea why it wants 0.3.4 because 0.3.3 is specified everywhere I can find in OH. But, the dependency tree shows this:
[INFO] org.openhab.addons.bundles:org.openhab.binding.ecovacs:jar:5.0.0-SNAPSHOT
[INFO] +- org.igniterealtime.smack:smack-tcp:jar:4.3.3:provided
[INFO] | \- org.igniterealtime.smack:smack-core:jar:4.3.3:compile
[INFO] | +- xpp3:xpp3:jar:1.1.4c:compile
[INFO] | +- org.jxmpp:jxmpp-core:jar:0.6.4:compile
[INFO] | | \- org.jxmpp:jxmpp-util-cache:jar:0.6.4:compile
[INFO] | +- org.jxmpp:jxmpp-jid:jar:0.6.4:compile
[INFO] | \- org.minidns:minidns-core:jar:0.3.4:compile
…which seems to indicate that org.igniterealtime.smack:smack-core:4.3.3 required 0.3.4, but when I try to look at smack, all I can find is this:
I really don’t know how gradle resolves a range into a specific version, but something is off here. Can anybody shed some light on this?
What do you mean with “If there is no m2e support for it”?
" tell it to be ignored" how? remove the line?
Maven plugins need a separate “definition” to work with M2E. Plugins can embed this definition, in addition M2E provides definitions for many commonly used plugins. But if you come across a plugin that isn’t covered by M2E and that lacks any embedded definitions, you will get an error in Eclipse. You can then make that definition yourself in the project POM. Usually, the “fix” is to simply ask M2E to ignore the plugin. It would be suitable here for example, where the problem is the xml-maven-plugin. It’s used for validating XML files during build, there’s no need to do this each time Eclipse wants to rebuild. So, ignoring would be fine.
I’m trying to figure out how to make this definition. It should be added to the addons repo so that people don’t have to do it themselves. But, since I’m currently stuck on a different error, I can’t verify if my “fix” works.
After a lot of building and cleaning, the minidns error is gone. Using ranges is highly “unstable”, what I think happened is that Maven somehow figured out that 0.3.4 existed and was in the valid range. But, it’s not available at the OH jfrog repo - so it failed to fetch it from there. Exactly why it gave up in the end and “reresolved” or 0.3.3 is a mystery to me, but once it did, things started to resolve.
I’ve made a change to the addons’ POM that seems to get rid of the error related to xml-maven-plugin:
pom.xml | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/pom.xml b/pom.xml
index cf36b1f5e2..7d717ad3ef 100644
--- a/pom.xml
+++ b/pom.xml
@@ -763,6 +763,19 @@ Import-Package: \\
<execute/>
</action>
</pluginExecution>
+ <pluginExecution>
+ <pluginExecutionFilter>
+ <groupId>org.codehaus.mojo</groupId>
+ <artifactId>xml-maven-plugin</artifactId>
+ <versionRange>[1.0.0,)</versionRange>
+ <goals>
+ <goal>validate</goal>
+ </goals>
+ </pluginExecutionFilter>
+ <action>
+ <ignore/>
+ </action>
+ </pluginExecution>
</pluginExecutions>
</lifecycleMappingMetadata>
</configuration>
I’ve created a PR with the above “fix”, it seems to resolve the issue for me at least. It might be a good idea if @markus7017 tests whether this PR solves it for you as well.
1 Like
ok, one problem is gone 
@Nadahar much appreciated
the lifecycle mapping problem still remains, any idea how to fix this?
Please note: I checkout out only the openHAB Addoons and openHAB Development repos, as always in the past.
I don’t quite understand what it’s complaining about. Can you paste the full error as it looks now?
There is a possibility to override the lifecycle mapping manually. I still have no idea why you have a conflicting mapping (since I don’t), but the “manual override” file can be found in
<eclipse workspace folder>/.metadata/.plugins/org.eclipse.m2e.core/lifecycle-mapping-metadata.xml
It can also be found using Window → Preferences → Maven → Lifecycle Mappings. Here you can see the path to your mapping file, and you can choose to open it in Eclipse using the button Open workspace lifecycle mappings metadata. Maybe this file can shed some more light on the issue.
A similar problem is discussed here: Bndtools.m2e and e(fx)clipse do not work together in eclipse Photon · Issue #2904 · bndtools/bnd · GitHub
Your problem seems to be with bnd-maven-plugin:bnd-process.
bndtools.m2e:7.1.0 has the following “embedded” configuration:
..while m2e itself als has a configuration:
So, my question is really why this isn’t a problem for others, as they really do seem to conflict. I have no idea which one is “the correct one”, it seems that the configurator is what differs.
I finally managed to get the error too:
Conflicting lifecycle mapping (plugin execution "biz.aQute.bnd:bnd-maven-plugin:7.1.0:bnd-process (execution: default, phase: process-classes)"): Mapping defined in 'bndtools.m2e_7.0.0.202310060912 [18]' and 'org.eclipse.m2e.pde.connector_2.2.0.20241001-1350 [1299]'. To enable full functionality, remove the conflicting mapping and run Maven->Update Project Configuration. pom.xml /org.openhab.binding.shelly line 7 Maven Project Build Lifecycle Mapping Problem
As I pointed out above, there is indeed a conflict. But, when investigating, I didn’t have the “M2E PDE Integration” installed. Once I installed it in Eclipse manually, I get the same error. So, the problem seems to be to have “M2E PDE Integration” and “Bndtools” installed at the same time.
There must be some flaw somewhere here though, because to me, it seems natural that people install “Bndtools” when they use bnd-maven-plugin, so I don’t see why “M2E PDE Integration” has its own definitions for the plugin. That said, I have no idea what “M2E PDE Integration” is/does either. All its description says is:
m2e PDE - Maven Integration for Eclipse Plugin Development adds Maven integration to PDE for a more seamless integration.
Seamless integration sounds great, but of what?
Regardless, I’m pretty sure that the error will go away if you uninstall “M2E PDE Integration”. Assuming that you didn’t install this manually, the question is what has changed to make this a part of the “automated” installation now but not in the past (it seems that the conflict between the two plugins has been there for years).
Eclipse PDE is described as:
The Eclipse PDE™ (Plug-in Development Environment) provides tools to create, develop, test, debug, build and deploy Eclipse plug-ins, fragments, features, update sites and RCP products.
PDE also provides comprehensive OSGi tooling, which makes it an ideal environment for component programming, not just Eclipse plug-in development.
1 Like
Mission accomplished 
after uninstalling M2E PDE
this gets installed when running the ide setup from the current installer
this means
- install IDE
- uninstall bnd 7.1
- uninstall M2E PDE
- install bnd 7.0
- Maven:Update Project
2 Likes
The question somebody should probably answer is why M2E PDE is now suddenly installed by default, that can’t have been the case in the past since this problem hasn’t been there.
Could be a change made by Eclipse and is not related to openHAB.
I don‘t know who maintains the setup mechanism in Eclipse, but maybe there is an option to automatically uninstall M2E PDE
Otherwise, the developer documentation needs to be updated, it‘s outdated anyways. A new developer will never be able to manage this hurdle.
Yeah, I have no idea how this Oomph stuff works, but there must be someone somewhere that controls the Oomph setup for OH. Otherwise, it makes no sense that there is a setup specifically for OH.
So, while something external could have caused the change, it should be possible to remedy from OHs side.
I don’t know how this works, but I’d think that the Oomph setup would allow you to not install it in the first place.
At least the Bndtools issue should be resolved once 7.2 is released, so while unfortunate, it doesn’t require any direct action.
But in general, I agree with you, the whole process is way too hard to figure out, and the documentation fails to mention most of the pitfalls. If you install Core, there are several other levels of “challenges”, like the endless build of the “model” and the general extreme slowness of the system if you leave all the bundles open, like they are by default. The WebUI had a similar problem of endless builds, but I’ve pushed for some changes there lately that I think should have at least improved that situation.
I’m not one that give up easy, and I know Eclipse pretty well since I use it quite a lot outside of OH. But, despite this, I have given up getting the “OH Eclipse” working several times over the years. It was first this winter that I decided to “push through”, and I think I spend around a week before I got it all to work (with all the “packages” including Core and WebUI). I’ve had to gut much of the (forced) stuff Oomph does, because it kept resetting the changes I had made when Eclipse was restarted. It was extremely frustrating, which is why I’m not keen to touch it now that it works.
But, I’d say, the state of this as it is effectively blocks new contributors to OH. I think very few people have the persistence to “power through” this. It should absolutely be made much easier to live with.
Personally, I think I would have preferred to drop Oomph altogether and instead document how to install and configure the necessary systems/plugins. That way, although “more work”, the (would be) developer would have some idea of what was being done and how to “control” it all. It would at least be nice if this was documented as an alternative.
While a comprehensive documentation of use tooling and setup + typical pitfalls makes sense anyways I think Oomph is not the baddest thing. The problem ist only that somebody needs to maintain the integration.
Requested a new developer to setup configure a complex toolset sounds not feasible for me. Nevertheless, a documentation would even open this path to experts like you.
There should also be a clear recommendation for the Eclipse version: “Of course you could use a different one, but this one was tested and is defiantly compatible with the build tools OH is using”.
That’s what I found on Google to supress installation of M2E PDE integration:
To avoid installing the Maven for Eclipse (M2E) PDE integration with Eclipse Oomph, you can choose to not include the M2E and PDE features when defining your setup configuration model in Oomph. This is done during the setup configuration process where you can select and deselect various components to be included in the final Eclipse installation. Specifically, you can remove the "m2e-core" plugin and any related PDE integration components.
Here's a more detailed breakdown:
1. Define the Setup Configuration Model:
When creating a new setup project model in Oomph, you'll be guided through the process of selecting and configuring the components for your desired Eclipse environment.
2. Component Selection:
During this process, you'll see a list of available components, including M2E and PDE integration features.
3. Remove M2E/PDE:
Carefully review the list and deselect the specific components related to M2E and PDE integration, such as "m2e-core".
4. Generate the Setup:
Once you have removed the unwanted components, generate the setup project model.
5. Install with Oomph:
Use the generated setup project to create and install your Eclipse environment with the desired components.
That means the list of packages installed by Oomph could be configured and we need to have someone updating this information: force usage of BND 7..0 (rather than latest) and remove M2E PDE from the list of installed packages.
@Kai Do you know how that works? Who is maintaining the Oomph setup configuration or is it just a left-over from the ESH days?
Not all developers are reading the full community forum, so please open an issue in GitHub or contribute a solution in GitHub.
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. I don’t know if there are hidden areas where more things happen, but at least the public areas seem more or less dead.
In this case, a PR has already been created and merged to solve on issue discussed in this thread, so it’s not like we’re not aware of GitHub, but to contribute to a solution, you must first know what to “fix”. As of now, it’s still unknown (in this thread) how OH’s Oomph configuration is handled, and thus it’s difficult to make a contribution. Also, this might not just be about fixing the current situation, but about preventing that it’s left “to rot” without somebody making sure that the solution keeps working.
This Oomph setup file is used by the Eclipse installer:
I made some changes to it before but don’t consider myself to be an Oomph expert. 
IIRC you can choose any such file to use in the installer. So if you have a local copy with your changes you can test by selecting your own file.
1 Like