[ https://issues.apache.org/jira/browse/SLING-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15037677#comment-15037677 ]
Oliver Lietz commented on SLING-5337: ------------------------------------- bq. Just a side note: we don't need start levels in the Launchpad, it's just an optimization for the startup This is not entirely true. Tika needs to be activated before Jackrabbit. And here is another one: OAK-2910. bq. We don't have to define which conditions have to be met to register that service We have to define when startup is finished in a general way. In my opinion the _conditions_ should be the availability of services and capabilities (taking additional conditions like start level into account is ok). The base conditions should be the same for every launcher otherwise you will see strange effects. Suppose you have a bundle which expects JCR to be available when startup is finished. This may be true on our Launchpad but not necessarily on a custom Launchpad or Karaf because a minimal Sling works without JCR. bq. At least with subsystems you know that all bundles are installed and started, so simply adding a service based check does the trick. Maybe it's similar with Karaf? Yes, we could exploit the Features/Resolver API. Though after playing for a while with a configurable Startup Handler (SLING-5338) it seems that this approach is versatile and general and _good enough_. bq. I have started a Capability-based readiness detection? I have thought about adding a Capability check later to configurable Startup Handler. Taking a step back, the Startup handling came after Sling 6: * Do we really need it? * What are the use cases? * Should Sling modules (e.g. discovery) use it at all? * Should it be removed from Sling Settings? > Extract Startup API from Launchpad API > -------------------------------------- > > Key: SLING-5337 > URL: https://issues.apache.org/jira/browse/SLING-5337 > Project: Sling > Issue Type: Improvement > Components: Launchpad > Affects Versions: Launchpad API 1.2.0 > Reporter: Oliver Lietz > Assignee: Oliver Lietz > Fix For: Launchpad API 1.3.0, Startup API 1.0.0 > > > {{StartupHandler}}, {{StartupListener}}, {{StartupMode}} and > {{StartupService}} in {{org.apache.sling.launchpad.api}} should be moved to > {{org.apache.sling.startup.api}} (keeping extending but deprecated classes > there for backward compatibility) to decouple Startup from Launchpad. > A Startup implementation in Sling needs to be provided by every launcher > (Launchpad, Crankstart, Karaf)\[1\] whereas {{LaunchpadContentProvider}} is > only useful in contexts of Sling's own launcher Launchpad for installation > purpose. > [~cziegeler], [~bdelacretaz]: anything from your POVs to consider? > \[1\] We discussed to make Startup optional in {{Settings}} but that won't > work as we have modules which rely already on it (e.g. {{discovery}}). -- This message was sent by Atlassian JIRA (v6.3.4#6332)