While individual OSGi implementations will differ, I think this is a common problem.
When you start an OSGi framework, there is likely a mechanism for defining a set of bundles to install and perhaps start. Given this you could just put my application "main" in the appropriate BundleActivator.start() and put that bundle on the autostart list.
If I understand correctly, that means that start() never exits (well at least not until the app is done). As a result, you are running the whole time with the app bundle in STARTING state. Does this not cause problems with update? For instance, if you want to update the app bundle, you have to stop it. But you can't stop a STARTING bundle (or you can but it will throw and exception and will likely not be restarted).
This also implies that there is a different thread for each start() call as there is no real guaranteed start order so any one of the start's could block forever (or a long time) and prevent/delay the running of the following start()s.
So, you could fork a thread to run the app and let start() return. This is cool and allows for updating, running the other start(), etc. But you somehow have to stop the framework from exiting. In the couple of implementations I have seen, if you ignore the console, the framework comes up, installs/starts the bundles and then, with nothing else to do, falls off the end of main() (effectively) and stops. What is common practice here?