Hi, I have refactored jcrinstall to use a separate bundle for all OSGi operations (SLING-904). This needs more work, but one thing that can be done now is to split the OSGi-related operations in smaller sequential tasks (one class per task type), executed in a specified order.
I'm thinking of the following tasks, listed below in priority order - comments are welcome. Operations marked (*) are relevant for bundles only, others apply to both bundles and configurations. uninstall install or upgrade refresh packages (*) start (*) Configuration-related tasks will be executed before Bundle-related tasks. Notes: 1) Tasks sometimes need to be deferred for later execution. Configuration-related tasks, for example, cannot be executed if the (now optional) ConfigAdmin service is not present. 2) Multiple "refresh packages" tasks should be collapsed into a single one, executed after all pending install/upgrade/uninstall tasks, as shown above. 3) Before refreshing packages, the "refresh packages" task might create multiple "start bundle" tasks, one for each bundle that is currently active, to make sure those bundles are restarted after the refresh. 4) The worker thread execution loop needs to find out if new tasks have been added since the last loop iteration, and if that's the case walk the list of tasks to optimize it - for example changing install tasks to upgrade tasks if a bundle is already present, or merging multiple "refresh packages" tasks. Besides helping fix issues on which SLING-904 depends, all this should make the jcrinstall code simpler and easier to debug, especially as all tasks will be executed by a single worker thread. That's almost the case now, except that the OsgiController.executedScheduledOperations() method is still synchronous and creates a new thread every time. -Bertrand
