For just running Sling you need roughly 30 bundles, from which 12 or so are Sling bundles. Some of them are Sling commons one, then you need things like the resource resolver, the servlets bundles and finally a resource provider.
But I think the notion of required is not really helpfull here, especially as it only converts a third of what you really need to run Sling. And that would be without considering which resource provider you use. For example if you want to use JCR, then this adds a bunch of new bundles to the mix which are required for that scenario Regards Carsten Dominik Süß wrote > Hi Jason, > > What beyond the ‚engine‘ is actually required? > And even the engine is not required to use some sling bundles. > > Sling follows a service oriented architecture thst is very loosely coupled > and expresses minimal depencies. We shouldn’t try to establish wrong > expectations by naming which is why I really don’t like core & controb or > extensions. > > The functional aspect is very personal and Sling starter is just one > reasonable combination of modules. > > The axis of interest are maintenance commitment (indicating commitment of > active commiters for module - staring as contribution and ending orphaned) > and maturity (experimental, alpha, beta, production ready/ stable , > deprecated, maybe discontinued) > > > For maturity: > Experimental ( intended for poc - might be quick & dirty) > Alpha (active development to cover a full productive scenario) > Beta (full coverage for intended use case - feedback cycles might lead to > refactorings of smaller parts) > Stable (versions > 1.0.0 indicating stable semantic versioning and > behavioral stability) > Deprecated (better alternatives around or no longer actively updated to > work optimally with latest platform) > Discontinued (only archival of latest shipped source) > > For the maintenance commitment I am personally interested how many active > willing commiters are around: 0, 1, 2-3, 4+) indicating how likely someone > can start to help in case of trouble with module > > Cheers > Dominik > > Jason E Bailey <j...@apache.org> schrieb am Mo. 24. Sep. 2018 um 15:13: > >> I still feel like we are missing an axis. One that groups the various >> bundles by functionality. >> >> Maybe: Required, Extension, Optional >> >> Required are the minimal bundles you need, Extensions are alternatives or >> specific implementations of Required, and Optional is just that. >> >> >> - Jason >> >> On Tue, Sep 18, 2018, at 9:46 AM, Bertrand Delacretaz wrote: >>> On Tue, Sep 18, 2018 at 3:38 PM Jason E Bailey <j...@apache.org> wrote: >>>> ...I'll throw "community" and/or "community supported" into the ring >> for consideration as well. For those bundles that aren't supported... >>> >>> I like it, as a way to indicate that the PMC expects the community to >>> take care of those bundles, on a best effort basis, as opposed to the >>> core bundles which the PMC commits to maintaining and keeping in sync >>> with the latest evolutions. >>> >>> That doesn't prevent any community member from working on core bundles >>> of course, again it's just an indication of PMC committment. >>> >>> So we might go for these two axes: >>> >>> Code maturity axis: experimental, alpha, beta, product-ready. >>> >>> PMC committment axis: core, community and whiteboard >>> >>> -Bertrand >> > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
