Introduce full bnd-based IDE setup

[kaikreuzer]

As nearly all openhab2 add-ons have been migrated to bnd, the existing IDE setup that uses Tycho isn't really usable anymore - we must hence provide an updated IDE setup through which it is again possible to do add-on development.

Disclaimer: I myself still feel a bit lost in the bnd world and I am not having a decent development environment since January anymore - this made me pretty inefficient over the past months and I hope we can overcome this situation soon.

As I am not fully clear on the target picture for the IDE setup, I hope for input and contributions to this PR by all contributors driving the bnd change.

As a starting point, I have adapted the Oomph setup file to use bnd for all development and to checkout the correct repos.

As suggested here, I have moved the demo app to openhab-distro, so that it should become possible to start openHAB from within the IDE as a replacement for the former launch configuration.

What I am not yet clear on:

• With this change, we are losing the possibility to maintain code in openhab1-addons (and the org.openhab.binding.bacnet). Do we accept this? Do we have any suitable workaround or suggestion to the developers how to deal with this situation?
• We already discussed it somewhere else, but I don't think we had a final conclusion: With this PR, we have two demo setups: One of the demo app and one for the demo package in the distro. I am not sure that it makes sense to keep it like this for long.

Closes openhab/openhab-core#577

Signed-off-by: Kai Kreuzer kai@openhab.org

[davidgraeff]

There are still OH1 repo maintainers aren't there?
The migration can be performed mostly automatic and only need attention when tests are involved.

It only took longer in OH2-addons because we used maven dependencies to get rid of most embedded lib jars and needed to overcome a lot of OSGi bundling problems. For OH1-addons that effort doesn't need to be done I guess.

[kaikreuzer]

There are still OH1 repo maintainers aren't there?

In theory yes, in practice there are many open PRs and issues and not that much activity...

So your suggestion is to migrate openhab1-addons as well. I have no clue, how many obstacles might be on this way - it is a huge repo with a lot of (old) code, the open PRs will break and I don't know about the potential risk that something breaks and nobody notices it quickly (the code e.g. uses DS XMLs, has bundle Activators, etc.). My fear is, that a migration can take very long and will mean a lot of manual work.

[splatch]

With this change, we are losing the possibility to maintain code in openhab1-addons (and the org.openhab.binding.bacnet). Do we accept this?

@kaikreuzer I see no issues with bacnet binding - it has public maven central dependencies and can be ported to basic maven (BOM organized) build easily - with bnd or maven-bundle-plugin. In fact I initially did it with second, then bound it back to tycho parent.
Bacnet binding is not included in distribution build due to license incompatibility.

[maggu2810]

IMHO we should add DS requirements first (e.g. by openhab/openhab-core#595)

[kaikreuzer]

I see no issues with bacnet binding

Cool, so feel free to adapt it and I can keep the IDE setup option in place for it.

IMHO we should add DS requirements first

Is this a prerequisite or just something that "should" also be in place asap? It seems to me that the IDE setup can already work even without it being merged?

[maggu2810]

If people modifies the run requirements of the bndrun flie, they need to run the Bnd resolver (e.g. by press "resolve" in the UI), so the run bundles list is regenerated.

This will not work as expected as long as the DS requirements are disabled in core.

So, the unmodified openHAB demo will work, but as soon as someone adds its own bundles or would like to add other existing bundles, this will not work as expected.

[kaikreuzer]

I see, thanks for the explanation!

[kaikreuzer]

@maggu2810 I still have problems with the demo app in here. Trying to launch it I get

Where are those artifacts supposed to be loaded from and why aren't they found? Do you have a hint?

[J-N-K]

I thought we use two-space indentation in poms?

[kaikreuzer]

I used the IDE formatter, in which we defined to use tabs for XML files.

[kaikreuzer]

replaced by 2 spaces

[maggu2810]

In openHAB Core we follow the POM file convention for two spaces indentation, as we did previously in ESH. Regardless what has been choosen for things etc. xml files.

I don't have access to a PC this weekend.
You could check my openhab-demo repo, it contains a demo setup only. So it should be not blown up by unused stuff...
You could this one as a template.
I assume it will work.

[kaikreuzer]

@openhab/distro-maintainers I think this can be merged and issues that occur can then be addressed by individual PRs.

[kaikreuzer]

As there's no veto, allow me to merge so that we can move forward on this!

[kaikreuzer]

@openhab/core-maintainers & @openhab/2-x-add-ons-maintainers, I am pretty frustrated, maybe you can help:
I hoped that we can reach a working IDE for all our developers again and I think technically, this Oomph-setup file is more or less right. But when I execute it and choose openHAB addons as well as openHAB Core to be checked out from git and imported in the workspace, the whole setup process takes more than 1 hour. Doing a "Run OSGi" on app.bndrun hangs about one minute in "Performing required build..." at 31%. Doing small changes to some file (e.g. adding a bundle to the app.bndrun) causes the IDE to be busy for a minute.
All in all, my IDE is so terribly sluggish that it is hardly usable for development. 😥
Is this a sign that I need to buy new hardware? Is this only a problem for me as all of you seem to be pretty productive in the code? What could be different?
Ok, I agree that I chose the "maximum setup" with core + 2xaddons in the same workspace. But with PDE, I used to also have >100 1xaddons additionally in the workspace and it was still working decently...
I'd be interested to learn how your IDE setup looks like and how the sluggishness can be solved / worked around. I'll otherwise perpetually remind you of the good old productive times with PDE 😛.

[J-N-K]

I see the lagging Run-OSGi (exactly at 31% like yours) on one machine but not on another (which has less power than the lagging one). I can‘t say what the difference in setup is.

[davidgraeff]

I have the same bad experience if I add everything. That's why I only add the absolute minimum into the workspace. There is also https://github.com/openhab/openhab2-addons/issues/5554 (Eclipse Autobuild builds forever). m2e and bndtools don't seem to like each other at the moment.

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/addon-development/73935/9

[triller-telekom]

I just tried the new OOMPH setup with openhab-addons and openhab development.

It checks out everything fine (though it takes a while). Compilation also works, except for a few errors on the marytts addon, which complains about missing libraries.

I also see the hang on 31% if I right click on "app.bndrun" and select "Run as OSGi Run launcher".

But after about a minute a pop-up opens with a lot of OSGi errors:

could not resolve the bundles: [com.eclipsesource.jaxrs.jersey-all-2.22.2 org.osgi.framework.BundleException: Could not resolve module: com.eclipsesource.jaxrs.jersey-all [1]
  Unresolved requirement: Import-Package: javax.activation

, com.eclipsesource.jaxrs.publisher-5.3.1.201602281253 org.osgi.framework.BundleException: Could not resolve module: com.eclipsesource.jaxrs.publisher [2]
  Unresolved requirement: Import-Package: javax.ws.rs.core; version="[2.0.0,3.0.0)"
    -> Export-Package: javax.ws.rs.core; bundle-symbolic-name="com.eclipsesource.jaxrs.jersey-all"; bundle-version="2.22.2"; version="2.0.0"; uses:="javax.ws.rs.ext,javax.ws.rs,javax.xml.bind.annotation.adapters,javax.xml.namespace,javax.xml.bind.annotation"
       com.eclipsesource.jaxrs.jersey-all [1]
         Unresolved requirement: Import-Package: javax.activation
  Unresolved requirement: Import-Package: javax.ws.rs; version="[2.0.0,3.0.0)"
    -> Export-Package: javax.ws.rs; bundle-symbolic-name="com.eclipsesource.jaxrs.jersey-all"; bundle-version="2.22.2"; version="2.0.0"; uses:="javax.ws.rs.core,javax.ws.rs.ext"

, org.glassfish.hk2.utils-2.4.0.b34 org.osgi.framework.BundleException: Could not resolve module: org.glassfish.hk2.utils [43]
  Unresolved requirement: Import-Package: javax.inject
    -> Export-Package: javax.inject; bundle-symbolic-name="com.eclipsesource.jaxrs.jersey-all"; bundle-version="2.22.2"; version="1.0.0"
       com.eclipsesource.jaxrs.jersey-all [1]
         Unresolved requirement: Import-Package: javax.activation
  Unresolved requirement: Import-Package: javax.annotation
    -> Export-Package: javax.annotation; bundle-symbolic-name="com.eclipsesource.jaxrs.jersey-all"; bundle-version="2.22.2"; version="1.2.0"
...

[kaikreuzer]

@triller-telekom Do you maybe have some settings.xml in place that prevents a proper download of the dependencies from Maven Central? It all resolves nicely for me (and the others).

@maggu2810 Do you also see the 31% hanging when launching the app? This is imho pretty annoying as it slows down dev round trips quite a bit - I'd hope there's some solution to it.

[maggu2810]

My progress view shows "Launching: Build before launch - Performing required build..." on 31%.

If you disable the option "Build (if required) before launching" you will see something similar like that in your console view:

Specified launch file `.../openhab-demo/app/target/tmp/resolve/app/generated/launch1091730779586632942.properties' was not found - absolutePath='.../openhab-demo/app/target/tmp/resolve/app/generated/launch1091730779586632942.properties'

But hey, the option contains the phrase "if required", so this is not really unexpected.

I assume this kind of behaviour needs to be reported to the Bnd guys and it needs to be discussed there is the situation can be improved.

[maggu2810]

You could check if something similar to this improves the situation (the time needed to start and the time needed to resolve) a little bit.

[kaikreuzer]

Unfortunately, this does not seem to make any difference 😞.

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/maven-bnd-migration-and-eclipse-formatter/74609/2

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/problem-install-eclipse-ide/75140/19