SLING-1037, jcrinstall - sequence of actions, and when to refresh packages?

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

I'm rewriting the jcrinstall sequencing of OSGi tasks
(https://issues.apache.org/jira/browse/SLING-1037), and wondering when
to call PackageAdmin.refreshPackages().

Currently my idea is to execute tasks in this order, in the
OsgiController.executeScheduledOperations() method:

0. Create a "start bundle" task for each active bundle (as refresh
packages might cause some to stop)
1. Uninstall configs that have disappeared from the repository
2. Install or upgrade configs that have appeared in the repository
3. Uninstall bundles that have disappeared from the repository
4. Install or upgrade bundles that have appeared in the repository
(might create additional "start bundle" tasks)
5. Refresh packages
6. Start bundles (duplicate "start bundle" tasks are ignored)

With the new structure it's also possible to insert "refresh packages"
tasks everywhere in this list.

The order of tasks can be precisely controlled, as each task is an
object in a sorted list.

What do our OSGi gurus think of the above sequence?

-Bertrand

Re: SLING-1037, jcrinstall - sequence of actions, and when to refresh packages?

[Bertrand Delacretaz <bd...@apache.org>]

Additional question - is it safe to assume that Bundle.stop() will
*never* cause other bundles to stop?

I'm asking because, due to SLING-1039, I'd like to change

....
> 0. Create a "start bundle" task for each active bundle (as refresh
> packages might cause some to stop)
> 1. Uninstall configs that have disappeared from the repository
...
> 5. Refresh packages
> 6. Start bundles (duplicate "start bundle" tasks are ignored)

to

1. Uninstall configs that have disappeared from the repository
...
5. Refresh packages - this task first creates a "start bundle" task
for each active bundle (as refresh packages might cause some to stop)
6. Start bundles (duplicate "start bundle" tasks are ignored)

-Bertrand