Hi Sling team, (hmmm...long read ahead, sorry about that but I tried to keep it pragmatic ;-)
When talking about Sling to people who don't know it, a reaction that comes up very often is "this stuff looks cool, but I cannot really figure out what it does". Looking at the list of bundles [1], I think breaking up Sling in smaller pieces might help a lot, by allowing people to focus on what's important for them. - o - I suggest the following parts: 1) Scriptable JCR-based REST resource processing framework (sling-core-*) This is the clear focus of the project, other modules are only here to support it. This module: -Maps incoming HTTP requests to resources (JCR nodes or OCM-mapped objects) -Uses servlets or scripts to process the requests based on the HTTP uniform interface (get, post, put, delete). A simple example webapp allows developers to test this without spending more than 15 minutes to download, run and start exploring it. This is usually the only module that web developers need to learn. If possible, the API of this module is independent of OSGi, but that's not a priority. 2) OSGI console and utilities (sling-osgi-*) This can be useful outside of Sling, but it is not our priority to make it standalone. 3) Scripting tools (sling-scripting-*) JSP compiler, future interfaces to other scripting engines, etc. These tools could also be useful outside of Sling, but it is not our priority to make them standalone. 4) JCR tools (sling-jcr-*) Glue code for interaction between Sling and JCR repositories. - o - Users of the Sling core usually do not need to understand how 2), 3) and 4) work. For modules 2) and 3) and 4), we try to reuse stuff from other projects, as much as possible, or contribute stuff to other projects so that they fit our needs. - o - If we agree on this, the next step might be to reorganize our code base, with those four Maven modules at the top (sling-core, sling-osgi, sling-scripting and sling-jcr), and sub-modules below them. This entails little or no changes to existing code, just moving modules around and renaming some of them to use their parent module's name as a prefix. WDYT? -Bertrand [1] http://incubator.apache.org/sling/site/architecture.html