Thanks to Markus, we have a starting point for ESH based solutions. It's very lightweight and has less magic and extras then Karaf and has no config-file overhead, which makes it an ideal candidate for embedded platforms.

But after starting using that, I ask myself, what the best practices are.

@markus
Should it be used as a final step in development to package all together?
I ask myself:

Should I develop inside my copy of smarthome-packaging-sample-karaf?

Is it bad to enhance that with tycho/targetplatform stuff to compile own code?

How should I decouple my own Binding dev cycle from the rest of ESH to be able to stay up to date with ESH repos?

Whats the best way to add patched versions of existing bundles? Of course I have to test stuff in my own environment before creating a PR.

Would it be better to have two environments? One regular oomph based setup to work on public code and a private one? How do I get stuff exchanged between them?

I'm aware that there is always a way, but is there anybody who has found a great way of doing this? Maybe there's a golden way I never found. Extending the packaging-sample feels wrong

My favourite is to use pure Maven projects and the bnd-maven-plugin (formerly the maven-bundle-plugin) to create OSGi bundles.
So I could use annotations to create OSGi components (DS) and Maven plugins for quality checks.

If I work on Eclipse SmartHome upstream stuff (modify the source code that relies in the ESH repository) I use the Eclipse IDE setup provided by that project.