Include UIs and other add-ons in the demo app

[kaikreuzer]

Launching the core through app.bndrun isn't really too helpful as it is lacking any UI and any other add-ons that might be helpful for testing and debugging.

Would it be possible to add https://openhab.jfrog.io/openhab/libs-snapshot/ as a Maven repo and allow adding bundles from there? By default, the Paper UI + Basic UI would make sense to be included in any case.

@maggu2810 I see that you have currently selected "Standalone Mode", so I am not sure how to add such a remote repo and what (negative) effect that might have. I therefore hope for some of your insights on this.

[maggu2810]

I see the need of such a setup, but IMHO it should not be part of this (core framework) repo.
There should be another repo that is part of the "openHAB IDE" that contains such a demo application and can consume artifacts of all the other openHAB repositories.

The framework itself should not consume artifacts of another repository that depends itself on the framework repo.

[kaikreuzer]

The "framework itself" would not depend on anything, it would just be the demo app that includes such stuff.

But ok, I can of course also change the IDE setup to always checkout the distro project and put a bndrun file in there (and not import the demo.app project anymore).

[5iver]

The demo app is also missing /conf/scripts and /conf/automation/jsr223 (with the demo scripts).

[5iver]

@kaikreuzer, I've done my best to implement several variations of this, and while it has been a great learning experience, I have not been successful. Have you made any progress?

I had several PRs to submit for openhab-core, but my IDEs are all now such a mess from the recent chnages, that any work I had done is likely lost. Hopefully, I will remember what I did and be able to recreate them. I'm specifically in need of an IDE where I can develop/debug openhab-core, while using Paper UI. This was my latest effort, and needs to be debugged/tested.

[kaikreuzer]

No, I didn't make any progress myself as I am currently sick in bed :-(. I'm also a beginner in all the bnd stuff, so all I can do is also to slowly learn how to do things.

Best person to ask for assistance is @maggu2810 for the time being, I am afraid...

[5iver]

Sorry to hear that... hope you're back on your feet soon! I'll keep trying to get this working. Was your plan to add openhab-distro to the Core Development in the setup file (I've added it to the top, so available for all options), create a new bdrun file (and whatever else is needed) to openhab-distro, and then remove Demo from the setup file? I just want to be sure I'm headed in the right direction.

[maggu2810]

Best person to ask for assistance is @maggu2810 for the time being, I am afraid...

There's nothing to fear. 😉

@openhab-5iver What is the exact problem?
I have installed the openHAB IDE with AddOn and Core development support.

[5iver]

@maggu2810, I've installed an IDE with both Addon and Core too, but are you saying you have it working where you can debug modified core files while using a UI?! I specifically need Paper UI in order to debug a ConfigOptionProvider and GenericScriptEngineFactory. I cannot get the Demo app (although it sounds like this will need to be moved/recreated) to access any addons, either from openhab-distro or openhab-addons. I have no experience with bnd, and honestly, I'm not yet completely clear on the technical reason for why it is needed. But I am desperate to be able to debug core while using a UI!

[maggu2810]

There are different options to workaround the mixture of development technologies.
Everyone need some manual interactions.

You can add the JARs of the local core to the target platform and use a PDE based launch configuration.

You can use "Maven install" while opening the run section of the contextmenu of your Paper UI pom 's run section and add the Paper UI to a dependency section that is used by the "index" goal of the bnd indexer.
You can also include the JAR directly (in the target directory) using a local index, ...

Perhaps it would make sense to start migration of the Paper UI (at least as this one is used IMHO very frequently on development) to Maven + bnd.

[maggu2810]

Let's wait for #584 it will simplify it a little bit.

[kaikreuzer]

I have installed the openHAB IDE with AddOn and Core development support.

Note that I specifically mentioned that we do not support such a mixed setup (it will imho cause far too much confusion). This issue here is about adding binary artifacts, not sources to the demo app and I'd hope that this is fairly easy for the Core IDE.

Perhaps it would make sense to start migration of the Paper UI

FYI, I have moved all UIs to https://github.com/openhab/openhab-webui and plan to migrate them to bnd as a next step. But as stated above, this imho should not really matter.

Was your plan to add openhab-distro to the Core Development in the setup file (I've added it to the top, so available for all options), create a new bdrun file (and whatever else is needed) to openhab-distro, and then remove Demo from the setup file?

Yes, exactly - I think this is what we need to do as @maggu2810 does not like having the core demo app depend on artifacts from other repos (although I'd consider Jetty to be a similar situation and this is included in the demo app ;-)).

[maggu2810]

I think this is what we need to do as @maggu2810 does not like having the core demo app depend on artifacts from other repos (although I'd consider Jetty to be a similar situation and this is included in the demo app ;-)).

The situation differs for Jetty. Jetty does not depend on anything in openHAB Core.

The demo app that is part of the openHAB Core reactor should not depend on a non-reactor artifact that itself depends on a module of the openHAB Core reactor.

How do you want to resolve this cycle on e.g. a release?

• the core reactor will change from 2.5-SNAPSHOT to 2.5
• releases do not depend on snapshot (also the demo app is versioned and part of the reactor)
• to build the demo app index + JAR you need a release of the non-reactor dependency
• so, let's release that first
• ah, wait, we need a released core first

[kaikreuzer]

I guess what I fail to understand is why the app.bndrun has to be part of the build at all - there is nothing specific wrt versions in there and no other artifact depends on it either. To me, the bndrun file is nothing else as the equivalent of a launch-file in PDE. Is this a wrong comparison?

[maggu2810]

There are different points (all information here is just my understanding if I am completely wrong about bnd -- excuse me):

The demo app is also a build product. A JAR file is generated on a headless (Maven) build and that file can be started on the command line. No IDE necessary for the demo application.

The app.bndrun references indices: https://github.com/openhab/openhab-core/blob/363a437/demo/app/app.bndrun#L1-L3

The application contains runrequires: https://github.com/openhab/openhab-core/blob/363a437/demo/app/app.bndrun#L1-L3

The application contains runbundles: https://github.com/openhab/openhab-core/blob/363a437/demo/app/app.bndrun#L71-L180

runbundles is generated by using the resolver.
The runrequires defines the requirements.
The indices are used to satisfy that requirements (at this point new requirements can be added by bundles that provides something that needs to be resolved again, ...).
The resolver generates the runbundles section that contains the bundles that are used and that fulfills the requirements (runrequires).

If the application is started the bundles of runrequries are used.
The indices are used to find the location of that bundles.

So, the indices are the fundamental part to read the capabilities and requirements of bundles and to identify the uri the bundles can be found.

If you want an demo application that consumed JARs of core and addon you need an index that contains the URIs (or you need multiple separate indices).

My idea has been to use another repository that contains such a demo application (e.g. the distro repo, as it consumes all the other ones and no one refers to the distro).
That repository should be available in every openHAB IDE.
The repository can build a index that contains all the JAR files of subdirectories or a relative parent.
Additionally it can build indices using Maven coordinates.

E.g. directory layout of the git directory of the openHAB IDE (I don't care about the real names, because I don't know):

• distro
• addons
• core
• web-ui

In "distro/demo" we could place index projects

• index-local
  use all JAR files (without the itests ones) that are part of the current local build using just a modification of the input directory and the includes of

  openhab-core/bom/openhab-core-index/pom.xml

  Lines 45 to 51 in 363a437

  	<inputDir>${project.basedir}/../../bundles</inputDir>
  	<outputFile>${project.build.directory}/local-index.xml</outputFile>
  	<indexFiles>
  	<include>*/target/*.jar</include>
  	<exclude>*/target/*-javadoc.jar</exclude>
  	<exclude>*/target/*-sources.jar</exclude>
  	</indexFiles>

• index-m2-core
  refers to artifacts of the respective repo using maven coordinates
• index-m2-addons
  refers to artifacts of the respective repo using maven coordinates
• index-m2-web-ui
  refers to artifacts of the respective repo using maven coordinates

The app will consume index-local and perhaps the m2 ones if they are missing in the local checkout.

If the indices are generated by the Eclipse IDE correctly (I referred to the respective upstream issue already) I assume that only one index would be enough and that one can be merged into the application artifact itself

[davidgraeff]

I also vote for the full demo application to be in the distro or another repo.

But I also have to point out, that without that bndrun file of the demo app, I would have had no idea within Eclipse on how to "start" the OSGi environment and to start getting things done.

[kaikreuzer]

As we are getting closer to having to provide a working IDE setup for developers again, I guess we need to continue here.

without that bndrun file of the demo app, I would have had no idea within Eclipse on how to "start" the OSGi environment and to start getting things done

Same for me, so I consider this a vital part for the IDE setup.

My idea has been to use another repository that contains such a demo application (e.g. the distro repo

I think we all agree with that.

That repository should be available in every openHAB IDE.

That's already the case with the openhab-distro as it up to now included the target platform definition and the PDE launch configuration - i.e. fairly similar artifacts for the same use case.

In "distro/demo" we could place index projects

Could we put all those projects in the "launch" folder in the distro (which we should keep as it is referenced by the Eclipse Installer for the setup file).

[maggu2810]

I don't know what's the remaining points here.

What's the missing part WRT the current demo applications (except then moving it to another repo)?
BOMs are already used for addons and UI.
If a GAV referenced by the POM of the bndrun, the Bndtools already use the one in the workspace.
If you would like to add a new bundle, just add its dependency to the POM.

[kaikreuzer]

What's the missing part WRT the current demo applications (except then moving it to another repo)?

I hoped you would be able to answer. I've created openhab/openhab-distro#905, so feel free to comment.