You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@sling.apache.org by bd...@apache.org on 2017/06/19 12:41:26 UTC
[20/53] sling-site git commit: asf-site branch created for published
content
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/bundles/sling-health-check-tool.md
----------------------------------------------------------------------
diff --git a/content/documentation/bundles/sling-health-check-tool.md b/content/documentation/bundles/sling-health-check-tool.md
deleted file mode 100644
index 710e937..0000000
--- a/content/documentation/bundles/sling-health-check-tool.md
+++ /dev/null
@@ -1,224 +0,0 @@
-title=Sling Health Check Tools
-type=page
-status=published
-~~~~~~
-
-Based on simple `HealthCheck` OSGi services, the Sling Health Check Tools ("hc" in short form) are used to
-check the health of live Sling systems, based on inputs like JMX MBean attribute values, OSGi framework
-information, Sling requests status, etc.
-
-Health checks are easily extensible either by configuring the supplied default `HealthCheck` services, or
-by implementing your own `HealthCheck` services to cater for project specific requirements.
-
-However for simple setups, the out of the box health checks are often sufficient. [Executing Health Checks](#executing-health-checks)
-is a good starting point to run existing checks and to get familiar with how health checks work.
-
-See also:
-
-* Source code at [http://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/healthcheck](http://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/healthcheck)
-* adaptTo slides about Health Checks: [Introduction](http://www.slideshare.net/bdelacretaz/slinghc-bdelacretazadaptto2013) and [Health Check Executor](https://adapt.to/content/dam/adaptto/production/presentations/2014/adaptTo2014-Sling-Health-Checks-New-And-Noteworthy-Georg-Henzler.pdf/_jcr_content/renditions/original.media_file.download_attachment.file/adaptTo2014-Sling-Health-Checks-New-And-Noteworthy-Georg-Henzler.pdf)
-
-## Use cases
-Generally health checks have two high level use cases:
-
-* Operations teams checking sling instances for their internal state manually
-* Load balancers can query the health of a sling instance and decide to take it out or back into the list of used backends automatically
-
-The strength of Health Checks are to surface internal Sling state for external use:
-
-* Verify that performance counters are in range
-* Run smoke tests at system startup
-* Check that all OSGi bundles are up and running
-* Check that demo content has been removed from a production system
-* Check that demo accounts are disabled
-* Ping external systems and raise alarms if they are down
-
-The health check subsystem uses tags to select which health checks to execute so you can for example execute just the _performance_ or _security_ health
-checks once they are configured with the corresponding tags.
-
-The out of the box health check services also allow for using them as JMX aggregators and processors, which take JMX
-attribute values as input and make the results accessible via JMX MBeans.
-
-## What's a `HealthCheck` ?
-
-A `HealthCheck` is just an OSGi service that returns a `Result`.
-
-public interface HealthCheck {
-
-/** Execute this health check and return a {@link Result}
-* This is meant to execute quickly, access to external
-* systems, for example, should be managed asynchronously.
-*/
-public Result execute();
-}
-
-Where `Result` is a simple immutable class that provides a `Status` (OK, WARN, CRITICAL etc.) and one or more log-like messages that
-can provide more info about what, if anything, went wrong.
-
-public class Result implements Iterable <ResultLog.Entry> {
-
-public boolean isOk() {
-return getStatus().equals(Status.OK);
-}
-
-public Status getStatus() {
-return resultLog.getAggregateStatus();
-}
-
-@Override
-public Iterator<ResultLog.Entry> iterator() {
-return resultLog.iterator();
-}
-
-... details omitted
-}
-
-### SlingHealthCheck annotation
-The `SlingHealthCheck` annotation makes it easier to specify the required `HealthCheck` service properties.
-
-Here's an example from the `samples` module - see the `annotations` module for more details.
-
-@SlingHealthCheck(
-name="Annotated Health Check Sample",
-mbeanName="annotatedHC",
-description="Sample Health Check defined by a java annotation",
-tags={"sample","annotation"})
-
-public class AnnotatedHealthCheckSample implements HealthCheck {
-
-@Override
-public Result execute() {
-...health check code
-}
-}
-
-## Executing Health Checks
-
-Health Checks can be executed via a [webconsole plugin](#webconsole-plugin), the [health check servlet](#health-check-servlet) or via [JMX](#jmx-access-to-health-checks). `HealthCheck` services can be selected for execution based on their `hc.tags` multi-value service property.
-
-The `HealthCheckFilter` utility accepts positive and negative tag parameters, so that `-security,sling`
-selects all `HealthCheck` having the `sling` tag but not the `security` tag, for example.
-
-For advanced use cases it is also possible to use the API directly by using the interface `org.apache.sling.hc.api.execution.HealthCheckExecutor`.
-
-## Health Check bundles
-The Health Check subsystem consists of the following bundles:
-
-* The only required bundles are `org.apache.sling.hc.api` which provides the API and `org.apache.sling.hc.core` which provides some utility classes and some generally useful `HealthCheck` services (e.g. the health check executor)
-* `org.apache.sling.hc.support` provides more Sling-specific `HealthCheck` services.
-* `org.apache.sling.hc.webconsole` provides the Webconsole plugin described below.
-* `org.apache.sling.junit.healthcheck` provides a `HealthCheck` service that executes JUnit tests in the server-side OSGi context.
-* `org.apache.sling.hc.samples` provides sample OSGi configurations and `HealthCheck` services. The sample configurations are provided as Sling content, so the Sling Installer is required to activate them.
-* `org.apache.sling.hc.junit.bridge` makes selected Health Checks available as server-side JUnit tests. See below for more info.
-
-## Out-of-the-box `HealthCheck` services
-
-The following default `HealthCheck` services are provided by the `org.apache.sling.hc.core` bundle:
-
-The `org.apache.sling.hc.samples` bundle provides OSGi configurations that demonstrate them.
-
-* `JmxAttributeHealthCheck` checks the value of a single JMX attribute and supports ranges like _between 12 and 42_.
-* `ScriptableHealthCheck` evaluates an expression written in any scripting language that Sling supports, and provides bindings to access JMX attributes.
-* `CompositeHealthCheck` executes a set of `HealthCheck` selected by tags, useful for creating higher-level checks.
-
-A few more Sling-specific ones are provided by the `org.apache.sling.hc.support` bundle:
-
-* `SlingRequestStatusHealthCheck` checks the HTTP status of Sling requests.
-* `DefaultLoginsHealthCheck` can be used to verify that the default Sling logins fail.
-* `ThreadUsageHealthCheck` can be used to monitor for deadlocks using JRE ThreadMXBean (see [SLING-6698](https://issues.apache.org/jira/browse/SLING-6698) )
-
-A bridge to server-side OSGi-aware JUnit tests is provided by the `JUnitHealthCheck`, from
-the `org.apache.sling.junit.healthcheck` bundle.
-
-The `org.apache.sling.hc.samples` bundle provides an example `OsgiScriptBindingsProvider` for the default `ScriptableHealthCheck`,
-which provides OSGi-related information to health check script expressions.
-
-## Configuring Health Checks
-`HealthCheck` services are created via OSGi configurations. Generic health check service properties are interpreted by the health check executor service. Custom health check service properties can be used by the health check implementation itself to configure its behaviour.
-
-The following generic Health Check properties may be used for all checks:
-
-Property | Type | Description
------------ | -------- | ------------
-hc.name | String | The name of the health check as shown in UI
-hc.tags | String[] | List of tags: Both Felix Console Plugin and Health Check servlet support selecting relevant checks by providing a list of tags
-hc.mbean.name | String | Makes the HC result available via given MBean name. If not provided no MBean is created for that `HealthCheck`
-hc.async.cronExpression | String | Used to schedule the execution of a `HealthCheck` at regular intervals, using a cron expression as specified by the [Sling Scheduler](/documentation/bundles/scheduler-service-commons-scheduler.html) module.
-hc.resultCacheTtlInMs | Long | Overrides the global default TTL as configured in health check executor for health check responses (since v1.2.6 of core)
-
-All service properties are optional.
-
-As an example, here's a `ScriptableHealthCheck` configuration provided by the `org.apache.sling.hc.samples` bundle:
-
-Factory PID = org.apache.sling.hc.ScriptableHealthCheck
-"hc.name" : "LoadedClassCount and ManagementSpecVersion are in range"
-"hc.mbean.name" : "LoadedClassCount and ManagementSpecVersion"
-"hc.tags" : [jvm, script]
-"expression" : "jmx.attribute('java.lang:type=ClassLoading', 'LoadedClassCount') > 10 && jmx.attribute('java.lang:type=Runtime', 'ManagementSpecVersion') > 1"
-"language.extension" : "ecma"
-
-The service properties starting with the `hc.` prefix in this example should be provided by all `HealthCheck` services.
-
-## Configuring the Health Check Executor
-The health check executor can **optionally** be configured via service PID `org.apache.sling.hc.core.impl.executor.HealthCheckExecutorImpl`:
-
-Property | Type | Default | Description
------------ | -------- | ------ | ------------
-timeoutInMs | Long | 2000ms | Timeout in ms until a check is marked as timed out
-longRunningFutureThresholdForCriticalMs | Long | 300000ms = 5min | Threshold in ms until a check is marked as 'exceedingly' timed out and will marked CRITICAL instead of WARN only
-resultCacheTtlInMs | Long | 2000ms | Result Cache time to live - results will be cached for the given time
-
-## Webconsole plugin
-If the `org.apache.sling.hc.webconsole` bundle is active, a webconsole plugin
-at `/system/console/healthcheck` allows for executing health checks, optionally selected
-based on their tags (positive and negative selection, see the `HealthCheckFilter` mention above).
-
-The DEBUG logs of health checks can optionally be displayed, and an option allows for showing only health checks that have a non-OK status.
-
-The screenshot below shows an example, as of svn revision 1513462.
-
-
-
-## JMX access to health checks
-If the `org.apache.sling.hc.jmx` bundle is active, a JMX MBean is created for each `HealthCheck` which has the
-service property `hc.mbean.name` service property set. All health check MBeans are registered in the
-domain `org.apache.sling.healthcheck` with a type of `HealthCheck`.
-
-The MBean gives access to the `Result` and the log, as shown on the screenshot below.
-
-See the example configurations of the `org.apache.sling.hc.samples` for more details.
-
-
-
-## Health Check Servlet
-Starting with version 1.2.4 of the `org.apache.sling.hc.core` bundle, a flexible Health Checks execution servlet is available. It provides
-similar features to the Web Console plugin described above, with output in HTML, JSON (plain or jsonp) and TXT (concise or verbose) formats (see HTML format rendering page for more documentation).
-
-The Health Checks Servlet is disabled by default, to enable it create an OSGi configuration like
-
-PID = org.apache.sling.hc.core.impl.servlet.HealthCheckExecutorServlet
-servletPath = /system/health
-
-which specifies the servlet's base path. That URL then returns an HTML page, by default with the results of all active health checks and
-with instructions at the end of the page about URL parameters which can be used to select specific Health Checks and control their execution and output format.
-
-Note that by design **the Health Checks Servlet doesn't do any access control by itself** to ensure it can detect unhealthy states of the authentication itself. Make sure the configured path is only accessible to relevant infrastructure and operations people. Usually all `/system/*` paths are only accessible from a local network and not routed to the Internet.
-
-## Health Checks as server-side JUnit tests
-The `org.apache.sling.hc.junit.bridge` bundle makes selected Health Checks available as server-side JUnit tests.
-
-It requires the `org.apache.sling.junit.core bundle` which provides the server-side JUnit tests infrastructure.
-
-The idea is to implement the smoke tests of your system, for example, as health checks. You can then run them
-as part of integration testing, using the [Sling Testing Tools](/documentation/development/sling-testing-tools.html)
-remote testing utilities, and also as plain Health Checks for monitoring or troubleshooting Sling instances.
-
-To use this module, configure sets of tags at `/system/console/configMgr/org.apache.sling.hc.junitbridge.HealthCheckTestsProvider`
-using the standard `includeThisTag,-omitThatTag` syntax, and JUnit tests will be available at /system/sling/junit/HealthChecks.html
-to run the corresponding Health Checks.
-
-To run the Health Check tests at build time, see the [testing/samples/integration-tests](http://svn.apache.org/repos/asf/sling/trunk/testing/samples/integration-tests)
-sample module.
-
-
-
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/bundles/sling-main-servlet-config.png
----------------------------------------------------------------------
diff --git a/content/documentation/bundles/sling-main-servlet-config.png b/content/documentation/bundles/sling-main-servlet-config.png
deleted file mode 100644
index cf667d5..0000000
Binary files a/content/documentation/bundles/sling-main-servlet-config.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/bundles/sling-oak-restrictions.md
----------------------------------------------------------------------
diff --git a/content/documentation/bundles/sling-oak-restrictions.md b/content/documentation/bundles/sling-oak-restrictions.md
deleted file mode 100644
index 13f6bd7..0000000
--- a/content/documentation/bundles/sling-oak-restrictions.md
+++ /dev/null
@@ -1,103 +0,0 @@
-title=Sling Oak Restrictions
-type=page
-status=published
-~~~~~~
-[TOC]
-
-
-## Introduction
-Oak introduced plugability of restrictions as described in [Oak Restriction Management](https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Pluggability). The bundle sling-oak-restrictions provides additional restrictions that generally make sense for sling applications. Currently sling restrictions for exact resource type match and resource type match including all descendants are supplied.
-
-**Important:** Using the sling restrictions (as well as standard oak restrictions) is not as performant as simple path based ACE entries without any restrictions. Permission setups should always mostly work with path based ACEs and only use ACEs with restrictions for special cases.
-
-## Restriction sling:resourceTypes
-This restriction allows to match against a sling resource type of a node and works much like the oak standard restriction `rep:ntNames`. Only resources that have one of the supplied resource types are matched, child and parent resources with other resource types are not matched.
-
-The following example allows `myAuthorizable` to write to all nodes that have either resource type `myproj/comp1` or `myproj/comp2`:
-
-- /content/myprj/mynode
-- rep:policy (rep:ACL)
-- allow (rep:GrantACE)
-+ principalName (String) = "myAuthorizable"
-+ rep:privileges (Name[]) = "rep:write"
-- rep:restrictions (rep:Restrictions)
-+ sling:resourceTypes (String[]) = [myproj/comp1,myproj/comp2]
-
-
-Assuming the following structure
-
-- /content/myprj
-+ sling:resourceType (String) = "myproj/siteroot"
-- mynode
-+ sling:resourceType (String) = "myproj/comp1"
-- mysubnode
-+ sling:resourceType (String) = "myproj/comp3"
-
-
-the rule from above will match `/content/myprj/mynode` and not `/content/myprj` (parent) nor `/content/myprj/mynode/mysubnode` (child).
-
-Naturally (as with any oak restrictions), the rule is limited to its base path. In case the node `/content/myprj/othernode` is of resource type `myproj/comp1`, it will still not match.
-
-## Restriction sling:resourceTypesWithDescendants
-This restriction matches against resource types in the same way as [sling:resourceTypes](#restriction-slingresourcetypes), except that it will also match all descendants of a matched node.
-
-The following example allows `myAuthorizable` to write to all nodes that have either resource type `myproj/comp1` or `myproj/comp2` **or are a child of a node, that has one of these resource types**:
-
-- /content/myprj/mynode
-- rep:policy (rep:ACL)
-- allow (rep:GrantACE)
-+ principalName (String) = "myAuthorizable"
-+ rep:privileges (Name[]) = "rep:write"
-- rep:restrictions (rep:Restrictions)
-+ sling:resourceTypesWithDescendants (String[]) = [myproj/comp1,myproj/comp2]
-
-
-Assuming the structure example as mentioned in [sling:resourceTypes](#restriction-slingresourcetypes), the rule from above will match `/content/myprj/mynode` and `/content/myprj/mynode/mysubnode` (and any other subnodes of `/content/myprj/mynode` with arbitrary resource types), but not `/content/myprj`.
-
-## Advanced Path Matching
-Both [sling:resourceTypes](#restriction-slingresourcetypes) and [sling:resourceTypesWithDescendants](#restriction-slingresourcetypeswithdescendants) support advanced path matching by using `resourcetype@path`. That way instead of checking the resource type of the current node, the resource type of node at the relative path is checked. For instance this is useful for the case where page content is stored in a `jcr:content` subnode of a hierarchy, the permission however is required to become effective on the parent node of `jcr:content`.
-
-The following example allows `myAuthorizable` to write to all nodes that have a subnode `jcr:content` with resource type `myproj/comp1` or `myproj/comp2` including their descendants:
-
-- /content/myprj/mynode
-- rep:policy (rep:ACL)
-- allow (rep:GrantACE)
-+ principalName (String) = "myAuthorizable"
-+ rep:privileges (Name[]) = "rep:write"
-- rep:restrictions (rep:Restrictions)
-+ sling:resourceTypesWithDescendants (String[]) = [myproj/comp1@jcr:content,myproj/comp2@jcr:content]
-
-Assuming the following structure
-
-- /content/myprj
-- jcr:content
-+ sling:resourceType (String) = "myproj/siteroot"
-- mynode1
-- jcr:content
-+ sling:resourceType (String) = "myproj/comp1"
-- mysubnode1
-- jcr:content
-+ sling:resourceType (String) = "myproj/comp3"
-- contentsubnode1
-+ sling:resourceType (String) = "myproj/comp4"
-- contentsubnode2
-+ sling:resourceType (String) = "myproj/comp5"
-- mysubnode2
-- jcr:content
-+ sling:resourceType (String) = "myproj/comp3"
-- mynode2
-- jcr:content
-+ sling:resourceType (String) = "myproj/comp7"
-
-the rule from above will match
-
-* `/content/myprj/mynode1` (because of the `@jcr:content` part of `myproj/comp1@jcr:content`)
-* `/content/myprj/mynode1/jcr:content` (it will check for `/content/myprj/mynode1/jcr:content/jcr:content` that does not exist, but since the parent `/content/myprj/mynode1` is already a match this matches because of `sling:resourceTypesWithDescendants`)
-* `/content/myprj/mynode1/contentsubnode1` (because of `sling:resourceTypesWithDescendants`)
-* `/content/myprj/mynode1/contentsubnode1` (because of `sling:resourceTypesWithDescendants`)
-
-and not match
-
-* `/content/myprj`
-* `/content/myprj/mynode2`
-
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/bundles/sling-pipes.md
----------------------------------------------------------------------
diff --git a/content/documentation/bundles/sling-pipes.md b/content/documentation/bundles/sling-pipes.md
deleted file mode 100644
index a19d19c..0000000
--- a/content/documentation/bundles/sling-pipes.md
+++ /dev/null
@@ -1,363 +0,0 @@
-title=Sling Pipes
-type=page
-status=published
-~~~~~~
-
-tool for doing extract - transform - load operations through a resource tree configuration.
-
-often one-shot data transformations need sample code to be written & executed. This tiny tool set intends to provide ability to do such transformations with proven & reusable blocks called pipes, streaming resources from one to the other.
-
-## What is a pipe
-
-getOutputBinding
-^
-|
-getInput +---+---+ getOutput
-| |
-+----> Pipe +---->
-| |
-+-------+
-
-A sling pipe is essentially a sling resource stream:
-
-- it provides an output as a sling resource iterator
-- it gets its input either from a configured path, either, if its chained (see container pipes below), from another pipe's output
-- each pipe can have additional dynamic inputs using other's bindings, and outputing its own bindings
-
-At this moment, there are 3 types of pipes to consider:
-
-- "reader" pipes, that will just output a set of resource depending on the input
-- "writer" pipes, that write to the repository, depending on configuration and output
-- "container" pipes, that contains pipes, and whose job is to chain their execution : input is the input of their first pipe,
-output is the output of the last pipe it contains.
-
-A `Plumber` osgi service is provided to help getting & executing pipes.
-
-## Registered Pipes
-a pipe configuration is a jcr node, with:
-
-- `sling:resourceType` property, which must be a pipe type registered by the plumber
-- `name` property, that will be used in bindings as an id, and will be the key for the output bindings (default value being a value map of the current output resource). Note that the node name will be used in case no name is provided.
-- `path` property, defines pipe's input. Note that property is not mandatory in case the pipe is streamed after another pipe, in which case previous pipe output's can be used as input.
-- `expr` property, expression through which the pipe will execute (depending on the type)
-- `additionalBinding` is a node you can add to set "global" bindings (property=value) in pipe execution
-- `additionalScripts` is a multi value property to declare scripts that can be reused in expressions
-- `conf` optional child node that contains addition configuration of the pipe (depending on the type)
-
-### readers
-
-#### Base pipe
-rather dummy pipe, outputs what is in input (so what is configured in path). Handy for doing some test mostly, and giving basic functionalities to others that inherit from it
-
-- `sling:resourceType` is `slingPipes/base`
-
-#### SlingQuery Pipe
-executes $(getInput()).children(expression)
-
-- `sling:resourceType` is `slingPipes/slingQuery`
-- `expr` mandatory property, contains slingQuery expression through which getInput()'s children will be computed to getOutput()
-
-#### JsonPipe
-feeds bindings with remote json
-
-- `sling:resourceType` is `slingPipes/json`
-- `expr` mandatory property contains url that will be called, the json be sent to the output bindings, getOutput = getInput.
-An empty url or a failing url will block the pipe at that given place.
-
-#### MultiPropertyPipe
-iterates through values of input multi value property and write them to bindings
-
-- `sling:resourceType` is `slingPipes/multiProperty`
-- `path` should be the path of a mv property
-
-#### XPathPipe
-retrieve resources resulting of an xpath query
-
-- `sling:resourceType` is `slingPipes/xpath`
-- `expr` should be a valid xpath query
-
-### JsonPipe
-feeds bindings with remote json
-
-- `sling:resourceType` is `slingPipes/json`
-- `expr` mandatory property contains url that will be called, the json be sent to the output bindings, getOutput = getInput.
-An empty url or a failing url will block the pipe at that given place.
-
-#### AuthorizablePipe
-retrieve authorizable resource corresponding to the id passed in expression, or if not found (or void expression),
-from the input path, output the found authorizable's resource
-
-- `sling:resourceType` is `slingPipes/authorizable`
-- `expr` should be an authorizable id, or void (but then input should be an authorizable)
-- `autoCreateGroup` (boolean) if autorizable id is here, but the authorizable not present, then create group with given id (in that case, considered as a write pipe)
-- `addMembers` (stringified json array) if authorizable is a group, add instanciated members to it (in that case, considered as a write pipe)
-- `addToGroup` (expression) add found authorizable to instanciated group (in that case, considered as a write pipe)
-- `bindMembers` (boolean) if found authorizable is a group, bind the members (in that case, considered as a write pipe)
-
-#### ParentPipe
-outputs the parent resource of input resource
-- `sling:resourceType` is `slingPipes/parent`
-
-#### FilterPipe
-outputs the input resource if its matches its configuration
-
-- `sling:resourceType` is `slingPipes/filter`
-- `conf` node tree that will be tested against the current input of the pipe, each `/conf/sub@prop=value` will triggers a test
-on `./sub@prop` property of the current input, testing if its value matches `value` regex. If the special `slingPipesFilter_noChildren=${true}`
-property is there with the value instantiated as a true boolean, then filter will pass if corresponding node has no children.
-- `slingPipesFilter_not='true'` inverts the expected result of the filter
-
-### containers
-#### Container Pipe
-assemble a sequence of pipes
-
-- `sling:resourceType` is `slingPipes/container`
-- `conf` node contains child pipes' configurations, that will be configured in the order they are found (note you should use sling:OrderedFolder)
-
-#### ReferencePipe
-execute the pipe referenced in path property
-
-- `sling:resourceType` is `slingPipes/reference`
-- `path` path of the referenced pipe
-
-### writers
-
-#### Write Pipe
-writes given nodes & properties to current input
-
-- `sling:resourceType` is `slingPipes/write`
-- `conf` node tree that will be copied to the current input of the pipe, each property's
-names and value will be written to the input resource. Input resource will be outputed.
-Note that properties that will be evaluated (in an expression) as `null` for a given input resource will be
-removed from it. E.g. `./conf/some/node@prop=${null}` will add `./conf/some/node` structure
-if not in current input resource, but remove its `prop` property if any).
-
-### MovePipe
-JCR move of current input to target path (can be a node or a property)
-
-- `sling:resourceType` is `slingPipes/mv`
-- `expr` target path, note that parent path must exists
-
-#### RemovePipe
-removes the input resource, returns the parent, regardless of the resource being a node, or
-a property
-
-- `sling:resourceType` is `slingPipes/rm`
-- `conf` node tree that will be used to filter relative properties & subtrees to the current resource to remove.
-A subnode is considered to be removed if it has no property configured, nore any child.
-
-#### PathPipe
-get or create path given in expression
-
-- `sling:resourceType` is `slingPipes/path`
-- `nodeType` node type of the intermediate nodes to create
-- `autosave` should save at each creation (will make things slow, but sometimes you don't have choice)
-
-## Making configuration dynamic with pipe bindings
-in order to make things interesting, most of the configurations are javascript template strings, hence valid js expressions reusing bindings (from configuration, or other pipes).
-
-Following configurations are evaluated:
-
-- `path`
-- `expr`
-- name/value of each property of some pipes (write, remove)
-
-you can use name of previous pipes in the pipe container, or the special binding `path`, where `path.previousPipe`
-is the path of the current resource of previous pipe named `previousPipe`
-
-global bindings can be set at pipe execution, external scripts can be added to the execution as well (see pipe
-configurations)
-
-## How to execute a pipe
-for now it's possible to execute Pipes through GET (read) or POST (read/write) commands:
-
-### Request Path
-
-- either you'll need to create a slingPipes/plumber resource, say `etc/pipes` and then to execute
-
-curl -u admin:admin -F "path=/etc/pipes/mySamplePipe" http://localhost:8080/etc/pipes.json
-
-- either you execute the request directly on the pipe Path, e.g.
-
-curl -u admin:admin http://localhost:8080/etc/pipes/mySamplePipe.json
-
-which will return you the path of the pipes that have been through the output of the configured pipe.
-
-### Request Parameter `binding`
-
-you can add as `bindings` parameter a json object of global bindings you want to add for the execution of the pipe
-
-e.g.
-
-
-curl -u admin:admin -F "path=/etc/pipes/test" -F "bindings={testBinding:'foo'}" http://localhost:4502/etc/pipes.json
-
-
-will returns something like
-
-{"size":2, "items":["/one/output/resource", "another/one"]}
-
-### Request Parameter `writer`
-
-you can add as `writer` parameter a json object as a pattern to the result you want to have. The values of the json
-object are expressions and can reuse each pipe's subpipe binding.
-Note
-this works only if the pipe called is a container
-pipe.
-
-e.g.
-
-
-curl -u admin:admin http://localhost:4502/etc/pipes/users.json?writer={"user":"${user.fullName}"}
-
-will returns something similar to
-
-{"size":2, "items":[{'user':'John Smith','path':'/home/users/q/q123jk1UAZS'},{'user':'John Doe','path':'/home/users/q/q153jk1UAZS'}]}
-
-### Request Parameter `dryRun`
-if parameter dryRun is set to true, and the executed pipe is supposed to modify content, it will log (at best it can) the change it *would* have done, without doing anything
-
-### Request Parameter `size`
-default response is truncated to 10 items, if you need more (or less), you can modify that settings with the size parameter
-
-## sample configurations
-
-### slingQuery | write
-this pipe parse all profile nodes, and
-
-{
-"sling:resourceType":"slingPipes/container",
-"name":"Dummy User prefix Sample",
-"jcr:description":"prefix all full names of profile with "Mr" or "Ms" depending on gender",
-"conf":{
-"profile": {
-"sling:resourceType":"slingPipes/slingQuery",
-"expr":"nt:unstructured#profile",
-"path":"/home/users"
-},
-"writeFullName": {
-"sling:resourceType":"slingPipes/write",
-"conf": {
-"fullName":"${(profile.gender === 'female' ? 'Ms ' + profile.fullName : 'Mr ' + profile.fullName)}",
-"generatedBy":"slingPipes"
-}
-}
-}
-}
-
-### slingQuery | multiProperty | authorizable | write
-{
-"jcr:primaryType": "sling:Folder",
-"jcr:description": "move badge<->user relation ship from badge MV property to a user MV property"
-"name": "badges",
-"sling:resourceType": "slingPipes/container",
-"conf": {
-"jcr:primaryType": "sling:OrderedFolder",
-"badge": {
-"jcr:primaryType": "sling:Folder",
-"jcr:description": "outputs all badge component resources",
-"expr": "[sling:resourceType=myApp/components/badge]",
-"path": "/etc/badges/badges-admin/jcr:content",
-"sling:resourceType": "slingPipes/slingQuery"
-},
-"profile": {
-"jcr:primaryType": "sling:Folder",
-"jcr:description": "retrieve all user ids from a mv property",
-"path": "${path.badge}/profiles",
-"sling:resourceType": "slingPipes/multiProperty"
-},
-"user": {
-"jcr:primaryType": "sling:OrderedFolder",
-"jcr:description": "outputs user resource",
-"expr": "profile",
-"sling:resourceType": "slingPipes/authorizable"
-},
-"write": {
-"jcr:primaryType": "sling:OrderedFolder",
-"jcr:descritption": "patches the badge path to the badges property of the user profile"
-"path": "${path.user}/profile",
-"sling:resourceType": "slingPipes/write",
-"conf": {
-"jcr:primaryType": "nt:unstructured",
-"badges": "+[${path.badge}]"
-}
-}
-}
-}
-
-
-### xpath | json | write
-this use case is for completing repository profiles with external system's data (that has an json api)
-
-{
-"jcr:primaryType": "nt:unstructured",
-"jcr:description": "this pipe retrieves json info from an external system and writes them to the user profile, uses moment.js, it
-distributes modified resources using publish distribution agent",
-"sling:resourceType": "slingPipes/container",
-"distribution.agent": "publish",
-"additionalScripts": "/etc/source/moment.js",
-"conf": {
-"jcr:primaryType": "sling:OrderedFolder",
-"profile": {
-"jcr:primaryType": "sling:OrderedFolder",
-"expr": "/jcr:root/home/users//element(profile,nt:unstructured)[@uid]",
-"jcr:description": "query all user profile nodes",
-"sling:resourceType": "slingPipes/xpath"
-},
-"json": {
-"jcr:primaryType": "sling:OrderedFolder",
-"expr": "${(profile.uid ? 'https://my.external.system.corp.com/profiles/' + profile.uid.substr(0,2) + '/' + profile.uid + '.json' : '')",
-"jcr:description": "retrieves json information relative to the given profile, if the uid is not found, expr is empty: the pipe will do nothing",
-"sling:resourceType": "slingPipes/json"
-},
-"write": {
-"jcr:primaryType": "sling:OrderedFolder",
-"path": "path.profile",
-"jcr:description": "write json information to the profile node",
-"sling:resourceType": "slingPipes/write",
-"conf": {
-"jcr:primaryType": "sling:OrderedFolder",
-"background": "${json.opt('background')}",
-"about": "${json.opt('about')}",
-"birthday": "${(json.opt('birthday') ? moment(json.opt('birthday'), "MMMM DD").toDate() : '')}",
-"mobile": "${json.opt('mobile')}"
-}
-}
-}
-}
-
-### xpath | parent | rm
-
-{
-"jcr:primaryType": "nt:unstructured",
-"jcr:description": "this pipe removes user with bad property in their profile",
-"sling:resourceType": "slingPipes/container",
-"conf": {
-"jcr:primaryType": "sling:OrderedFolder",
-"profile": {
-"jcr:primaryType": "sling:OrderedFolder",
-"expr": "/jcr:root/home/users//element(profile,nt:unstructured)[@bad]",
-"jcr:description": "query all user profile nodes with bad properties",
-"sling:resourceType": "slingPipes/xpath"
-},
-"parent": {
-"jcr:primaryType": "sling:OrderedFolder",
-"jcr:description": "get the parent node (user node)",
-"sling:resourceType": "slingPipes/parent"
-},
-"rm": {
-"jcr:primaryType": "sling:OrderedFolder",
-"jcr:description": "remove it",
-"sling:resourceType": "slingPipes/rm",
-}
-}
-}
-
-some other samples are in https://github.com/npeltier/sling-pipes/tree/master/src/test/
-
-# Compatibility
-For running this tool on a sling instance you need:
-
-- java 8 (Nashorn is used for expression)
-- slingQuery (3.0.0) (used in SlingQueryPipe)
-- jackrabbit api (2.7.5+) (used in AuthorizablePipe)
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/bundles/sling-query.md
----------------------------------------------------------------------
diff --git a/content/documentation/bundles/sling-query.md b/content/documentation/bundles/sling-query.md
deleted file mode 100644
index ee2fd7f..0000000
--- a/content/documentation/bundles/sling-query.md
+++ /dev/null
@@ -1,68 +0,0 @@
-title=Sling Query
-type=page
-status=published
-~~~~~~
-
-SlingQuery is a Sling resource tree traversal tool inspired by the [jQuery](http://api.jquery.com/category/traversing/tree-traversal/) JavaScript API.
-
-## Introduction
-
-The recommended way to find resources in the Sling repository is using tree-traversal methods, like `listChildren()` and `getParent()` rather than JCR queries. The latter are great for listing resources with given properties, but we can't leverage the repository tree structure with such queries. On the other hand, using tree-traversal method is quite verbose. Consider following code that takes an resource and returns its first ancestor, being `cq:Page`, with given `jcr:content/cq:template` attribute:
-
-Resource resource = ...;
-while ((resource = resource.getParent()) != null) {
-if (!resource.isResourceType("cq:Page")) {
-continue;
-}
-Resource template = resource.getChild("jcr:content/cq:template");
-if (template != null && "my/template".equals(template.adaptTo(String.class))) {
-break;
-}
-}
-if (resource != null) {
-// we've found appropriate ancestor
-}
-
-SlingQuery is a tool that helps creating such queries in a more concise way. Above code could be written as:
-
-import static org.apache.sling.query.SlingQuery.$;
-// ...
-$(resource).closest("cq:Page[jcr:content/cq:template=my/template]")
-
-Dollar sign is a static method that takes the resource array and creates SlingQuery object. The `closest()` method returns the first ancestor matching the selector string passed as the argument.
-
-SlingQuery is inspired by the jQuery framework. jQuery is the source of method names, selector string syntax and the dollar sign method used as a collection constructor.
-
-## Features
-
-* useful [operations](https://github.com/Cognifide/Sling-Query/wiki/Method-list) to traverse the resource tree,
-* flexible [filtering syntax](https://github.com/Cognifide/Sling-Query/wiki/Selector-syntax),
-* lazy evaluation of the query result,
-* `SlingQuery` object is immutable (thread-safe),
-* fluent, friendly, jQuery-like API.
-
-## Installation
-
-Add following Maven dependency to your `pom.xml`:
-
-<dependency>
-<groupId>org.apache.sling</groupId>
-<artifactId>org.apache.sling.query</artifactId>
-<version>3.0.0</version>
-</dependency>
-
-## Documentation
-
-* [CIRCUIT 2014 presentation](http://cognifide.github.io/Sling-Query/circuit2014/)
-* [Basic ideas](https://github.com/Cognifide/Sling-Query/wiki/Basic-ideas)
-* [Method list](https://github.com/Cognifide/Sling-Query/wiki/Method-list)
-* [Selector syntax](https://github.com/Cognifide/Sling-Query/wiki/Selector-syntax)
-* [Operator list](https://github.com/Cognifide/Sling-Query/wiki/Operator-list)
-* [Modifier list](https://github.com/Cognifide/Sling-Query/wiki/Modifier-list)
-* [Hierarchy operator list](https://github.com/Cognifide/Sling-Query/wiki/Hierarchy-operator-list)
-* [Examples](https://github.com/Cognifide/Sling-Query/wiki/Examples)
-
-## External resources
-
-* See the [Apache Sling website](http://sling.apache.org/) for the Sling reference documentation. Apache Sling, Apache and Sling are trademarks of the [Apache Software Foundation](http://apache.org).
-* Method names, selector syntax and some parts of documentation are inspired by the [jQuery](http://jquery.com/) library.
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/bundles/sling-settings-org-apache-sling-settings.md
----------------------------------------------------------------------
diff --git a/content/documentation/bundles/sling-settings-org-apache-sling-settings.md b/content/documentation/bundles/sling-settings-org-apache-sling-settings.md
deleted file mode 100644
index 7d99a92..0000000
--- a/content/documentation/bundles/sling-settings-org-apache-sling-settings.md
+++ /dev/null
@@ -1,81 +0,0 @@
-title=Sling Settings and Run Modes (org.apache.sling.settings)
-type=page
-status=published
-~~~~~~
-
-# Overview
-
-The Sling Settings Bundle exposes the `SlingSettingsService` which allows access to the following information pertinent to a Sling instance:
-
-| Method | Bundle Context Property | Description |
-|--|--|--|
-| `String getSlingId()` | --- | A unique identifier of the running Sling instance. This value is created when Sling is first started and may be used to identify the instance, for example if multiple Sling instances are running on top of a Jackrabbit Repository Cluster |
-| `String getSlingHomePath()` | `sling.home` | The absolute filesystem path to the directory where Sling stores all its content |
-| `URL getSlingHome()` | `sling.home.url` | The Sling Home path as an `java.net.URL` instance |
-| `Set<String> getRunModes()` | `sling.run.modes` | The active Run Modes of the running Sling instance |
-
-The new Sling Settings Bundle replaces the former [Run Modes (org.apache.sling.runmode)]({{ refs.run-modes-org-apache-sling-runmode.path }}) Bundle and the `SlingSettingsService` previously provided by the Sling Engine bundle, as it also implements the run modes logic.
-
-## Selecting the active run modes
-The run modes are selected based on the `sling.run.modes` property (the "selection property"), specified in the Sling settings file or as a command-line parameter (which takes precedence), out of the valid run modes defined by the properties described below. The value is a String which contains a list of comma-separated run modes. If a run mode is given here which is not contained in any group of valid run modes (given in `sling.run.mode.install.options` or `sling.run.mode.options`) it is always active, on the other hand run modes which are contained in any of the predefined groups may be modified/removed (see below for the details).
-
-Using `-Dsling.run.modes=foo,bar` on the JVM command-line, for example, activates the *foo* and *bar* run modes if that combination is valid.
-
-The absolute truth about run modes definition and selection is found in the [RunModeImplTest](https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/settings/src/test/java/org/apache/sling/settings/impl/RunModeImplTest.java) which should be self-explaining.
-
-## Defining valid run modes
-Since [SLING-2662](https://issues.apache.org/jira/browse/SLING-2662) the valid run modes are defined by the `sling.run.mode.options` and `sling.run.mode.install.options` configuration properties, usually defined in the `sling.properties` file or in the provisioning model of a Sling Launchpad instance.
-
-The `sling.run.mode.install.options` property is only used on the first startup on the Sling instance and the run modes that it defines cannot be changed later.
-
-The `sling.run.mode.options` property on the other hand is used at each startup, so the run modes that it defines can be changed between executions of a given Sling instance.
-
-The value of the both these properties is a string which looks like:
-
-red,green,blue|one|moon,mars
-
-where *comma-separated run modes form a group*. The individual groups are separated by a pipe character (`|`, which is not an OR operation, it's just as separator). A group defines a number of run modes which are **mutually exclusive**. It means once a group is defined, exactly one run mode will be active from that group.
-
-The example from above consists out of 3 different groups
-
-1. `red,green,blue`
-2. `one`
-3. `moon,mars`
-
-The rules for determining the active run modes from the selected run mode (`sling.run.modes`) and the run mode options (`sling.run.mode.install.options` and `sling.run.mode.options`) are as follows :
-
-1. If none of the run modes in the options are selected, the first one from each group in the options is activated by default.
-1. If one is selected from a group in the options, this is active.
-1. If several are selected from one group in the options, the first one from the list of valid run modes is used.
-1. If the selected run mode is not mentioned in any of the option groups it is active
-
-Examples
-
-sling.run.mode.options=a,b|c,d,e
-
-User defined run modes (e.g. via property `sling.run.modes`) | Effectively active run modes
---- | ---
-(none) | `a,c`
-`a` | `a,c`
-`b` | `b,c`
-`a,b` | `a,c`
-`a,d` | `a,d`
-`a,e,f` | `a,e`
-
-Remember to look at the `RunModeImplTest` mentioned above for details, and feel free to enhance it with useful examples.
-
-### Getting the Run Modes of the Sling instance
-
-The `SlingSettings` service provides the Run Modes of the running Sling instance as in this example:
-
-:::java
-SlingSettings settings = ...get from BundleContext...
-Set<String> currentRunModes = settings.getRunModes();
-
-Set<String> expectedRunModes = new HashSet<String>(){{ add("foo");add("wii"); }};
-if(expectedRunModes.removeAll(currentRunModes)) {
-// at least one of (foo,wii) run modes
-// is active
-}
-
-Getting run modes in this way is usually not needed, it's better to define bundles or configurations that are only valid in specific run modes, rather than making decisions in code based on run modes.
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/bundles/subsystem-installer-factory.md
----------------------------------------------------------------------
diff --git a/content/documentation/bundles/subsystem-installer-factory.md b/content/documentation/bundles/subsystem-installer-factory.md
deleted file mode 100644
index 5b5e3f4..0000000
--- a/content/documentation/bundles/subsystem-installer-factory.md
+++ /dev/null
@@ -1,15 +0,0 @@
-title=Subsystems Installer Factory
-type=page
-status=published
-~~~~~~
-
-The subsystems installer factory provides support for subsystems to the [OSGI installer](/documentation/bundles/osgi-installer.html). The provisioning of artifacts is handled by installer providers like the file installer or the JCR installer.
-
-
-## Subsystems
-
-The subsystem file must end with ".esa" and the manifest must at least contain the subsystem symbolic name "Subsystem-SymbolicName" header.
-
-# Project Info
-
-* Subsystems installer factory ([org.apache.sling.installer.factory.subsystems](http://svn.apache.org/repos/asf/sling/trunk/installer/factories/subsystems))
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/bundles/tracer-config.png
----------------------------------------------------------------------
diff --git a/content/documentation/bundles/tracer-config.png b/content/documentation/bundles/tracer-config.png
deleted file mode 100644
index 897259f..0000000
Binary files a/content/documentation/bundles/tracer-config.png and /dev/null differ
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/bundles/validation.md
----------------------------------------------------------------------
diff --git a/content/documentation/bundles/validation.md b/content/documentation/bundles/validation.md
deleted file mode 100644
index af1c7f4..0000000
--- a/content/documentation/bundles/validation.md
+++ /dev/null
@@ -1,144 +0,0 @@
-title=Sling Validation
-type=page
-status=published
-~~~~~~
-
-[TOC]
-
-Many Sling projects want to be able to validate both Resources and request parameters. Through the Sling Validation framework this is possible with the help of validation model resources which define validation rules for a certain resourceType.
-
-# Prerequisites
-To use this validation framework the following bundles need to be deployed
-
-1. `org.apache.sling.validation.api`
-1. `org.apache.sling.validation.core`
-
-In addition a [service resolver mapping](/documentation/the-sling-engine/service-authentication.html) needs to be configured for the service name `org.apache.sling.validation.core`. The bound service user needs to have at least read access to all resources within the resource resolver's search paths (usually `/apps` and `/libs`).
-
-# Basic Usage
-To validate a resource one first needs to get a `ValidationModel` and then validate the resource with that model. Both functionalities are provided by the `ValidationService` OSGi service:
-
-::java
-try {
-ValidationModel validationModel = validationService.getValidationModel(resource, true);
-if (validationModel != null) {
-ValidationResult result = validationService.validate(resource, validationModel);
-if (!result.isValid()) {
-// give out validation messages from result.get
-}
-}
-} catch (IllegalStateException e) {
-// give out error message that the validation model is invalid!
-}
-
-Apart from that it is also possible to validate resources including all child resources having their own validation model (i.e. a merged view of the validation models is applied). The appropriate validation model is being looked up by getting the resource type for each node. Since by default the JCR will return the primary type in case there is no `sling:resourceType` property found on the node, either the 2nd parameter `enforceValidation` should be set to `false` or some resource types must be explicitly ignored by the given filter in the 3rd parameter `filter` to also properly support validation models which have children resources on their own.
-
-::java
-try {
-final Predicate ignoreResourceType1Predicate = new Predicate<Resource>() {
-@Override
-public boolean test(final Resource resource) {
-return !"resourcetype1".equals(resource.getResourceType());
-}
-};
-ValidationResult result = validationService.validateResourceRecursively(resource, false, ignoreResourceType1Predicate, false);
-if (!result.isValid()) {
-// give out validation messages from result.getFailureMessages()
-}
-
-} catch (IllegalStateException e) {
-// give out error message that an invalid validation model for at least one sub resource was found
-} catch (IllegalArgumentException e) {
-// one of the resource types is absolute or there was no validation model found for at least one sub resource
-}
-
-All methods to retrieve a validation model support a boolean parameter `considerResourceSuperTypeModels`. If this is set to true, the validation model is not only being looked up for exactly the given resource type but also for all its resource super types. The returned model is then a merged model of all found validation model along the resource type hierarchy.
-
-## ValidationResult
-The `ValidationResult` indicates whether a given `Resource` or `ValueMap` is valid or invalid according to a given validation model. In the latter case it aggregates one or more `ValidationFailure`s. Each `ValidationFailure` is encapsulating an error message and a severity. The severity may be set on the following locations (where locations on top may overwrite severity from locations below):
-
-1. validation model (per use case of a `Validator`)
-1. severity defined on the `Validator`
-1. the default severity (may be set through the OSGi configuration for PID `org.apache.sling.validation.impl.ValidationServiceImpl`, is 0 by default)
-
-You have to use a `ResourceBundle` ([Internationalization Support](/documentation/bundles/internationalization-support-i18n.html)) to resolve the message for a specific locale. By default Sling Validation comes only with English failure messages.
-
-# Validation Model Resources
-The `ValidationModel` is constructed from resources with the resourceType **sling/validation/model**. Those resources are considered validation model resources if they are located below the Sling ResourceResolver search paths (*/apps* and */libs*).
-
-The resources should have the following format:
-
-Property/Resource Name | Property or Resource | Type | Description | Mandatory | Example
--------------------- | ------- | -------------- | -------------| --------- | ------
-`sling:resourceType` | Property | `String` | Always `sling/validation/model`, otherwise model will never be picked up by Sling Validation. | yes | `sling/validation/model`
-`validatingResourceType` | Property | `String` | The resource type of the resource for which this validation model should be applied. Must always be relative to the resource resolver's search path (i.e. not start with a "/"). | yes | `my/own/resourcetype`
-`applicablePaths` | Property | `String[]` | Path prefixes which restrict the validation model to resources which are below one of the given prefixes. No wildcards are supported. If not given, there is no path restriction. If there are multiple validation models registered for the same resource type the one with the longest matching applicablePath is chosen. | no | `/content/mysite`
-`properties<propertyName>` | Resource | - | This resource ensures that the property with the name `<propertyName>` is there. The resource name has no longer a meaning if the property `nameRegex` is set on this node. | no | `false`
-`properties<propertyName>optional` | Property | `Boolean` | If `true` it is not an error if there is no property with the given `<propertyName>` or none matching the `nameRegex`. If not set or `false` the property must be there. | no | `false`
-`properties<propertyName>propertyMultiple` | Property | `Boolean` | If `true` only multivalue properties are allowed with the name `<propertyName>` or matching the `nameRegex`. If not set or `false`, multi- and single-value properties are accepted. | no | `false`
-`properties<propertyName>nameRegex` | Property | `String` | If set the `<propertyName>` has no longer a meaning. Rather all properties which match the given regular expression are considered. At least one match is required, otherwise the validated resource/valuemap is considered invalid. | no | `property[0-8]`
-`properties<propertyName>validators<validatorId>` | Resource | - | The `<validatorId>` must be the id of a validator. The id is given by the OSGi service property `validator.id` set in the validator. Each validators node might have arbitrarily many child resources (one per validator). | no | `false`
-`properties<propertyName>validators<validatorId>validatorArguments` | Property | `String[]` | The parametrization for the validator with the id `<validatorId>`. Each value must have the pattern `key=value`. The parametrization differs per validator. | no | `regex=^[a-z]*$`
-`properties<propertyName>validators<validatorId>severity` | Property | `Integer` | The severity which should be set on all emitted validation failures by this validator. | no | `0`
-`children<resourceName>` | Resource | - | This resource ensures that the resource with the name `<resourceName>` is there. The resource name has no longer a meaning if the property `nameRegex` is set on this node. | no | `child1`
-`children<resourceName>nameRegex` | Property | `String` | If set the `<resourceName>` has no longer a meaning. Rather all resources whose name match the given regular expression are considered. At least one match is required, otherwise the validated resource/valuemap is considered invalid. | no | `child[1-9]`
-`children<resourceName>optional` | Property | `Boolean` | If `true` it is not an error if there is no resource with the given `<resourceName>` or none matching the `nameRegex`. If not set or `false` the resource must be there. | no | `false`
-`children<resourceName>properties` | Resource | - | The properties can be configured on the child level in the same way as on the root level. | no | -
-
-## Validation Model Inheritance
-Sling Validation optionally supports the inheritance of Sling Validation Models. This means not only the model for exactly the given resource type is considered, but also the models for all resource super types.
-To overwrite some property or child from one of the super type models, just define a property/child on the same level and with the same name in a model for a resource type which is more specific. That way the property/child on the super validation model is no longer effective.
-
-## Precedence of Validation Models
-In case there are multiple validation models registered for the same resource type the one gets chosen which has the longest matching applicablePath. In case even that does not resolve to a single model the one in the first resource resolver's search path is chosen (models below `/apps` before the ones below `/libs`). If even that does not resolve to a single validation model any of the equally ranked models might be picked.
-
-# Usage in [Sling Models](/documentation/bundles/models.html)
-## Since Sling Models 1.2.0
-See [Sling Models validation](/documentation/bundles/models.html#validation)
-
-## Before Sling Models 1.2.0
-One needs to call the validate method within the PostConstruct method of the according Sling Model
-
-::java
-@SlingObject
-protected Resource resource;
-
-@OSGiService
-protected ValidationService validation;
-
-@PostConstruct
-public void validate() {
-try {
-ValidationModel validationModel = validation.getValidationModel(resource);
-if (validationModel == null) {
-LOG.warn("No validation defined for resource '{}' with type '{}'", resource.getPath(), resource.getResourceType());
-
-} else {
-ValidationResult result = validation.validate(resource, validationModel);
-if (!result.isValid()) {
-// give out the validation result
-}
-}
-} catch (IllegalStateException e) {
-LOG.warn("Invalid validation model for resource '{}' with type '{}'", resource.getPath(), resource.getResourceType());
-}
-}
-
-# Validators
-
-Validator ID | Description | Parameters | Since
----------------|-------------|------------|-------
-[`org.apache.sling.validation.core.RegexValidator`](https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/validation/core/src/main/java/org/apache/sling/validation/impl/validators/RegexValidator.java) | Validates that a property value matches a given regular expression | `regex`, mandatory parameter giving a regular expression according to the pattern described in [java.util.regex.Pattern](http://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html). Only if the property value matches this expression it is considered valid. | 1.0.0
-
-# Writing Validators
-To write a validator one needs to implement the [`org.apache.sling.validation.spi.Validator`](https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/validation/api/src/main/java/org/apache/sling/validation/spi/Validator.java) interface in an OSGi service (look at [`org.apache.sling.validation.core.RegexValidator`](https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/validation/core/src/main/java/org/apache/sling/validation/impl/validators/RegexValidator.java) for an example).
-That interface defines the method `validate`. That is called for each property which is bound to the validator through the validation model.
-Each validator needs to specify one type parameter which defines upon which classes the validator can act (usually `String`). Array types are also supported here. Collection types are not supported. If a property value cannot be converted to the requested type from the validator (through `ValueMap.get(name, type)`), validation will fail.
-
-In addition the OSGi service must expose a String property named `validation.id`. The value of this property should always start with the providing bundle's symbolic name. Only through this value the validator can be referenced from validation models. If multiple validators have the same `validation.id` value the one with the highest service ranking gets always chosen.
-
-A validator may also expose a service property named `validation.severity` with an Integer value. This defines the default severity of the Validator (which may be overwritten in the validation model).
-
-# References
-1. [Apache Sling Generic Validation Framework, adaptTo 2014](http://www.slideshare.net/raducotescu/apache-sling-generic-validation-framework)
-
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/bundles/web-console-extensions.md
----------------------------------------------------------------------
diff --git a/content/documentation/bundles/web-console-extensions.md b/content/documentation/bundles/web-console-extensions.md
deleted file mode 100644
index fef0adb..0000000
--- a/content/documentation/bundles/web-console-extensions.md
+++ /dev/null
@@ -1,41 +0,0 @@
-title=Web Console Extensions
-type=page
-status=published
-~~~~~~
-
-The Apache Sling project provides two extensions to the [Apache Felix Web Console](http://felix.apache.org/site/apache-felix-web-console.html) (in addition to a number of plugins, of course):
-
-[TOC]
-
-## Branding (org.apache.sling.extensions.webconsolebranding)
-
-The Apache Sling Web Console Branding provided by Apache Sling is currently just for the product logo displayed in the upper right corner of the Web Console and some titles and strings.
-
-This bundle will attach as a fragment bundle to the Apache Felix Web Console bundle. To enable it after installation into a running system, you might have to refresh the package imports of the Apache Felix Web Console bundle. If you install using the Apache Felix Web Console bundle installation functionality, this will be taken care of by the Web Console.
-
-
-## Security Provider (org.apache.sling.extensions.webconsolesecurityprovider)
-
-The Apache Sling Web Console Security Provider implements the Apache Felix Web Console `WebConsoleSecurityProvider` and `WebConsoleSecurityProvider2` interface for authenticating Web Console users against the JCR repository. Each username and password presented is used to login to the JCR repository and to check the respective session.
-
-1. Ensure the username and password can be used to login to the default workspace. If not, access is denied
-1. If the username presented is one of the user names configured with the `users` configuration property, access is granted.
-1. Otherwise if the user is a (direct or indirect) member of one of the groups configured with the `groups` configuration property, access is granted.
-
-Access is denied if the username and password cannot be used to login to the default workspace or if the user is neither one of the configured allowed users nor in any of the configured groups.
-
-### Configuration
-
-The Security Provider is configured with the configuration PID `org.apache.sling.extensions.webconsolesecurityprovider.internal.SlingWebConsoleSecurityProvider` supporting the following properties:
-
-| Property | Type | Default Value | Description
-|--|--|--|
-| `users` | `String`, `String[]` or `Vector<String>` | admin | The list of users granted access to the Web Console |
-| `groups`| `String`, `String[]` or `Vector<String>` | --- | The list of groups whose (direct or indirect) members are granted access to the Web Console |
-
-Note, that while the default value explicitly grants the *admin* user to access the Web Console it is suggested that system administrators define a special group and assign users with Web Console access to this group.
-
-### Authentication Handling
-
-As long as the web console security provider bundle is not activate and has not installed one of the above mentioned services, the default authentication of the web console is used. Once the bundle is active and a JCR repository service is available, the repository is used for authentication as explained above. But still the login form of the web console is used which is usually basic authentication.
-Once startup is finished and a Sling authentication service is available as well, the security provider replaces the JCR repository based auth provider with a Sling based auth provider. Both authenticate against the JCR repository, however the Sling based one using Sling to render the login form. Therefore, this provider is not registered until startup is finished
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/bundles/xml-support.md
----------------------------------------------------------------------
diff --git a/content/documentation/bundles/xml-support.md b/content/documentation/bundles/xml-support.md
deleted file mode 100644
index 5513fec..0000000
--- a/content/documentation/bundles/xml-support.md
+++ /dev/null
@@ -1,11 +0,0 @@
-title=XML support
-type=page
-status=published
-~~~~~~
-Excerpt: XML mechanisms supported by Sling
-
-Out of the box, Sling provides no special bundles for XML. However, Sling supports multiple mechanisms and libraries. The ones we have validated with integration tests are:
-
-* XPath ( see the [XPathServlet](http://svn.apache.org/repos/asf/sling/trunk/launchpad/test-services/src/main/java/org/apache/sling/launchpad/testservices/servlets/XpathServlet.java) )
-* SAX ( see the [SaxServlet](http://svn.apache.org/repos/asf/sling/trunk/launchpad/test-services/src/main/java/org/apache/sling/launchpad/testservices/servlets/SaxServlet.java) )
-* DOM ( see the [DomServlet](http://svn.apache.org/repos/asf/sling/trunk/launchpad/test-services/src/main/java/org/apache/sling/launchpad/testservices/servlets/DomServlet.java) )
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/configuration.md
----------------------------------------------------------------------
diff --git a/content/documentation/configuration.md b/content/documentation/configuration.md
deleted file mode 100644
index 147277f..0000000
--- a/content/documentation/configuration.md
+++ /dev/null
@@ -1,183 +0,0 @@
-title=Configuration
-type=page
-status=published
-~~~~~~
-
-
-## Introduction
-
-Configuration in Sling is aligned with respective support by the OSGi specification:
-
-* Framework and Java system properties are available through the `BundleContext.getProperty(String)` method. These properties are provided in Sling through the Sling launcher.
-* Bundle Header values are available through the `Bundle.getHeaders()` and `Bundle.getHeaders(String)` methods. These header values are set by the bundle developer in the `META-INF/MANIFEST.MF` file. In fact, all main manifest attributes are available through these methods.
-* Components managed by the Service Component Runtime and declared in component descriptor files listed in the `Service-Component` manifest header access configuration properties through the `ComponentContext.getProperties()` method. These properties have three sources:
-1. Configuration specified specifically for factory components
-2. Properties retrieved from the Configuration Admin Service
-3. Properties set in the component descriptor
-* Configuration properties provided to `ManagedService` and `ManagedServiceFactory` instances by the Configuration Admin Service.
-
-For the discussion to follow we differentiate between initial configuration provided by Framework and system properties and managed configuration provided by the Configuration Admin Service.
-
-Components managed by the Service Component Runtime are generally configured (as listed above) through the descriptor properties and configuration set by Configuration Admin Service configuration. The descriptor property values may be seen as configuration default values set by the component developer, which may be overwritten by user configuration through the Configuration Admin Service. Components may but are not required to make use of Framework properties by accessing the `BundleContext` through the `ComponentContext` given to the `activate(ComponentContext)` method of the component.
-
-
-
-## Initial Configuration
-
-The lifecycle of the OSGi framework implemented by an instance of the `org.apache.felix.framework.Felix` class is managed by the Sling launcher class `org.apache.sling.launcher.Sling`. This class is used by the standalone main class (`org.apache.sling.launcher.main.Main`) and the Sling Servlet (`org.apache.sling.launcher.servlet.SlingServlet`) to control the lifecycle.
-
-The Sling launcher is responsible to provide the Framework properties to the OSGi framework. The properties are prepared as a `java.util.Map<String, String>` instance as follows (later steps may overwrite properties defined in earlier steps) :
-
-1. Load core properties from the embedded `sling.properties` file.
-1. Resolve any property file inclusions. This is mainly used to resolve the correct JRE package definitions for the JRE version used.
-1. Overwrite with any properties provided by the main class or the Sling Servlet.
-1. Make sure the `sling.home` property is set defining a sensible default value if missing
-1. Load the contents of the `${sling.home}/sling.properties` file
-1. Overwrite properties with Java system properties. This step only considers system properties of the same names as properties already existing. That is, the system properties are not just copied into the properties here. Additionally this step my be omitted if the `sling.ignoreSystemProperties` property is set to `true`.
-1. Resolve any property file inclusions. This may be used to provide more configurability depending on the integration.
-1. Handle OSGi boot delegation support (see below).
-1. Resolve property references of the form `${propName`}
-1. For each property value starting with `ontext:/` do the following, assuming the value to be an URL with scheme `context:`:
-* Copy the application resource to `${sling.home`} preserving the URL path unless such a file already exists.
-* Replace the property value with the path to the newly created file. The path has the form `${sling.home}/relpath`.
-1. Store the properties as `${sling.home}/sling.properties` to be re-used on next startup
-1. Setup Bundle auto installation for the Felix Framework
-
-Using file system copies of the initial configuration and referred files, it is easy to modify this configuration without the need to unpack and repackage the web application archive.
-
-The only property really required is actually the `sling.home` property, which defines the file system location where runtime files will be placed. The default if this property is missing will be *sling* in the current working directory as defined the `user.dir` system property.
-
-
-
-### Standalone Application
-
-When launching Sling as a standalone application the `sling-app.jar` file is used. This is an executable JAR File. The `sling.properties` file as well as the `sling_install.properties` and JRE specific properties files are located at the root of the JAR file hierarchy.
-
-The standalone application currently sets properties for the third step of the configuration setup to ensure the HTTP Servlet integration is using the Apache Felix *http.jetty* bundle. Additionally system properties may be set using the `-D` command line switch of the Java binary.
-
-In addition the following command line arguments are accepted:
-
-| Argument | Sling property | Description |
-|--|--|--|
-| `-l loglevel` | `org.apache.sling.osgi.log.level` | The initial loglevel (0..4, FATAL, ERROR, WARN, INFO, DEBUG) |
-| `-f logfile` | `org.apache.sling.osgi.log.file` | The log file, "-" for stdout |
-| `-c slinghome` | `sling.home` | the sling context directory |
-| `-a address` | -- | the interfact to bind to (use 0.0.0.0 for any) (not supported yet) |
-| `-p port` | `org.osgi.service.http.port` | the port to listen to (default 8080) |
-| `-h` | -- | Prints a simple usage message and exits. |
-
-The standalone application exits with status code 0 (zero) if Sling terminates normally, that is if the OSGi framework is stopped or if just the usage note has been displayed. If any error occurrs during command line parsing, the cause is printed to the error output and the application exists with status code 1 (one). If the OSGi framework fails to start, the cause is printed to the error output and the application exists with status code 2.
-
-
-### Web Application
-
-When launching Sling as a web application using the `sling-servlet.war` or any derived Web Application archive file, the `sling.properties` file is located in the `WEB-INF` folder along with the `sling_install.properties` and JRE specific properties files.
-
-The Sling Servlet uses the Servlet Context and Servlet `init-param` configurations to prepare the properties for the third step of the configuration setup.
-
-If the OSGi framework fails to startup for any reason a `javax.servlet.UnavailableException`.
-
-
-
-### Property File Inclusions
-
-Twice in the configuration setup (second and seventh step) any property file inclusions will be handled. Property files may be included by defining one or more properties containing a comma-separated list of properties files to include. Property file inclusion looks at the `sling.include` property and any other property whose prefix is `sling.include.`. When such properties exist, the files listed in those properties are included.
-
-The order of handling the property file inclusion properties is defined as natural sort order of the actual property names. So the properties of the files listed in the `sling.include.first` property will be loaded before the files listed in the `sling.include.second` but after the files listed in the `sling.include.a` property.
-
-Any file which does not exist is silently ignored.
-
-The names of the files are resolved as follows:
-
-1. If a resource exists at the same location as the initial `sling.properties` file packaged with the application, that resource is used
-1. If the name is a relative file name, it is looked for in the `sling.home` directory
-1. If the name is an absolute file name, it is used as is
-
-*Example*
-
-The packaged `sling.properties` file contains the following properties file inclusion setting:
-
-
-sling.include.jre = jre-${java.specification.version}.properties
-
-
-This is used to include the JRE package list to be made visible inside the OSGi framework.
-
-
-
-### OSGi Boot Delegation Support
-
-Some packages may have to be shared between bundles in an OSGi framework and the rest of Java VM in which the framework has been launched. This is especially true for OSGi framework instances launched in embedding such as Servlet Containers. In the case of a Sling Application accessing a JCR Repository launched in a different Web Application, this mainly concerns an API packages as well as the JNDI Initial Factory package(s).
-
-To cope with this sharing issue, the OSGi core specification defines two properties, which may list packages to be used from the environment:
-
-
-* *`org.osgi.framework.system.packages`* - This property lists package names which are added to the list of exported packages of the system bundle of the OSGi framework. These packages are used in the resolution process just as any package listed in an `Export-Package` bundle manifest header.
-* *`org.osgi.framework.bootdelegation`* - This property lists packages, which are always used from the environment. As such, these packages will never be looked up in package wirings as are packages imported by listing them in the `Import-Package` bundle manifest header.
-
-
-Sometimes, especially in the Servlet Container case, it is important to use the shared classes from the container and not resolve using standard OSGi resolution. In such cases, the packages of these shared classes must be listed in the `org.osgi.framework.bootdelegation` property. Sling provides a mechanism to extend the default setting of the `org.osgi.framework.bootdelegation` property by adding properties prefixed with `sling.bootdelegation.`. The value of each of these prefixed properties is conditionally appended to the `org.osgi.framework.bootdelegation` property. *Conditionally* means, that the property name may contain the fully qualified name of a class, which is checked to see whether to add the property value or not.
-
-*Examples*
-
-| Configuration | Description |
-|--|--|
-| `sling.bootdelegation.simple = com.some.package` | This setting unconditionally adds the `com.some.package` package to the `org.osgi.framework.bootdelegation` property |
-| `sling.bootdelegation.class.com.some.other.Main = com.some.other` | This setting checks whether the `com.some.other.Main` class is known. If so, the `com.some.other` package is added to the `org.osgi.framework.bootdelegation` property. Otherwise the `com.some.other` package is not added - and therefore must be exported by a bundle if required for use inside the framework. |
-
-
-*Note* Even though packages listed in the `org.osgi.framework.bootdelegation` property will always be loaded from the environment, any bundles using these packages must still import them (through `Import-Package` or `DynamicImport-Package`) and the bundles must resolve for being usable.
-
-
-
-### OSGi System Packages Support
-
-As listed in the above section on OSGi Boot Delegation Support, the `org.osgi.framework.system.packages` property may be used to extend the export list of the system bundle. Similar to the support for extending the boot delegation packages list, Sling supports extending the system packages list. The mechanism to extend the default setting of the `org.osgi.framework.system.packages` property by adding properties prefixed with `sling.system.packages.`. The value of each of these prefixed properties is conditionally appended to the `org.osgi.framework.system.packages` property. *Conditionally* means, that the property name may contain the fully qualified name of a class, which is checked to see whether to add the property value or not.
-
-*Examples*
-
-| Configuration | Description |
-|--|--|
-| `sling.system.packages.simple = com.some.package` | This setting unconditionally adds the `com.some.package` package to the `org.osgi.framework.system.packages` property |
-| `sling.system.packages.class.com.some.other.Main = com.some.other` | This setting checks whether the `com.some.other.Main` class is known. If so, the `com.some.other` package is added to the `org.osgi.framework.system.packages` property. Otherwise the `com.some.other` package is not added - and therefore must be exported by a bundle if required for use inside the framework. |
-
-
-*Note* Packages listed in the `org.osgi.framework.system.packages` required by any bundles must be imported by those bundles by listing them in the `Import-Package` or `DynamicImport-Package` manifest header.
-
-
-
-## Recommendations for property names
-
-The following system property names are reserved:
-
-* Names starting with `org.osgi.` are reserved for OSGi defined Framework properties
-* Names starting with `org.apache.felix.` are reserved for the Felix Framework
-* Names starting with `sling.` and `org.apache.sling.` are reserved for Sling
-
-To prevent property name collisions, I suggest the following convention:
-
-* Use fully qualified property names for initial configuration through Framework properties
-* Use unqualified property names for configuration through the Configuration Admin Service
-
-
-## Well Known Properties
-
-The following table is a collection of well known property names from different parts of Project Sling.
-
-| Property | Description |
-|--|--|
-| `sling.home` | Defines the file system location where Project Sling will write copies of the initial configuration. This property should also be used to define other local file system locations such as the directory to use for the Apache Felix Bundle Cache (`${sling.home}/felix` by default). If this property is not set it defaults to `${user.dir}/sling`. |
-| `sling.home.url` | Contains the Sling directory set in the `sling.home` property as a valid URL. This property may be used in situations where the Sling directory is required as an URL. This property is automatically set by the Sling application and may not be modified by configuration files. |
-| `sling.ignoreSystemProperties` | Whether to overwrite any configuration properties with Java system properties or not. By default this property is set to `true` by the Sling Servlet but not set by the Sling main class. The reason to set this by default in the Sling Servlet is to not induce values from the environment, which may not be appropriate in the Web Application case. |
-| `obr.repository.url` | A comma-separated list of OSGi Bundle Repository URLs. See *sling.properties* on the page [the Sling Launchpad](/documentation/the-sling-engine/the-sling-launchpad.html#slingproperties). |
-| `org.apache.sling.commons.log.*` | Properties providing initial configuration to the Sling Log Service. See *sling.properties* on the page [the Sling Launchpad](/documentation/the-sling-engine/the-sling-launchpad.html#slingproperties). |
-
-
-
-## Configuration Admin Service
-
-Configuration of the system entities, such as services and components, by the system administrator is supported the Configuration Admin Service. The Configuration Admin Service acts as the center for the management of the configuration data, to which GUI-based tools will connect to retrieve and update configuration data. The Configuration Admin Service is responsible for persisting the configuration data and for providing configuration consumers with the configuration data. Specifically services registered with the `ManagedService` or `ManagedServiceFactory` interfaces are updated with the configuration upon updated. The Service Component Runtime on the other hand recognizes updated configuration and provides it to the managed components as defined in the OSGi Declarative Services Specification.
-
-By default the Configuration Admin Service is installed when Sling is started for the first time. This service is used by the Service Component Runtime launching the OSGi components declared in the bundles with configuration values. The Sling Management Console provides a simple GUI to manage these configuration elements on the 'Configuration' page.
-
-For more information on the Configuration Admin Service refer to the OSGi Configuration Admin Service Specification in the OSGi Service Platform Service Compendium book.
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/development.md
----------------------------------------------------------------------
diff --git a/content/documentation/development.md b/content/documentation/development.md
deleted file mode 100644
index 97f16be..0000000
--- a/content/documentation/development.md
+++ /dev/null
@@ -1,57 +0,0 @@
-title=Development
-type=page
-status=published
-~~~~~~
-
-Welcome to the wonderful world of extending Sling. Refer to these pages to find out how we envision the extension of Sling and how to do it.
-
-
-## Using Sling as your Development Framework
-
-Look here for more information on developper support when your are using Sling to build your own applications.
-
-* [Getting and Building Sling](/documentation/development/getting-and-building-sling.html)
-* [Defining and Launching a Sling based Application](/documentation/development/slingstart.html)
-* [Embedding Sling](/documentation/development/embedding-sling.html)
-* [Logging](/documentation/development/logging.html)
-* [Client Request Logging](/documentation/development/client-request-logging.html)
-* [Monitoring Requests](/documentation/development/monitoring-requests.html)
-* [Repository Based Development](/documentation/development/repository-based-development.html)
-* [Sling IDE Tooling](/documentation/development/ide-tooling.html)
-* [Leveraging JSR-305 null annotations](/documentation/development/jsr-305.html)
-
-
-## Testing Sling-based Applications
-* [Testing Sling-based Applications](/documentation/tutorials-how-tos/testing-sling-based-applications.html)
-* [Junit Server-Side Tests Support](/documentation/bundles/org-apache-sling-junit-bundles.html)
-* [Resource Resolver Mock](/documentation/development/resourceresolver-mock.html)
-* [Sling Mocks](/documentation/development/sling-mock.html)
-* [OSGi Mocks](/documentation/development/osgi-mock.html)
-* [JCR Mocks](/documentation/development/jcr-mock.html)
-* [Hamcrest integration](/documentation/development/hamcrest.html)
-
-
-## Maven Stuff
-
-Sling is using Apache Maven 3 as its build system. Over time we have created a number of Maven 3 plugins and gathered a whole range of knowledge about using Maven.
-
-* [Maven Sling Plugin](http://sling.apache.org/components/maven-sling-plugin/)
-* [HTL Maven Plugin](http://sling.apache.org/components/htl-maven-plugin/)
-* [SlingStart Maven Plugin](http://sling.apache.org/components/slingstart-maven-plugin/)
-* [Maven Launchpad Plugin](/documentation/development/maven-launchpad-plugin.html)
-* [JspC Maven Plugin](http://sling.apache.org/components/jspc-maven-plugin/)
-* [Maven Archetypes](/documentation/development/maven-archetypes.html)
-* [Maven Tips & Tricks](/documentation/development/maventipsandtricks.html)
-
-
-## Sling Development
-
-Last but not least, here is some more information on how we ourselves are working on Sling
-
-* [Dependency Management](/documentation/development/dependency-management.html)
-* [Version Policy](/documentation/development/version-policy.html)
-* [Issue Tracker](/documentation/development/issue-tracker.html)
-* [Release Management](/documentation/development/release-management.html)
-* [Maven Usage](/documentation/development/maven-usage.html)
-* To run our integration tests suite see the [launchpad/testing module README](http://svn.apache.org/repos/asf/sling/trunk/launchpad/testing/README.txt) and the [launchpad/integration-tests README](http://svn.apache.org/repos/asf/sling/trunk/launchpad/integration-tests/README.txt) for how to run individual integration tests. We use the [sling-IT](https://issues.apache.org/jira/issues/?jql=labels%20%3D%20sling-IT) label in JIRA for known issues with our integration tests.
-* A Sonar analysis is available on the [analysis.apache.org](https://analysis.apache.org/dashboard/index/org.apache.sling:sling-builder) server.