Thanks Richard, You can, although you can also use OBR to deploy from a local repository > too. Regarding location, it isn't too important. For example, OBR just > generates one based on the symbolic name and a timestamp. The main issue is > that the location is used as a key to uniquely identify a bundle, so if you > use a different location for the same bundle, the framework will treat it > different than if you use the same location. >
Sounds like OBR is generally the way to go. I'll take a more in depth look. Other than https://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+OSGi+Bundle+Repository#ApacheFelixOSGiBundleRepository-OBRRepositoryFile are there any other resources or examples you happen to know of? > Yeah, you don't need to do that. You can package the initial bundles with > the install package. Of course, once you update the installed bundles, you > may want another mechanism to save the updates overtop of the bundles in > the install package (i.e., outside the framework) so if the user ever > restarts from scratch (i.e., deletes their framework cache) they will start > with the latest bundles. Of course, this is not completely necessary, since > you could just deploy the old bundles and update them again, but it's > something to think about. Yeah, already thought about that, I wasn't going to overwrite the initially-installed bundles for now. There are security implications for Windows Vista+ platforms (write access to Program Files/**) technical issues with the Mac (updating a DMG image possibly beyond its size) and finally in many ways it may be a nice feature being able to roll back to the original version just by removing felix-cache. > You don't need to write your own AutoProcessor, just your own launcher > that massages the auto-deploy directory bundles to be what you want, then > the existing AutoProcessor would install, update, and delete as appropriate. I guess I don't understand this... Considering possibly already installed bundles in felix-cache I still have the problem with the version numbers differentiating the bundles and so more than one version of the bundle may be started. i.e... after first install and before first run: bundle/ my_web_app-1.0.1.jar jetty-xyz.jar Run it: bundle/ my_web_app-1.0.1.jar jetty-xyz.jar felix-cache/ my_web_app-1.0.1.jar jetty-xyz.jar Update it: bundle/ my_web_app-1.0.1.jar jetty-xyz.jar felix-cache/ my_web_app-1.0.2.jar jetty-xyz.jar Re-install later version: bundle/ my_web_app-1.0.3.jar jetty-xyz.jar felix-cache/ my_web_app-1.0.2.jar jetty-xyz.jar Because my_web_app-1.0.3.jar has a different URL to my_web_app-1.0.2.jar (whose location is my_web_app-1.0.1.jar) it will be started. Dan
