Cannot get bundle to activate

English Forum Software-Development
1

I’m working on a OpenEMS module for a hardware device that will manage a range of different lithium ion batteries. To do so, I’ve (re)written a generic comms bridge for our proprietary protocol, MC-Comms (io.openems.edge.bridge.mccomms in feature/mccomms-bridge). This bridge module is similar to the existing Modbus bridge module in that it provides an abstract component class (api/AbstractMCCommsComponent) for devices using MC-Comms protocol . The bridge seems to be working fine as far as I can tell, but when trying to implement a device using the abstract component class in io.openemes.edge.battery.microcare.ubmu (also in feature/mccomms-bridge), I cannot get the device to activate, and all hardcoded debug log points are never hit.

Steps to reproduce:
1.Start edge application
2.Activate alphabetical scheduler
3.Activate ‘Bridge MC-Comms’ with a valid serial port
4.Activate ‘BMS Microcare UBMU’
5.Console does not produce debug info, and osgiValidateWorker produces non-activation warnings (OpenemsComponent is implemented in io.openemes.edge.battery.microcare.ubmu)

Can anyone please shed light on why this is perhaps happening? TIA

2

Hi Kyle,

I didn’t run your code yet - just looked at the code for now. Here you are referencing the Service “MCCommsBridge”. Such a reference always needs to refer to a Interface and not a concrete Class. That might be the problem, as your implementation of the service is a class.

Compare this with the Modbus-Bridge, where “BridgeModbus” is a Interface and “BridgeModbusTcpImpl” is the implementation of this service.

Regards,
Stefan

3

Hi Stefan,

Thanks for the reply.
I made the code changes you suggested, but no dice - the UBMU bundle is still not activating. I’m tearing my hair out at this point. Thanks for the suggested code fix though, that particular code would have probably been a problem anyway.

Regards,
Kyle

4

Hi Kyle,

I took the time to dig a deeper. Here is my commit that fixed it for me. Applying that patch, I was able to activate the components:

There were numerous problems in the ‘classpath’, ‘bnd’ and ‘project’ files. You are using IntelliJ, right? Can I suggest to use Eclipse IDE + bndtools till you get a clear understanding of how everything works together. I don’t have any experience in IntelliJ and won’t be able to help much otherwise.

Regards,
Stefan

5

Thanks for taking time to dig deeper Stefan, I sincerely appreciate it. The classpath and project files are eclipse-specific, and are required if building the project through the IDE. This is obviously problematic when trying to build through IntelliJ, so I switched to doing Gradle builds instead a while back - I’m open to correction on this one, but the .classpath and .project files do not affect Gradle builds.

Your changes to the .bnd and .bndrun files did the trick though - the bundle did indeed activate. Thank you for the patch.

As for bndtools and OSGi in general - are there any courses you would recommend that would allow me to be more effective at OpenEMS development?

Thanks again,
Kyle

6

No problem - glad it works for you know. OSGi + bndtools have a quite steep learning curve. It took me a long time to understand the basics and I guess I am still far from understanding everything…

I can recommend the OSGi enRoute tutorials. They provide some good introductions:

I am personally not working with IntelliJ, but seems I should spend some time on improving compatibility with OpenEMS. I know that some people at Consolinno (e.g. @SebastianWalbrun) are working with IntelliJ, so maybe you can exchange some best practice.

For the Gradle-build: are you using the provided scripts (gradlew) or do you have anything customized? Our continious integration and production builds are also done using gradle.

7

I use the Gradle tasks in that I found in the project, namely clean, jar and buildEdge. I may eventually wrap these in a single build script if I ever get lazy enough to not want to click 6 times. IntelliJ integrates very nicely with Gradle and the project Gradle wrapper and picks up these tasks and executes them when asked to with zero configuration, which is preferable to the frankly sub-par OSGi plugin. Bndtools was working on an IntelliJ plugin, but it seems development has stalled on that project. Jetbrains themselves are making steady progress on improving OSGi compatibility, but it seems it’s still a while out. The biggest problem with the IntelliJ OSGi plugin at the moment is the buggy dependency resolution, as importing a bnd workspace will result in the classpath for several modules not being constructed correctly - hence the modified .classpath files, which is a hacky workaround to get IntelliJ to build OpenEMS without using Gradle. Here is a slideshare which may be of interest if you wish to look at using IntelliJ with OpenEMS:

1 Like
8

A word of warning for anyone reading this hoping to use IntelliJ with OpenEMS: DO NOT USE THE AMDATU PLUGIN - it will break everything in the project and force you to do a hard rebase to get things back to a working state.

1 Like