Home » Archived » Eclipse SmartHome » OpenHAB2 and SmartHome dependencies and build structure.
| OpenHAB2 and SmartHome dependencies and build structure. [message #1376483] |
Fri, 23 May 2014 12:36  |
|
Hi all,
One of the things still missing in SmartHome is the capability to run bindings on remote (low footprint) SmartHome nodes.
In my opinion, the two biggest challenges for remote nodes will be:
- running bindings with a minimum amount of bundles
- remote item/binding configuration management
In order to make it easy to run bindings in a minimal configuration, I would like to propose a change to the build dependencies between OpenHAB2 and SmartHome. I think it would be great if the compile dependency of OpenHAB2 could be reduced to a single org.eclipse.smarthome.api.jar.
This would mean that some of the interfaces in different SmartHome bundles would have to be moved to this API jar (e.g. BindingConfig, Item, etc.)
Pro's:
- Simplicity: easy to understand which classes from SmartHome you can/should use in openHAB2
- Strict decoupling: the openHAB2 build could be configured to only use the API jar during compilation and thus guarantee that no bindings are using any visible classes from SmartHome which they are not supposed to.
- No SmartHome bundle dependencies: It will be possible to run the bindings on any runtime which implements the SmartHome API, a full blown SmartHome runtime or a minimal version for remote nodes.
- Faster builds for openHAB2
Con's:
- Setup: There maybe 2 target platforms needed for OpenHAB2, 1 for compilation (which only includes the API jar) and 1 for running bindings on SmartHome.
Besides that change, it would also be great if the designer could graduate into its' own stream with it's own build process.
Any thoughts, suggestions, see other cons that I may overlooked?
Davy
|
|
|
| Re: OpenHAB2 and SmartHome dependencies and build structure. [message #1376769 is a reply to message #1376483] |
Fri, 23 May 2014 15:19  |
 Kai Kreuzer
Messages: 673
Registered: December 2011 |
Senior Member |
|
|
Hi Davy,
Not sure if your post was triggered through it, but I just posted something related yesterday on the openHAB list: https://groups.google.com/d/msg/openhab/EFoYiK-OfIE/cdrP_dsCyMoJ
A few comments:
- Yes, I agree that there should be the possibility to build minimal runtimes (see post above).
- Splitting bundles is always a tradeoff. So far, they are mainly split by functionality, e.g. if you are not interested in an REST API, simply leave out the io.rest bundles.
- Putting ALL apis in a single bundle is no solution as you might inherit dependencies that you do not want and you also have apis that you are not at all interested in in your system.
- So a consequence would be to have an api and an impl package for every functionality - which would result in almost twice as many bundles as we have today.
- Many apis are only really usable, if you also have the according abstract classes or services available. E.g. an Item Provider is not really useful without the ItemRegistry OSGi service.
- Agreed, it should be clearly defined, what bundles a binding (or other add-on) should exclusively depend on. But as OSGi allows private packages, I do not see a problem in having implementation classes in there as well.
For these reasons, I suggest to define useful subsets of bundles (and I am open for refactorings on their content where it makes sense) that we could package as separate features from which a "runtime" can choose, depending on what it wants to do and what it needs.
Best regards,
Kai
P.S: WRT the designer, the problem is that it shares the model bundles with the runtime and these need code generation through Xtext - so it is not really possible to have it in its own build stream.
The good thing is that none of this (neither model bundles nor the designer) is relevant for the openHAB2 build anymore (see https://openhab.ci.cloudbees.com/job/openHAB2/). So developing a binding for openHAB2 will in future mean a much much quicker and simpler Maven build.
Regards,
Kai
|
|
|
| Re: OpenHAB2 and SmartHome dependencies and build structure. [message #1377077 is a reply to message #1376769] |
Fri, 23 May 2014 18:19 |
|
Hi Kai,
No, I missed that post, thanks for pointing it out.
I agree that having a separate api and impl for every functionality or moving ALL apis into a single jar would not be a good idea.
I wanted to avoid using the term 'core' jar to avoid confusion with the current core jars, but in hindsight 'api' jar doesn't seem like it was such a good choice either.
What I meant is a single bundle which contains all the interfaces, exceptions, abstract classes, etc which you would ALWAYS need. Regardless of whether you want to build even the simplest of binding or the simplest of runtime...
To be very specific I believe it should contain the following classes: BindingConfig, EventPublisher, GenericItem, GroupFunction, GroupItem, Item, ItemFactory, ItemLookupException, ItemNotFoundException, ItemNotUniqueException, ItemProvider, ItemRegistry, ItemRegistryChangeListener, ItemsChangeListener, StateChangeListener, ColorItem, ContactItem, DateTimeItem, DimmerItem, NumberItem, RollershutterItem, StringItem, SwitchItem, ArithmeticGroupFunction, DateTimeType, DecimalType, HSBType, IncreaseDecreaseType, OnOffType, OpenClosedType, PercentType, StopMoveType, StringType, UpDownType, Command, ComplexType, PrimitiveType, State, Type, TypeParser, UnDefType and a handful new ones like Binding, ActiveBinding, etc.
This bundle shouldn't need any dependencies other than the eclipse osgi jar itself.
So in practice, if I wanted to create a simple binding, I would only have to use that single bundle as a dependency. If I wanted to build a more complex binding which uses MQTT or serial transport for example, then there would be an additional dependency on the corresponding transport bundle.
I have no knowledge on XText whatsoever, but couldn't you just use a target platform for the designer which depends on the SmartHome runtime, just like is done for openHAB2 now?
Kind regards,
Davy
|
|
|
| Re: OpenHAB2 and SmartHome dependencies and build structure. [message #1377168 is a reply to message #1377077] |
Fri, 23 May 2014 19:14 |
|
Right, I think I'm making this discussion a LOT more complicated than needed..
If the existing org.eclipse.smarthome.core could be extended a little bit to include a few extra classes and move a few others that are not needed out, then this would pretty much be what I had in mind..
Sorry for the confusion, I'm trying to pick up where I left off with some old code changes and it's turning out a little more difficult than I thought it would be...
Davy
|
|
| |
Goto Forum:
Current Time: Wed Apr 24 20:42:51 GMT 2024
Powered by FUDForum. Page generated in 0.03177 seconds |
] 
Search
Help
Register
Login
Home
