The \"OSGi way\" is to develop separate bundles containing discrete, coherent pieces of functionality. Sometimes these bundles contain utility classes, sometimes they depend on
The framework is the application ... The biggest mistake imho in the OSGi world is to see OSGi as a multi-tenant framework, it was not designed for that purpose and it is not a good fit. Inside a framework, there is high cohesion, all services registered are your services. The architectural model of OSGi allows you to write applications from loosely coupled components wired through services. Which is imho by far the best it gets in software (though there are lots of missing components unfortunately, will come).
In bndtools we go out of our way to help with this model. A bndtools bndrun file is basically an application that you can deploy. bnd can turn this bndrun file into runnable Jar with a Main-Class manifest header. (And with JPM it will be easy to deploy on any system.)
So the workflow is basically: design your services (== architecture), find standard components, develop missing components, test the components, test the integration, and turn the whole thing into a runnable JAR (or WAR).
Obviously you can still run multiple frameworks inside a single VM if so desired, but never run different unrelated applications in the same framework, not a good idea, life is hard enough as it is.