sling-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bdelacre...@apache.org
Subject [17/53] sling-site git commit: asf-site branch created for published content
Date Mon, 19 Jun 2017 12:41:23 GMT
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/development/repository-based-development.md
----------------------------------------------------------------------
diff --git a/content/documentation/development/repository-based-development.md b/content/documentation/development/repository-based-development.md
deleted file mode 100644
index ddc7418..0000000
--- a/content/documentation/development/repository-based-development.md
+++ /dev/null
@@ -1,81 +0,0 @@
-title=Repository Based Development		
-type=page
-status=published
-~~~~~~
-
-[TOC]
-
-# WebDAV Support
-
-WebDAV support in Sling is based on the [Simple WebDAV](http://jackrabbit.apache.org/jcr/components/jackrabbit-jcr-server.html#Simple_Webdav_Server) implementation of Apache Jackrabbit which is integrated in the `jcr/webdav` project. This bundle provides WebDAV access to Sling's repository in two flavours:
-
-1. Access to all workspaces of the repository on a separate URI space -- by default rooted at `/dav` in the Sling context -- and
-2. access to the workspace used by Sling itself at the root of the Sling context.
-
-
-## Example
-
-Consider Sling be installed on a Servlet container in the `/sling` context on `some.host.net:8080`. Here you would access the Sling workspace by directing your WebDAV client to the URL `http://some.host.net:8080/sling`. To access the `sample` workspace, which is not used by Sling itself, you would direct your WebDAV client to the URL `http://some.host.net:8080/sling/dav/sample`.
-
-Please note that accessing the repository in the separate URI space is actually faster, since requests do not pass the Sling resource and script resolution framework but instead hit the Jackrabbit Simple WebDAV Servlet directly.
-
-
-## Separate URI Space WebDAV
-
-When accessing the repository through WebDAV in its separate URI Space, the URLs have the following generic structure:
-
-<slingroot>/<prefix>/<workspace>/<item>
-
-
-* `slingroot` is the URL of the Sling web application context. In the above example, this would `http://some.host.net:8080/sling`.
-* `prefix` is the URL prefix to address the WebDAV servlet. By default this is set to `/dav` but may be configured to any valid path.
-* `workspace` is the name of the workspace to be accessed through WebDAV.
-* `item` is the path to the JCR Item to access.
-
-If you access the WebDAV server at the prefix path -- e.g. `http://localhost:8080/dav` -- you will be redirected to the default workspace with a temporary redirect status 302. Some clients, such as the Linux *davfs*, do not like this redirection and must be configured to explicitly address the default workspace.
-
-
-## Configuration
-
-The Jackrabbit Simple WebDAV support in Sling has the following configuration options:
-
-Property | Default | Description
----- | ---- | ----
-Root Path | `/dav` | The root path at which the Simple WebDAV Servlet is accessible. Access to the repository is provided in two ways. You may connect your WebDAV client directly to the root of the Sling web application to access the workspace of Sling directly. The other way is required if you want to connect your WebDAV client to any other workspace besides the Sling workspace. In this case you connect your WebDAV client to another a path comprised of this root path plus the name of the workspace. For example to connect to the `some*other` workspace, you might connect to `http://slinghost/dav/some*other`.
-Authentication Realm | `Sling WebDAV` | The name of the HTTP Basic Authentication Realm presented to the client to ask for authentication credentials to access the repository.
-Non Collection Node Types | `nt:file`, `nt:resource` | The JCR Node Types considered being non-collection resources by WebDAV. Any node replying `true` to `Node.isNodeType()` for one of the listed types is considered a non-collection resource. Otherwise the respective node is considered a collection resource.
-Filter Prefixes | `jcr`, `rep` | A list of namespace prefixes indicating JCR items filtered from being reported as collection members or properties. The default list includes jcr and rep (Jackrabbit internal namespace prefix) items. Do not modify this setting unless you know exactly what you are doing.
-Filter Node Types | -- | Nodetype names to be used to filter child nodes. A child node can be filtered if the declaring nodetype of its definition is one of the nodetype names specified in the nodetypes Element. E.g. defining rep:root as filtered nodetype would result in `jcr:system` being hidden but no other child node of the root node, since those are defined by the nodetype nt:unstructered. The default is empty. Do not modify this setting unless you know exactly what you are doing.
-Filter URIs | -- | A list of namespace URIs indicating JCR items filtered from being reported as collection members or properties. The default list is empty. Do not modify this setting unless you know exactly what you are doing.
-Collection Primary Type | `sling:Folder` | The JCR Primary Node Type to assign to nodes created to reflect WebDAV collections. You may name any primary node type here, provided it allows the creation of nodex of this type and the defined Non-Collection Primary Type below it.
-Non-Collection Primary Type | `nt:file` | The JCR Primary Node Type to assign to nodes created to reflect WebDAV non-collection resources. You may name any primary node type here, provided the node type is allowed to be created below nodes of the type defined for the Collection Primary Type and that a child node with the name `jcr:content` may be created below the non-collection resource whose type is defined by the Content Primary Type.
-Content Primary Type | `nt:resource` | The JCR Primary Node Type to assign to the jcr:content child node of a WebDAV non-collection resource. You may name any primary node type here, provided the node type is allowed to be created as the jcr:content child node of the node type defined by the Non-Collection Primary Type. In addition the node type must allow at least the following properties: jcr:data (binary), jcr:lastModified (date), and jcr:mimeType (string).
-
-## Advanced Technical Details
-
-Since the Jackrabbit Simple WebDAV Servlet is originally configured using an XML configuration file, which provides a great deal of flexibility, the integration into Sling had to assume some simplifications, of which some of the above parameters are part:
-
-### IOManager
-
-This implementation uses the standard `org.apache.jackrabbit.server.io.IOManagerImpl` class and adds the `org.apache.jackrabbit.server.io.DirListingExportHandler` and `org.apache.jackrabbit.server.io.DefaultHandler` IO handlers as its only handlers. The `DefaultHandler` is configured from the three node types listed as configuration parameters above (collection, non-collection, and content primary node types).
-
-### PropertyManager
-
-This implementation uses the standard `org.apache.jackrabbit.server.io.PropertyManagerImpl` and adds the same `DirListingExportHandler` and `DefaultHanlder` instances as its own handlers as are used by the IO Manager.
-
-### ItemFilter
-
-This implementation uses the standard `org.apache.jackrabbit.webdav.simple.DefaultItemFilter` implementation as its item filter and configures the filter with the namespace prefixes and URIs as well as the node types configured as parameters.
-
-### Collection Node Types
-
-This implementation only supports listing node types which are considered representing non-collection resources. All nodes which are instances of any of the configured node types are considered non-collection resources. All other nodes are considere collection resources.
-
-# DavEx Support
-
-[DavEx](https://wiki.apache.org/jackrabbit/RemoteAccess) (WebDAV with JCR Extensions) allows to remotely access a JCR repository. Sling provides support based on the [JCR WebDAV Server](http://jackrabbit.apache.org/jcr/components/jackrabbit-jcr-server.html#JCR_Webdav_Server) implementation of Apache Jackrabbit which is integrated in the `jcr/davex` project. By default the server listens on request urls starting with `/server`.
-
-
-# Eclipse plugin for JCR
-
-see [Sling IDE Tooling](/documentation/development/ide-tooling.html)

http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/development/resourceresolver-mock.md
----------------------------------------------------------------------
diff --git a/content/documentation/development/resourceresolver-mock.md b/content/documentation/development/resourceresolver-mock.md
deleted file mode 100644
index 872f387..0000000
--- a/content/documentation/development/resourceresolver-mock.md
+++ /dev/null
@@ -1,51 +0,0 @@
-title=Resource Resolver Mock		
-type=page
-status=published
-~~~~~~
-
-Mock for the resource resolver / factory for easier testing. It uses an in-memory map for storing the resource data, and supports reading, writing and a certain level of transaction and eventing support.
-
-[TOC]
-
-
-## Maven Dependency
-
-#!xml
-<dependency>
-<groupId>org.apache.sling</groupId>
-<artifactId>org.apache.sling.testing.resourceresolver-mock</artifactId>
-</dependency>
-
-See latest version on the [downloads page](/downloads.cgi).
-
-
-## Implemented mock features
-
-The mock implementation supports:
-
-* All read and write operations of the Sling Resource API
-* Mimics transactions using via commit()/revert() methods
-* OSGi events for adding/changing/removing resources
-* The implementation tries to be as close as possible to the behavior of the JCR resource implementation e.g. concerning date and binary handling
-
-
-The following features are *not supported*:
-
-* Authentication not supported ("login" always possible with null authentication info)
-* Querying with queryResources/findResources not supported (always returns empty result set)
-* Sling Mapping is not supported
-* Resolving resource super types
-
-
-
-## Usage
-
-To create a mocked resource resolver:
-
-#!java
-MockResourceResolverFactory factory = new MockResourceResolverFactory();
-ResourceResolver resolver = factory.getResourceResolver(null);
-
-With the resolver you can use all Sling Resource features including reading and writing data using the Sling API.
-
-You cannot do any operations that require the JCR API because no JCR is underlying and adapting to JCR objects will just return null.

http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/development/sling-datasource-config.png
----------------------------------------------------------------------
diff --git a/content/documentation/development/sling-datasource-config.png b/content/documentation/development/sling-datasource-config.png
deleted file mode 100644
index 9ba5ddd..0000000
Binary files a/content/documentation/development/sling-datasource-config.png and /dev/null differ

http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/development/sling-log-support.png
----------------------------------------------------------------------
diff --git a/content/documentation/development/sling-log-support.png b/content/documentation/development/sling-log-support.png
deleted file mode 100644
index d37a7da..0000000
Binary files a/content/documentation/development/sling-log-support.png and /dev/null differ

http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/development/sling-mock.md
----------------------------------------------------------------------
diff --git a/content/documentation/development/sling-mock.md b/content/documentation/development/sling-mock.md
deleted file mode 100644
index 2dbb43f..0000000
--- a/content/documentation/development/sling-mock.md
+++ /dev/null
@@ -1,451 +0,0 @@
-title=Sling Mocks		
-type=page
-status=published
-~~~~~~
-
-Mock implementation of selected Sling APIs for easier testing.
-
-[TOC]
-
-
-## Maven Dependency
-
-#!xml
-<dependency>
-<groupId>org.apache.sling</groupId>
-<artifactId>org.apache.sling.testing.sling-mock</artifactId>
-</dependency>
-
-See latest version on the [downloads page](/downloads.cgi).
-
-
-There are two major version ranges available:
-
-* sling-mock 1.x: compatible with older Sling versions from 2014 (Sling API 2.4 and above)
-* sling-mock 2.x: compatible with Sling versions from 2016 (Sling API 2.11 and above)
-
-
-## Implemented mock features
-
-The mock implementation supports:
-
-* `ResourceResolver` implementation for reading and writing resource data using the Sling Resource API
-* Backed by a [mocked][jcr-mock] or real Jackrabbit JCR implementation
-* Uses the productive [Sling JCR resource provider implementation][jcr-resource] internally to do the Resource-JCR mapping
-* Alternatively the non-JCR mock implementation provided by the
-[Sling resourceresolver-mock implementation][resourceresolver-mock] can be used
-* `AdapterManager` implementation for registering adapter factories and resolving adaptions
-* The implementation is thread-safe so it can be used in parallel running unit tests
-* `SlingScriptHelper` implementation providing access to mocked request/response objects and supports getting
-OSGi services from the [mocked OSGi][osgi-mock] environment.
-* Implementations of the servlet-related Sling API classes like `SlingHttpServletRequest` and `SlingHttpServletRequest`
-* It is possible to set request data to simulate a certain Sling HTTP request
-* Support for Sling Models (Sling Models API 1.1 and Impl 1.1 or higher required)
-* Additional services `MimeTypeService`
-* Context Plugins
-
-The following features are *not supported*:
-
-* It is not possible (nor intended) to really execute sling components/scripts and render their results.
-* The goal is to test supporting classes in Sling context, not the sling components/scripts themselves
-
-
-### Additional features
-
-Additional features provided:
-
-* `SlingContext` JUnit Rule for easily setting up a Sling Mock environment in your JUnit test cases
-* `ContentLoader` supports importing JSON data and binary data into the mock resource hierarchy to easily
-prepare a test fixture consisting of a hierarchy of resources and properties.
-* The same JSON format can be used that is provided by the Sling GET servlet for output
-* `ContentBuilder` and `ResourceBuilder` make it easier to create resources and properties as test fixture
-
-
-## Usage
-
-### Sling Context JUnit Rule
-
-The Sling mock context can be injected into a JUnit test using a custom JUnit rule named `SlingContext`.
-This rules takes care of all initialization and cleanup tasks required to make sure all unit tests can run
-independently (and in parallel, if required).
-
-Example:
-
-#!java
-public class ExampleTest {
-
-@Rule
-public final SlingContext context = new SlingContext();
-
-@Test
-public void testSomething() {
-Resource resource = context.resourceResolver().getResource("/content/sample/en");
-// further testing
-}
-
-}
-
-It is possible to combine such a unit test rule with a `@RunWith` annotation e.g. for
-[Mockito JUnit Runner][mockito-testrunner].
-
-The `SlingContext` object provides access to mock implementations of:
-
-* OSGi Component Context
-* OSGi Bundle Context
-* Sling Resource Resolver
-* Sling Request
-* Sling Response
-* Sling Script Helper
-
-Additionally it supports:
-
-* Registering OSGi services
-* Registering adapter factories
-* Accessing ContentLoader, and ContentBuilder and ResourceBuilder
-
-
-### Choosing Resource Resolver Mock Type
-
-The Sling mock context supports different resource resolver types. Example:
-
-#!java
-public class ExampleTest {
-
-@Rule
-public final SlingContext context = new SlingContext(ResourceResolverType.RESOURCERESOLVER_MOCK);
-
-}
-
-Different resource resolver mock types are supported with pros and cons, see next chapter for details.
-
-
-### Resource Resolver Types
-
-The Sling Mocks resource resolver implementation supports different "types" of adapters for the mocks.
-Depending on the type an underlying JCR repository is used or not, and the data is stored in-memory or in a real
-repository.
-
-Resource resolver types currently supported:
-
-**RESOURCERESOLVER_MOCK (default)**
-
-* Simulates an In-Memory resource tree, does not provide adaptions to JCR API.
-* Based on the [Sling resourceresolver-mock implementation][resourceresolver-mock] implementation
-* You can use it to make sure the code you want to test does not contain references to JCR API.
-* Behaves slightly different from JCR resource mapping e.g. handling binary and date values.
-* This resource resolver type is very fast because data is stored in memory and no JCR mapping is applied.
-
-**JCR_MOCK**
-
-* Based on the [JCR Mocks][jcr-mock] implementation
-* Uses the productive [Sling JCR resource provider implementation][jcr-resource] internally to do the Resource-JCR mapping
-* Is quite fast because data is stored only in-memory
-
-**NONE**
-
-* Uses the productive Sling resource factory implementation without any ResourceProvider. You have to register one yourself to do anything useful with it.
-* The performance of this resource resolver type depends on the resource provider registered.
-* This is useful if you want to test your own resource provides mapped to root without any JCR.
-
-**JCR_OAK**
-
-* Uses a real JCR Jackrabbit Oak implementation based on the `MemoryNodeStore`
-* Full JCR/Sling features supported e.g. observations manager, transactions, versioning
-* Uses the productive [Sling JCR resource provider implementation][jcr-resource] internally to do the Resource-JCR mapping
-* Takes some seconds for startup on the first access
-* Node types defined in OSGi bundle header 'Sling-Nodetypes' found in MANIFEST.MF files in the classpath are registered automatically.
-* Lucene indexing is not included, thus fulltext search queries will return no result
-
-To use this type you have to declare an additional dependency in your test project:
-
-#!xml
-<dependency>
-<groupId>org.apache.sling</groupId>
-<artifactId>org.apache.sling.testing.sling-mock-oak</artifactId>
-<scope>test</scope>
-</dependency>
-
-See latest version on the [downloads page](/downloads.cgi).
-
-**JCR_JACKRABBIT**
-
-* Uses a real JCR Jackrabbit implementation (not Oak) as provided by [sling/commons/testing][sling-commons-testing]
-* Full JCR/Sling features supported e.g. observations manager, transactions, versioning
-* Uses the productive [Sling JCR resource provider implementation][jcr-resource] internally to do the Resource-JCR mapping
-* Takes some seconds for startup on the first access
-* Node types defined in OSGi bundle header 'Sling-Nodetypes' found in MANIFEST.MF files in the classpath are registered automatically.
-
-To use this type you have to declare an additional dependency in your test project:
-
-#!xml
-<dependency>
-<groupId>org.apache.sling</groupId>
-<artifactId>org.apache.sling.testing.sling-mock-jackrabbit</artifactId>
-<scope>test</scope>
-</dependency>
-
-See latest version on the [downloads page](/downloads.cgi).
-
-_Remarks on the JCR_JACKRABBIT type:_
-
-* The repository is not cleared for each unit test, so make sure to use a unique node path for each unit test. You may use the `uniquePath()` helper object of the SlingContext rule for this.
-* The [sling/commons/testing][sling-commons-testing] dependency introduces a lot of further dependencies from
-jackrabbit and others, be careful that they do not conflict and are imported in the right order in your test project
-
-
-
-### Sling Resource Resolver
-
-Example:
-
-#!java
-// get a resource resolver
-ResourceResolver resolver = MockSling.newResourceResolver();
-
-// get a resource resolver backed by a specific repository type
-ResourceResolver resolver = MockSling.newResourceResolver(ResourceResolverType.JCR_MOCK);
-
-If you use the `SlingContext` JUnit rule you case just use `context.resourceResolver()`.
-
-
-### Adapter Factories
-
-You can register your own or existing adapter factories to support adaptions e.g. for classes extending `SlingAdaptable`.
-
-Example:
-
-#!java
-// register adapter factory
-BundleContext bundleContext = MockOsgi.newBundleContext();
-MockSling.setAdapterManagerBundleContext(bundleContext);
-bundleContext.registerService(myAdapterFactory);
-
-// test adaption
-MyClass object = resource.adaptTo(MyClass.class);
-
-// cleanup after unit test
-MockSling.clearAdapterManagerBundleContext();
-
-Make sure you clean up the adapter manager bundle association after running the unit test otherwise it can
-interfere with the following tests. If you use the `SlingContext` JUnit rule this is done automatically for you.
-
-If you use the `SlingContext` JUnit rule you case just use `context.registerService()`.
-
-
-### SlingScriptHelper
-
-Example:
-
-#!java
-// get script helper
-SlingScriptHelper scriptHelper = MockSling.newSlingScriptHelper();
-
-// get request
-SlingHttpServletRequest request = scriptHelper.getRequest();
-
-// get service
-MyService object = scriptHelper.getService(MyService.class);
-
-To support getting OSGi services you have to register them via the `BundleContext` interface of the
-[JCR Mocks][jcr-mock] before. You can use an alternative factory method for the `SlingScriptHelper` providing
-existing instances of request, response and bundle context.
-
-If you use the `SlingContext` JUnit rule you case just use `context.slingScriptHelper()`.
-
-
-### SlingHttpServletRequest
-
-Example for preparing a sling request with custom request data:
-
-#!java
-// prepare sling request
-ResourceResolver resourceResolver = MockSling.newResourceResolver();
-MockSlingHttpServletRequest request = new MockSlingHttpServletRequest(resourceResolver);
-
-// simulate query string
-request.setQueryString("param1=aaa&param2=bbb");
-
-// alternative - set query parameters as map
-request.setParameterMap(ImmutableMap.<String,Object>builder()
-.put("param1", "aaa")
-.put("param2", "bbb")
-.build());
-
-// set current resource
-request.setResource(resourceResolver.getResource("/content/sample"));
-
-// set sling request path info properties
-MockRequestPathInfo requestPathInfo = (MockRequestPathInfo)request.getRequestPathInfo();
-requestPathInfo.setSelectorString("selector1.selector2");
-requestPathInfo.setExtension("html");
-
-// set method
-request.setMethod(HttpConstants.METHOD_POST);
-
-// set attributes
-request.setAttribute("attr1", "value1");
-
-// set headers
-request.addHeader("header1", "value1");
-
-// set cookies
-request.addCookie(new Cookie("cookie1", "value1"));
-
-
-### SlingHttpServletResponse
-
-Example for preparing a sling response which can collect the data that was written to it:
-
-#!java
-// prepare sling response
-MockSlingHttpServletResponse response = new MockSlingHttpServletResponse();
-
-// execute your unit test code that writes to the response...
-
-// validate status code
-assertEquals(HttpServletResponse.SC_OK, response.getStatus());
-
-// validate content type and content length
-assertEquals("text/plain;charset=UTF-8", response.getContentType());
-assertEquals(CharEncoding.UTF_8, response.getCharacterEncoding());
-assertEquals(55, response.getContentLength());
-
-// validate headers
-assertTrue(response.containsHeader("header1"));
-assertEquals("5", response.getHeader("header2"));
-
-// validate response body as string
-assertEquals(TEST_CONTENT, response.getOutputAsString());
-
-// validate response body as binary data
-assertArrayEquals(TEST_DATA, response.getOutput());
-
-
-### Import resource data from JSON file in classpath
-
-With the `ContentLoader` it is possible to import structured resource and property data from a JSON file stored
-in the classpath beneath the unit tests. This data can be used as text fixture for unit tests.
-
-Example JSON data:
-
-#!json
-{
-"jcr:primaryType": "app:Page",
-"jcr:content": {
-"jcr:primaryType": "app:PageContent",
-"jcr:title": "English",
-"app:template": "/apps/sample/templates/homepage",
-"sling:resourceType": "sample/components/homepage",
-"jcr:createdBy": "admin",
-"jcr:created": "Thu Aug 07 2014 16:32:59 GMT+0200",
-"par": {
-"jcr:primaryType": "nt:unstructured",
-"sling:resourceType": "foundation/components/parsys",
-"colctrl": {
-"jcr:primaryType": "nt:unstructured",
-"layout": "2;colctrl-lt0",
-"sling:resourceType": "foundation/components/parsys/colctrl"
-}
-}
-}
-}
-
-Example code to import the JSON data:
-
-#!java
-context.load().json("/sample-data.json", "/content/sample/en");
-
-This codes creates a new resource at `/content/sample/en` (and - if not existent - the parent resources) and
-imports the JSON data to this node. It can be accessed using the Sling Resource or JCR API afterwards.
-
-
-### Import binary data from file in classpath
-
-With the `ContentLoader` it is possible to import a binary file stored in the classpath beneath the unit tests.
-The data is stored using a nt:file/nt:resource or nt:resource node type.
-
-Example code to import a binary file:
-
-#!java
-context.load().binaryFile("/sample-file.gif", "/content/binary/sample-file.gif");
-
-This codes creates a new resource at `/content/binary/sample-file.gif` (and - if not existent - the parent
-resources) and imports the binary data to a jcr:content subnode.
-
-
-### Building content
-
-Sling Mocks provides two alterantives for quickly building test content in the repository with as few code as possible. Sling Mocks provides two alternatives. Both are quite similar in their results, but follow different API concepts. You can choose whatever matches your needs and mix them as well.
-
-* `ContentBuilder`: Part of Sling Mocks since its first release. If you need a references to each created resource this is the easiest way.
-* `ResourceBuilder`: Separate bundle that can also be used in integration tests or live instances. Supports a "fluent" API to create a bunch of resources in hierarchy at once.
-
-
-#### Building content using `ContentBuilder`
-
-The entry point for the `ContentBuilder` is the `create()` method on the Sling context.
-
-Example:
-
-#!java
-context.create().resource("/content/test1", ImmutableMap.<String, Object>builder()
-.put("prop1", "value1")
-.put("prop2", "value2")
-.build());
-
-Simplified syntax without using a map:
-
-#!java
-context.create().resource("/content/test1",
-"prop1", "value1",
-"prop2", "value2");
-
-
-If you use the `SlingContext` JUnit rule you case just use `context.create()`.
-
-
-#### Building content using `ResourceBuilder`
-
-The entry point for the `ResourceBuilder` is the `build()` method on the Sling context.
-
-Example:
-
-#!java
-context.build().resource("/content/test1")
-.siblingsMode()
-.resource("test1.1", "stringParam", "configValue1.1")
-.resource("test1.2", "stringParam", "configValue1.2")
-.resource("test1.2", "stringParam", "configValue1.3");
-
-See JavaDocs of the class `org.apache.sling.resourcebuilder.api.ResourceBuilder` for a detailed documentation.
-
-
-### Context Plugins
-
-Sling Mocks supports "Context Plugins" that hook into the lifecycle of each test run and can prepare test setup before or after the other setUp actions, and execute test tear down code before or after the other tearDown action.
-
-To define a plugin implement the `org.apache.sling.testing.mock.osgi.context.ContextPlugin<SlingContextImpl>` interface. For convenience it is recommended to extend the abstract class `org.apache.sling.testing.mock.osgi.context.AbstractContextPlugin<SlingContextImpl>`. These plugins can be used with Sling Mock context, but also with context instances deriving from it like AEM Mocks. In most cases you would just override the `afterSetUp` method. In this method you can register additional OSGi services or do other preparation work. It is recommended to define a constant pointing to a singleton of a plugin instance for using it.
-
-To use a plugin in your unit test class, use the `SlingContextBuilder` class instead of directly instantiating the `SlingContext`class. This allows you in a fluent style to configure more options, with the `plugin(...)` method you can add one or more plugins.
-
-Example:
-
-#!java
-@Rule
-public SlingContext context = new SlingContextBuilder().plugin(MY_PLUGIN).build();
-
-More examples:
-
-* [Apache Sling Context-Aware Configuration Mock Plugin][caconfig-mock-plugin]
-* [Apache Sling Context-Aware Configuration Mock Plugin Test][caconfig-mock-plugin-test]
-
-
-
-[osgi-mock]: /documentation/development/osgi-mock.html
-[jcr-mock]: /documentation/development/jcr-mock.html
-[resourceresolver-mock]: /documentation/development/resourceresolver-mock.html
-[jcr-resource]: http://svn.apache.org/repos/asf/sling/trunk/bundles/jcr/resource
-[sling-commons-testing]: http://svn.apache.org/repos/asf/sling/trunk/bundles/commons/testing
-[mockito-testrunner]: http://mockito.github.io/mockito/docs/current/org/mockito/runners/MockitoJUnitRunner.html
-[caconfig-mock-plugin]: https://github.com/apache/sling/blob/trunk/contrib/extensions/contextaware-config/testing/mocks/caconfig-mock-plugin/src/main/java/org/apache/sling/testing/mock/caconfig/ContextPlugins.java
-[caconfig-mock-plugin-test]: https://github.com/apache/sling/blob/trunk/contrib/extensions/contextaware-config/testing/mocks/caconfig-mock-plugin/src/test/java/org/apache/sling/testing/mock/caconfig/ContextPluginsTest.java

http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/development/sling-requests-plugin.jpg
----------------------------------------------------------------------
diff --git a/content/documentation/development/sling-requests-plugin.jpg b/content/documentation/development/sling-requests-plugin.jpg
deleted file mode 100644
index 82f8826..0000000
Binary files a/content/documentation/development/sling-requests-plugin.jpg and /dev/null differ

http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/development/sling-testing-tools.md
----------------------------------------------------------------------
diff --git a/content/documentation/development/sling-testing-tools.md b/content/documentation/development/sling-testing-tools.md
deleted file mode 100644
index 0c02530..0000000
--- a/content/documentation/development/sling-testing-tools.md
+++ /dev/null
@@ -1,165 +0,0 @@
-title=Sling Testing Tools		
-type=page
-status=published
-~~~~~~
-
-<div class="warning">
-While this information is still valid, we recommend using the tools and techniques described
-in the newer "Junit Server-Side Tests Support" page instead, see link below.
-</div>
-
-As mentioned above, this is now replaced by the [Junit Server-Side Tests Support](/documentation/bundles/org-apache-sling-junit-bundles.html) page.
-
-Sling provides a number of testing tools to support the following use cases:
-
-* Run JUnit tests contributed by OSGi bundles in an OSGi system. This does not require Sling and should work in other OSGi  environments.
-* Run scriptable tests in a Sling instance, using any supported scripting language.
-* Run integration tests via HTTP against a Sling instance that is started during the Maven build cycle, or independently.
-
-This page describes those tools, and points to the bundles that implement them.
-
-The [testing/samples/integration-tests](http://svn.apache.org/repos/asf/sling/trunk/testing/samples/integration-tests) module demonstrates these tools, and is also meant as a sample project to show how to run integration tests for Sling-based applications.
-
-The main Sling integration tests at [launchpad/integration-tests](https://svn.apache.org/repos/asf/sling/trunk/launchpad/integration-tests) were created before this testing framework, and do not use it yet (as of March 2011). The new testing tools are simpler to use, but the "old" tests (all 400 of them as I write this) fulfill their validation role for testing Sling itself, there's no real need to modify them to use the new tools.
-
-See also [Testing Sling-based applications](/documentation/tutorials-how-tos/testing-sling-based-applications.html) which discusses testing in general.
-
-## Required bundles
-These tools require a number of bundles on top of the standard Sling launchpad. See the [sample tests pom.xml](http://svn.apache.org/repos/asf/sling/trunk/testing/samples/integration-tests/pom.xml)
-for an up-to-date list. Look for `sling.additional.bundle.*` entries in that pom for the bundle artifact IDs, and see the `dependencies` section for their version numbers.
-
-# Server-side JUnit tests contributed by bundles
-The services provided by the [org.apache.sling.junit.core](http://svn.apache.org/repos/asf/sling/trunk/testing/junit/core) bundle allow bundles to register JUnit tests, which are executed server-side by the JUnitServlet registered by default at `/system/sling/junit`. This bundle is not dependent on Sling, it should work in other OSGi environments.
-
-<div class="warning">
-Note that the JUnitServlet does not require authentication, so it would allow any client to run tests. The servlet can be disabled by configuration if needed, but in general the `/system` path should not be accessible to website visitors anyway.
-</div>
-
-<div class="note">
-For tighter integration with Sling, the alternate `SlingJUnitServlet` is registered with the `sling/junit/testing` resource type and `.junit` selector, if the bundle is running in a Sling system. Using this servlet instead of the plain JUnitServlet also allows Sling authentication to be used for running the tests, and the standard Sling request processing is used, including servlet filters for example.
-</div>
-
-To try the JUnitServlet interactively, install a bundle that contains tests registered via the `Sling-Test-Regexp=.*Test` bundle header.
-
-The JUnit core services use this regular expression to select which classes of the test bundle should be executed as JUnit tests.
-
-To list the available tests, open http://localhost:8080/system/sling/junit/ . The servlet shows available tests, and allows you to execute them via a POST request.
-
-Adding a path allows you to select a specific subset of tests, as in http://localhost:8080/system/sling/junit/org.apache.sling.junit.remote.html - the example integration tests described below use this to selectively execute server-side tests. The JUnitServlet provides various output formats, including in particular JSON, see http://localhost:8080/system/sling/junit/.json for example.
-
-To supply tests from your own bundles, simply export the tests classes and add the `Sling-Test-Regexp` header to the bundle so that the Sling JUnit core services register them as tests.
-
-### Injection of OSGi services
-The `@TestReference` annotation is used to inject OSGi services in tests that are executed server side.The `BundleContext` can also be injected in this way.
-
-## Curl examples
-Here's an example executing a few tests using curl:
-
-$ curl -X POST http://localhost:8080/system/sling/junit/org.apache.sling.testing.samples.sampletests.JUnit.json
-[{
-"INFO_TYPE": "test",
-"description": "testPasses(org.apache.sling.testing.samples.sampletests.JUnit3Test)"
-},{
-"INFO_TYPE": "test",
-"description": "testPasses(org.apache.sling.testing.samples.sampletests.JUnit4Test)"
-},{
-"INFO_TYPE": "test",
-"description": "testRequiresBefore(org.apache.sling.testing.samples.sampletests.JUnit4Test)"
-}
-]
-
-
-And another example with a test that fails:
-
-$ curl -X POST http://localhost:8080/system/sling/junit/org.apache.sling.testing.samples.failingtests.JUnit4FailingTest.json
-
-# Scriptable server-side tests
-If the [org.apache.sling.junit.scriptable](http://svn.apache.org/repos/asf/sling/trunk/testing/junit/scriptable) bundle is active in a Sling system, (in addition to the `org.apache.sling.junit.core` bundle), scriptable tests can be executed by the `JUnitServlet` according to the following rules:
-
-* A node that has the `sling:Test` mixin is a scriptable test node.
-* For security reasons, scriptable test nodes are only executed as tests if they are found under `/libs` or `/apps`, or more precisely under a path that's part of Sling's `ResourceResolver` search path.
-* To execute a test, the scriptable tests provider makes an HTTP request to the test node's path, with a `.test.txt` selector and extension, and expects the output to contain only the string `TEST_PASSED`. Empty lines and comment lines starting with a hash sign (#) are ignored in the output, and other lines are reported as failures.
-
-The [ScriptableTestsTest](http://svn.apache.org/repos/asf/sling/trunk/testing/samples/integration-tests/src/test/java/org/apache/sling/testing/samples/integrationtests/serverside/scriptable/ScriptableTestsTest.java) class, from the integration test samples module described below, sets up such a test node and its accompanying script, and calls the JUnitServlet to execute the test. It can be used as a detailed example of how this works.
-
-Here's a minimal example that sets up and executes a scriptable test:
-
-$ curl -u admin:admin -Fjcr:primaryNodeType=sling:Folder -Fsling:resourceType=foo -Fjcr:mixinTypes=sling:Test http://localhost:8080/apps/foo
-...
-$ echo TEST_PASSED > /tmp/test.txt.esp ; curl -u admin:admin -T/tmp/test.txt.esp http://localhost:8080/apps/foo/test.txt.esp
-
-At this point, foo.test.txt is what the scriptable test framework will request, and that outputs just TEST_PASSED:
-
-$ curl -u admin:admin http://localhost:8080/apps/foo.test.txt
-TEST_PASSED
-
-And a POST to the JUnit servlet returns information on the test's execution:
-
-curl -u admin:admin -XPOST http://localhost:8080/system/sling/junit/org.apache.sling.junit.scriptable.ScriptableTestsProvider.json
-[{
-"INFO_TYPE": "test",
-"description": "verifyContent[0](org.apache.sling.junit.scriptable.TestAllPaths)",
-"test_metadata": {
-"test_execution_time_msec": 2
-}
-}
-]
-
-Test failures would be included in this JSON representation - you can test that by modifying the script to fail and making the
-same request again.
-
-# Integration tests example
-The [testing/samples/integration-tests](http://svn.apache.org/repos/asf/sling/trunk/testing/samples/integration-tests) module runs some simple integration tests against a Sling Launchpad instance that's setup from scratch before running the tests.
-
-This module's pom and Java code can be used as examples to setup your own integration testing modules for Sling-based apps - or for any other runnable jar that provides an http service.
-
-Besides serving as examples, some of the tests in this module are used to validate the testing tools. They run as part of the full Sling [continuous integration](/project-information.html) build, so they're guaranteed to be correct examples if that build is successful.
-
-The sample uses the [testing/tools](http://svn.apache.org/repos/asf/sling/trunk/testing/tools) to make the test code simpler. See the [OsgiConsoleTest|https://svn.apache.org/repos/asf/sling/trunk/testing/samples/integration-tests/src/test/java/org/apache/sling/testing/samples/integrationtests/http/OsgiConsoleTest.java] class for an example of a test that's very readable and requires no test setup or boilerplate code.
-
-The following steps are executed in the `integration-test` phase of this module's Maven  build:
-
-1. A random port number for the Sling server is selected by the Maven build helper plugin, unless explicitely set (see pom.xml for such options).
-1. Additional bundles, defined in the module's pom, are downloaded from the Maven repository in the `target/sling/additional-bundles` folder.
-1. The first test that inherits from the [SlingTestBase](https://svn.apache.org/repos/asf/sling/trunk/testing/tools/src/main/java/org/apache/sling/testing/tools/sling/SlingTestBase.java) class causes the Sling runnable jar (defined as a dependency in the module's pom) to be started.
-1. The `SlingTestBase` class waits for the Sling server to be ready, based on URLs and expected responses defined in the pom.
-1. The `SlingTestBase` class installs and starts the bundles found in the `target/sling/additional-bundles` folder.
-1. The test can now either test Sling directly via its http interface, or use the JUnitServlet to execute server-side tests contributed by bundles or scripts, as described above.
-1. The Sling runnable jar is stopped when the test VM exits.
-1. The test results are reported via the usual Maven mechanisms.
-
-If `-DkeepJarRunning` is used on the Maven command line, the Sling runnable jar does not exit, to allow for running individual tests against this instance, for example when debugging the tests or the server code. See the pom for details.
-
-## Running tests against existing server
-
-Instead of provisioning a completely new Sling server, the ITs can also be executed on an already existing server instance. For that the
-`test-server-url` system property has to point to the existing server url.
-Additional bundles can still be deployed by using the `sling.additional.bundle.<num>` system property.
-
-Optionally, the additional bundles can be undeployed after the execution of the IT by setting `additional.bundles.uninstall` to `true`. (since Sling Testing Tools 1.0.12, [SLING-4819](https://issues.apache.org/jira/browse/SLING-4819))
-
-# Remote test execution
-The testing tools support two types of remote test execution.
-
-## SlingRemoteTestRunner
-The [SlingRemoteTestRunner](http://svn.apache.org/repos/asf/sling/trunk/testing/junit/remote/src/main/java/org/apache/sling/junit/remote/testrunner/SlingRemoteTestRunner.java) is used to run tests using the `JUnitServlet` described above. In this case, the client-side JUnit test only defines which tests to run and some optional assertions. Checking the number of tests executed, for example, can be useful to make sure all test bundles have been activated as expected, to avoid ignoring missing test bundles.
-
-See the [ServerSideSampleTest](https://svn.apache.org/repos/asf/sling/trunk/testing/samples/integration-tests/src/test/java/org/apache/sling/testing/samples/integrationtests/serverside/ServerSideSampleTest.java) class for an example.
-
-It's a good idea to check that the JUnit servlet is ready before running those tests, see the
-[ServerSideTestsBase]( https://svn.apache.org/repos/asf/sling/trunk/testing/samples/integration-tests/src/test/java/org/apache/sling/testing/samples/integrationtests/serverside/sling/SlingServerSideTestsBase.java)
-for an example of how to do that.
-
-## SlingRemoteExecutionRule
-The [SlingRemoteExecutionRule](http://svn.apache.org/repos/asf/sling/trunk/testing/junit/remote/src/main/java/org/apache/sling/junit/remote/ide/SlingRemoteExecutionRule.java) is a JUnit Rule that allows tests to be executed remotely in a Sling instance from an IDE, assuming the test is available on both sides.
-
-The [ExampleRemoteTest](https://svn.apache.org/repos/asf/sling/trunk/testing/junit/remote/src/main/java/org/apache/sling/junit/remote/exported/ExampleRemoteTest.java) class demonstrates this. To run it from your IDE, set the `sling.remote.test.url` in the IDE to the URL of the JUnitServlet, like http://localhost:8080/system/sling/junit for example.
-
-# Debugging ITs
-The JVM is usually forked twice during the execution of integration tests. The first time by the `maven-surefire-plugin` which executes the client-side (i.e. Maven-side) part of the tests. To debug this side the option `-Dmaven.surefire.debug` can be used which waits for a debugger to be attached on port 5005 before the (client-side) test is executed. More information is available in the [documentation of the maven-surefire-plugin](http://maven.apache.org/surefire/maven-surefire-plugin/examples/debugging.html).
-
-Then the `JarExecutor` is forking the VM a second time to start the server (this does not happen if connecting to an already running instance). The system environment variable `jar.executor.vm.options` can be used to start that VM with debug options. All debug options are described at the [JPDA documentation](http://docs.oracle.com/javase/7/docs/technotes/guides/jpda/conninv.html#Invocation). If running
-
-mvn test -Djar.executor.vm.options="-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8000"
-
-the server start is interrupted until a debugger is connected on port 8000.

http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/development/sling.md
----------------------------------------------------------------------
diff --git a/content/documentation/development/sling.md b/content/documentation/development/sling.md
deleted file mode 100644
index 4787b7a..0000000
--- a/content/documentation/development/sling.md
+++ /dev/null
@@ -1,6 +0,0 @@
-title=Maven Sling Plugin		
-type=page
-status=published
-~~~~~~
-
-See [Apache Maven Sling Plugin documentation](http://sling.apache.org/components/maven-sling-plugin/).

http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/development/slingstart.md
----------------------------------------------------------------------
diff --git a/content/documentation/development/slingstart.md b/content/documentation/development/slingstart.md
deleted file mode 100644
index 88cd698..0000000
--- a/content/documentation/development/slingstart.md
+++ /dev/null
@@ -1,346 +0,0 @@
-title=The Apache Sling Provisioning Model and Apache SlingStart		
-type=page
-status=published
-~~~~~~
-
-[TOC]
-
-The Apache Sling provisioning model is a model to describe OSGi based application. It can also be used to define a partial application aka feature (or subsystem in OSGi terms).
-
-The model is describing an instance, it is not directly related to any particular tooling or packaging/provisioning vehicle.
-
-For Apache Maven users, the `slingstart-maven-plugin` uses the model to create an executable application and/or a web application based on the model. Sling's Launchpad is defined using the model and built by this Maven plugin. See [SlingStart Maven Plugin](http://sling.apache.org/components/slingstart-maven-plugin/) for a documentation of the supported goals and parameters.
-
-
-## The Model
-
-The model is a simple API consisting of data objects:
-
-* Model: This is the central object. It consists of features.
-* Feature : this is the central object describing a (partial) system. A feature consists of variables and run modes.
-* Variables: These can be used to define artifact versions, settings values or configuration property values.
-* Run Mode : A run mode contains artifacts, configurations, and settings. The artifacts are divided into artifact groups.
-* Artifact Group: A group of artifacts with an associated start level (the artifacts are usually bundles)
-* Artifact: A deployable artifact described by Maven coordinates.
-* Configuration: A OSGi configuration
-* Settings : Framework settings for the OSGi framework
-
-### Run Modes
-
-The default run mode is always active, and all information provided there will be used/started.
-Custom run modes can be used to configure for different situations. Depending on which run mode is used to start the instance a different set of artifacts or configurations is used.
-Each run mode is associated with a set of run mode names. Only if all listed run modes are active, the definition is used.
-
-The model also supports special run modes, which have special meaning. By default, these pre defined special run modes are available:
-
-* :standalone Artifacts for the standalone application - in contrast to a war.
-* :webapp Artifacts for the webapp only
-
-Other special run modes can be defined by using a single run mode name which starts with a colon, like :test. These run modes can be used by special tooling.
-
-### Start Levels
-
-Each run mode has start levels. These start levels correspond to OSGi start levels. The default start level has the level 0 and should be used for all non bundle artifacts. If a non bundle artifact is configured with a start level, it's still provisioned, however the start level information might not have any meaning. As usually the provisioned artifacts are bundles and as start levels are pretty handy, this was conscious design decision in order to keep the model files small.
-
-### Artifacts
-
-An artifact is defined by Maven coordinates, that is group id, artifact id and version. Type and classifier can be specified, too. Type defaults to "jar". Although the maven way of referring to an artifact is used, the model is in no way tied to Maven and can be used with any tooling. For a plain jar the text definition for an artifact is:
-
-groupId/artifactId/version
-org.apache.sling/api/2.8.0
-
-If you want to specify the type, it's appended after the version:
-
-groupId/artifactId/version/type
-org.apache.sling/api/2.8.0/jar
-
-If you want to specify the classifier, it gets appended after the type:
-
-groupId/artifactId/version/type/classifier
-org.apache.sling/api/2.8.0/jar/test
-
-### Configurations
-
-A configuration has a pid, or a factory pid and an alias and of course the properties of the configuration object.
-
-Special configurations can be marked with a leading ":" of the pid. Special configurations are not added to the OSGi config admin. There are some predefined special configurations
-
-* :web.xml This configuration must be part of the :webapp runmode and contains a complete web.xml for the web application
-* :bootstrap This configuration must be part of either the :boot, :base, :standalone, or :webapp run mode and define the contents for the bootstrap command file executed by Launchpad.
-
-#### Bootstrap Command File
-
-The bootstrap configuration is a text block consisting of uninstall directives. This block is only executed on the first startup.
-
-[feature name=:launchpad]
-
-[configurations]
-# uninstall obsolete bundles which are neither not required anymore or are
-# replaced with new bundles
-:bootstrap
-uninstall org.apache.sling.fragment.activation 1.2
-uninstall org.apache.sling.installer.api [1.0,2.0)
-uninstall org.apache.sling.tests
-
-Each uninstall directive starts with the text "uninstall" followed by the bundle symbolic name. A version range can be specified as well. If no version information is specified, the bundle with that symbolic name is uninstalled on startup. If a version is specified, the bundle is only uninstalled if it's installed with the exact same version. If a range is specified, the bundle is only uninstalled, if the version is within that range.
-
-### Settings
-
-Settings are key value pairs that are added to the framework properties. For now, only settings for the run modes :boot, :base, :standalone, or :webapp are supported.
-
-### Features
-
-Features group run modes and define a special functionality. The model also defines two special features:
-
-* :launchpad This feature contains the dependency to Sling's launchpad artifact to be used. This mode is required if Apache Sling Launchpad should be used to start the application.
-* :boot The artifacts that are installed before the framework is started. They're used to bootstrap the system.
-
-## Model Files
-
-The model comes also with a textual description language:
-
-[feature name=my-feature]
-[variables]
-eventadmin.version=1.0.0
-metatype.version=1.2.0
-
-[artifacts]
-org.apache.sling/eventadmin/${eventadmin.version}
-org.apache.sling/metatype/${metatype.version}
-org.apache.sling/coordinator/3.0.0
-
-[configurations]
-org.apache.sling.eventadmin
-useQueue=true
-ignoreTopics=["myTopic"]
-
-A configuration for a run mode looks like this:
-
-[feature name=my-feature]
-[variables]
-eventadmin.version=1.0.0
-metatype.version=1.2.0
-
-[artifacts runModes=mymode]
-org.apache.sling/metatype/${metatype.version}
-
-[artifacts startLevel=5 runModes=mymode]
-org.apache.sling/eventadmin/${eventadmin.version}
-
-[configurations runModes=mymode]
-org.apache.sling.eventadmin
-useQueue=true
-ignoreTopics=["myTopic"]
-### Comments
-
-Each object in the model can be annotated with comments. A comment is a line starting with a '#'. Leading spaces are ignored.
-
-### Configurations in the Model file
-
-Configuration names are related to the PID and factory PID. The structure of the name is as follows:
-
-
-name ::= <pid> ( '-' <subname> )
-
-
-If the form is just `<pid>`, the configuration contains the properties for a Managed Service. The `<pid>` is then the PID of the Managed Service. See the Configuration Admin service for details.
-
-When a Managed Service Factory is used, the situation is different. The `<pid>` part then describes the PID of the Managed Service Factory. You can pick any `<subname>` which is used as a unique alias. For example:
-
-# Configuration for Managed Service com.acme.xyz
-com.acme.xyz //
-# Managed Service Factory, creates an instance for com.acme.abc
-com.acme.abc-default
-
-
-### Default Configuration Format
-
-Configurations use by default the format of the Apache Felix ConfigAdmin implementation. It allows to specify the type and cardinality of a configuration property and is not limited to string values.
-
-The first line of such a file might start with a comment line (a line starting with a #). Comments within the file are not allowed.
-
-The format is:
-
-file ::= (comment) (header) *
-comment ::= '#' <any>
-header ::= prop '=' value
-prop ::= symbolic-name // 1.4.2 of OSGi Core Specification
-symbolic-name ::= token { '.' token }
-token ::= { [ 0..9 ] | [ a..z ] | [ A..Z ] | '_' | '-' }
-value ::= [ type ] ( '[' values ']' | '(' values ')' | simple )
-values ::= simple { ',' simple }
-simple ::= '"' stringsimple '"'
-type ::= <1-char type code>
-stringsimple ::= <quoted string representation of the value> (see below)
-
-The 1 character type code is one of:
-
-* 'T' : simple string
-* 'I' : Integer
-* 'L' : Long
-* 'F' : Float
-* 'D' : Double
-* 'X' : Byte
-* 'S' : Short
-* 'C' : Character
-* 'B' : Boolean
-
-Apart from the escaping of the usual characters like the quotes, double quotes, backslash etc. the equals sign and spaces need to be escaped as well!
-
-
-###  Configurations Defined through Properties
-
-While the default configuration form is very powerful, it might also sometimes be a little bit too heavy to specify a configuration. For these usage cases, the configuration can be described as properties:
-
-com.acme.xyz [format=properties]
-ftp.port = 21
-
-Notice that this definition only supports string properties. Therefore the service consuming the configuration needs to be able to adapt a string value to the correct type.
-
-## Slingstart and Slingfeature projects
-
-The `slingstart-maven-plugin` introduces two new packaging types:
-
-* `slingstart` : This type requires a model at src/main/provisioning. It reads all text files in that directory and merges them in alphabetical order. The resulting artifact is a runnable jar. The assembled model is also attached to the project artifacts.
-* `slingfeature` : This type requires a model at src/main/provisioning. It reads all text files in that directory and merges them in alphabetical order and creates a merged model which is the final artifact of this project.
-
-A model can reference other slingstart or slingfeature artifacts. When such an artifact is reference, the type needs to be specified, for example:
-
-[artifacts]
-org.apache.sling/org.apache.sling.launchpad/8-SNAPSHOT/slingstart
-org.apache.sling/org.apache.sling.launchpad.test-bundles/0.0.1-SNAPSHOT/slingfeature
-
-The resulting model is a merged model, starting with the dependencies and then merging in the current model.
-
-By default the Maven classpath is extended by the dependencies of the merged model. This behaviour can be disabled though via setting the parameter `disableExtendingMavenClasspath` to `true` ([SLING-6541](https://issues.apache.org/jira/browse/SLING-6541)).
-
-## Model Merging
-
-If two or more models are supplied, they are merged feature by feature, each feature being treated as a separate unit.
-
-Within a feature each run mode is treated separately as well.
-
-Within a run mode, a model can overwrite definitions from the base model. For example, it can define a different configuration or a different version and/or start level for an artifact.
-
-The supplied models are ordered alphanumercally by their filenames for merging.
-
-### Removing and Changing of Artifacts
-
-In addition, it can also remove artifacts and configurations. For this the special runmode :remove needs to be used together with all run modes the artifact or configuration is currently in.
-
-Let's look at an example base model
-
-[artifacts]
-my/special/artifact/1.0.0
-commons/library/1.0.0
-
-[artifacts runModes=test]
-another/one/2.1.0
-
-Another model wants to use the above model as it's base but:
-
-* Change the version of the commons library to 1.1.0 and move it to a different start level.
-* Remove the "special artifact"
-* Remove the "another one"
-
-The changing model would mention the above as one artifact and in addition have:
-[artifacts startLevel=5]
-commons/library/1.1.0
-
-[artifacts runModes=:remove]
-my/special/artifact/0.0.0
-
-[artifacts runModes=:remove,test]
-another/one/0.0.0
-
-Note that the version for removal does not play a role, it's not compared for an exact match. But please keep in mind that the remove directive needs to be specified in the same feature and run mode as the original.
-
-### Removing and Changing of Configurations
-
-Configurations can be removed in the same way by just specifying their PID in the :remove run mode. This is the base model:
-
-[configurations]
-my.special.configuration.b
-foo="bar"
-another.special.configuration.a
-x="y"
-
-When this model is merged with the following model, the resulting model has a different configuration for my.special.configuration.b and no configuration for another.special.configuration.a:
-
-[configurations]
-my.special.configuration.b
-a="b"
-
-[configurations runModes=:remove]
-another.special.configuration.a
-
-By default if a model inherits from another and uses the same configuration pid, the configuration is overwritten! In the above example, the configuration my.special.configuration.b contains a single property named "a".
-
-It is also possible to merge configurations:
-
-[configurations]
-my.special.configuration.b [mode=merge]
-a="b"
-
-When the merge directive is used, the configurations are merged and the properties are applied as a delta to the base configuration. Therefore the configuration my.special.configuration.b will have two properties "a" and "foo".
-
-If a merged configuration redefines a property that already exists, it overwrites it, so the last configuration supplied in a merge wins.
-
-## Starting a server
-
-Use the goal with name `start` to start one or multiple servers. The goal is bound by default to the [`pre-integration-test` lifecycle phase](https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference). The launchpad JAR used to start the server is being looked up from the following locations:
-
-1. the file path given in the configuration field `launchpadJar` or parameter `launchpad.jar`
-2. the slingstart artifact being referenced in the configuration element `launchpadDependency`
-3. the artifact being created through the Maven project itself (through model definitions found below `src/main/provisioning` or `src/test/provisioning` which are consumed by the goals `prepare-package` and `package` ([SLING-6068](https://issues.apache.org/jira/browse/SLING-6068)) ).
-4. the first dependency of type `slingstart`
-
-The server itself is configured within an element `server` below the configuration element `servers`. It supports the following configuration settings
-
-Name | Type | Description | Default Value | Mandatory
----- | ---- | ----------- | ------------- | ---------
-port     | String | The port on which the server is listening for HTTP requests. Arbitrary if not set. | - | no
-id       | String | The instance id for this server. If not set the id is automatically generated from the run modes and the port. | - | no
-runmode  | String | The comma-separated list of [run modes](/documentation/bundles/sling-settings-org-apache-sling-settings.html#run-modes) to be set for this server. Those will be set in addition to the ones being defined by the underlying model. | - | no
-contextPath | String | The context path. If not set then Sling is deployed in the root context. | - | no
-controlPort | String | The TCP [control port](/documentation/the-sling-engine/the-sling-launchpad.html#control-port) on which the server is listening for control commands. Arbitrary if not set. | - | no
-instances | int | The number of instances which should be created from this server element. In this case the configuration acts as template. The port and controlPort for all servers being generated from this configuration are random (except for the first server). | 1 | no
-folder | String | The folder from where to start Sling. If not set is a folder in the project's build directory named like the `id`. | - | no
-vmOpts | String | The JVM options to use. | `-Xmx1024m -XX:MaxPermSize=256m -Djava.awt.headless=true` | no
-opts | String | Additional application options. | - | no
-debug | String | See below for an explanation. | - | no
-stdOutFile | String | The relative filename of the file which receives both the standard output (stdout) and standard error (stderr) of the server processes. If null or empty string the server process inherits stdout from the parent process (i.e. the Maven process). The given filename must be relative to the working directory of the according server. This was added with [SLING-6545](https://issues.apache.org/jira/browse/SLING-6545). | null | no
-
-### Debugging
-
-Since version 1.2.0 of this plugin it is possible to easily start a Sling server in debug mode ([SLING-4677](https://issues.apache.org/jira/browse/SLING-4677)). For that you either configure the property `debug` inside you server configuration in the pom.xml accordingly or by using the parameter `Dlaunchpad.debug`. Both values can either be `true` (in which case the [JDWP options](http://docs.oracle.com/javase/7/docs/technotes/guides/jpda/conninv.html#Invocation) `-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000` are appended to the VM options) or just some arbitrary string defining debugging options.
-In case both are used the parameter `Dlaunchpad.debug` takes precedence.
-
-## Stopping a server
-
-Use the goal with name `stop` to stop one or multiple servers. The goal is bound by default to the [`post-integration-test` lifecycle phase](https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference).
-
-## Known Issues
-
-### Support of configuration formats
-
-The provisioning model supports two formats to define configurations, properties and the format of the Apache Felix ConfigAdmin implementation.
-
-Starting with version 1.2.0 of the provisioning model and version 1.2.0 of the slingstart-maven-plugin, the implementation uses the latest format from Apache Felix, version 1.8.6 (or higher) of the ConfigAdmin. This requires you to use version 3.6.6 (or higher) of the OSGi installer core bundle to handle these configurations.
-
-If you want to stick with the old format from config admin, you can configure the maven plugin as follows:
-
-<plugin>
-<groupId>org.apache.sling</groupId>
-<artifactId>slingstart-maven-plugin</artifactId>
-<extensions>true</extensions>
-<version>1.3.4</version>
-<dependencies>
-<dependency>
-<groupId>org.apache.felix</groupId>
-<artifactId>org.apache.felix.configadmin</artifactId>
-<version>1.8.4</version>
-</dependency>
-</dependencies>
-</plugin>
-

http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/development/version-policy.md
----------------------------------------------------------------------
diff --git a/content/documentation/development/version-policy.md b/content/documentation/development/version-policy.md
deleted file mode 100644
index a9e42ad..0000000
--- a/content/documentation/development/version-policy.md
+++ /dev/null
@@ -1,211 +0,0 @@
-title=Version Policy		
-type=page
-status=published
-~~~~~~
-Excerpt: This page is about how we assign versions to exported packages and bundles and defines when to increase which part of the version number.
-
-This page is about how we assign versions to exported packages and bundles and defines when to increase which part of the version number.
-
-<div class="info">
-Please note that this page is currently in draft stage and still being discussed.
-</div>
-
-[TOC]
-
-## Introduction
-
-In comments to [SLING-1176](https://issues.apache.org/jira/browse/SLING-2944) Ian Boston wrote:
-
-> The exports in bundle/api/pom.xml look like they might become problematic from a support point of view, although we probably can't avoid this. [...] [The problem is the] manual maintenance of the version numbers. (not a big problem but needs to be done)
-
-I agree, that this is a problem. So let me reasonate on this a bit ;-)
-
-As a reference you might want to read [my blog post on version numbers](http://blog.meschberger.ch/2009/10/on-version-numbers.html) and also what the [Eclipse guys have to say](http://wiki.eclipse.org/index.php/Version_Numbering) (great read, btw). The OSGi Alliance has come up with a good definition for [Semantic Versioning](http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf) to which the definitions described below perfectly match.
-
-For Sling we have three kinds of version numbers:
-
-1. Big Sling Releases
-1. Sling Bundles
-1. Package Exports
-
-### Big Sling Releases
-
-For *Big Sling Releases* we already have an ample solution in that we just use a single number increased from release to release. Just remember that a *Big Sling Release* is a convenience release of existing released Sling bundles.
-
-### Sling Bundles
-
-For *Sling Bundles* version numbers are just defined as the `<version>` element of the bundle's POM. The only restriction here is, that we decided to use even numbers for releases and odd numbers for SNAPSHOTs. Whether and when which version part is increased is not explicitly defined yet.
-
-### Package Exports
-
-For *Package Exports* the situation is more problematic since there are a number of places to set exported package version number:
-
-* In a `packageinfo` file inside the package (picked up by the Maven Bundle Plugin to set the export version)
-* Explicitly in the `<Export-Package>` element of the Maven Bundle Plugin configuration
-* By reference to the bundle version number using the `${pom.version}` variable.
-
-Up to now, we mostly used the `${pom.version}` notation linking the exported package version to the bundle version. Over time this mechanism leads to a number of problems:
-
-* For bundles with more than one package exported, the exported packages will evolve independently. As a consequence their versioning should also evolve independently. An example of such a bundle is the Sling API bundle of course.
-* Linking the package export version number to the bundle version number confuses the actual semantics of both version numbers. The package export version number only indicates the version of the actual package while the bundle version number indicates a development state of the overall bundle. This will generally not be the same.
-* The version of the exported package is increased on each bundle release, even though nothing may have changed on the export. In such a situation the version of the export should stay the same.
-
-That said, the reuse of the bundle version as the package export version still is probably the correct thing to do for legacy library wrappers.
-
-Consider for example the Sling API bundle, which exports 9 packages. Each of which may evolve independently. Now the `resource` package is extended causing a minor version increase. Should the version numbers of the other exports also be increased ? Thus acting as if there was some API change ?
-
-I would say, no. Particularly if some API implementation bundle is restricting the import version of the API implemented. Such an implementation would immediately stop working because the version has been increased. But since there has been no change, the implementation would still be correct.
-
-So, I think, we should evolve the exported package versions independently from each other and even independently from the bundle version.
-
-This places more burden on the developer when deciding on the exported package version - in fact this requires such a decision as compared to have Maven take the decision by just setting the bundle version.
-
-The only problem is: Where shall this be noted ? In the POM or in the `packageinfo` file ? If we would place the `packageinfo` file just beneath the class source files, I would say, in the `packageinfo` file.
-
-But this would require defining the class source locations as resource location in the POM (at least for `packageinfo`) files.
-
-I am not sure ....
-
-This has not been discussed at large, but I would assume, that the POM is still the correct place to take note of the version of the exported packages.
-
-### Future
-
-The newest versions of the bnd library also support an `@Export` annotation in the `package-info.java` pseudo class file. This pseudo class is supported starting with Java 5 to take package level annotations (like the `@Export` annotation) and as a replacement of the `package-info.html` file.
-
-Using this syntax something like the following would be easily possible:
-
-
-/**
-* This is the Package Level JavaDoc
-*/
-@Export(version = "1.0")
-package org.apache.sling.api.auth;
-import aQute.bnd.annotation.Export;
-
-
-See [bnd Versioning](http://bnd.bndtools.org/chapters/170-versioning.html) for details.
-
-
-## Version Number Syntax
-
-As a small reminder, this is how a version number is constructed:  In OSGi version numbers are composed of four (4) segments: three integers and one string named _major_._minor_._micro_._qualifier_.
-
-Each segment captures a different intent:
-
-* the major segment indicates breakage in the API
-* the minor segment indicates *externally visible* changes
-* the micro segment indicates bug fixes
-* the qualifier segment is not generally used but may be used to convey more information about a particular build, such as a build time or a SVN revision number.
-
-
-## Evolution of Exported Package Versions
-
-Version numbers of exported packages evolve independently from each other. Depending on the changes applied, the micro, minor, or major segement is increased. Whenever the major segment is increased, the minor and micro segments are reset to zero. Whenever the minor segment is increased, the micro segment is reset to zero.
-
-Segments are increased according to the above listing.
-
-This requires committers to think well about changes they apply to exported packages:
-
-* Removing interfaces, methods or constants is likely an API breakage and thus requires a major version increase. In Sling we try to prevent this from happening.
-* Adding new methods to interfaces is likely just an *externally visible* change and thus requires a minor version increase
-* Fixing a bug in an exported class just requires a minor version increase.
-
-JavaDoc updates generally do not constitute a reason to evolve the version number. The exception is that if the JavaDoc update is caused by a API limitation, it might be conceivable to increase the version number of the exported package. A decision on this will have to be taken on a case-by-case basis.
-
-
-## Evolution of Bundle Versions
-
-Version numbers of bundles evolve depending on the evolution of the exported packages but also depending on the evolution of the private code, which is not exported.
-
-As a rule of thumb, the following reasons apply for increasing the segments of bundle version numbers:
-
-* Increasing the major version number of any of the exported packages or restructuring the bundle such that major parts are removed from the bundle (and either completely removed or moved to other bundle(s)).
-* Increasing the minor version number of any of the exported packages or refactoring the internal code or implementing a package exported by another bundle whose minor (or even major) version number has increased. Also functional extensions of the internal bundle classes consitutes a reason to increase the minor version number.
-* Increasing the micro version number of any of the exported packages or bug fixes.
-
-Note, that this definition does not require the bundle and epxorted package version numbers to be synchronized in any way. While doing so might help in a first or second step, over time it will become close to impossible to keep the versions in sync. So rather than trying to keep the versions in sync, we should make sure, we increase the versions correctly.
-
-
-## Examples
-
-
-### Pure API Bundle
-
-An example of an almost *Pure API Bundle* is the Sling API bundle. This bundle exports 9 packages. Some are really stable -- e.g. the `org.apache.sling.api` package or the `org.apache.sling.wrappers` package -- and some are being worked on at the moment -- e.g. the `org.apache.sling.resource` package.
-
-To not break existing users of the unmodified packages, the exported versions of these packages must not be increased.
-
-To signal to users of evolving packages, that there might be new and interesting functionality, the version number must be increased according to above definition. This also conveys to the implementor(s) of the API, that they have to take some action.
-
-
-A hypothetical evolution of version numbers shown on two packages and the bundle version might be as follows
-
-| Description | `api` package | `resource` package | bundle |
-|-|-|-|-|
-| Initial Release | 1.0.0 | 1.0.0 | 1.0.0 |
-| Bug fix in a `resource` class | 1.0.0 | 1.0.2 | 1.0.2 |
-| New API in the `resource` package | 1.0.0 | 1.1.0 | 1.1.0 |
-| New API in the `api` package | 1.1.0 | 1.1.0 | 1.2.0 |
-| API breakage in the `api` package | 2.0.0 | 1.1.0 | 2.0.0 |
-
-
-### Implementation Bundle providing API
-
-An example of such a hybrid bundle is the Sling Engine bundle. This bundle exports two packages themselves defining API and contains a number of internal packages which actually implement parts of the Sling API.
-
-A hypothetical evolution of version numbers shown on one exported package and the bundle version might be as follows
-
-| Description | `engine` package | bundle |
-|-|-|-|
-| Initial Release | 1.0.0 | 1.0.0 |
-| Bug fix in a `engine` class | 1.0.2 | 1.0.2 |
-| Bug fix in an internal calss | 1.0.2 | 1.0.4 |
-| New API in the `engine` package | 1.1.0 | 1.1.0 |
-| Implement new API from `api` 1.1.0 | 1.1.0 | 1.2.0 |
-| Refactor internal classes | 1.1.0 | 1.3.0 |
-| Implement API from `api` 2.0.0 | 1.1.0 | 2.0.0 |
-
-
-### Pure Implementation Bundle
-
-For Pure Implementation Bundles only the bundle version numbers are maintained because there is no exported package whose version number needs to be managed. This makes the decision process of version number evolution very simple.
-
-
-## Importing Packages
-
-
-When importing packages a version number will automatically be generated by the Maven Bundle Plugin as follows:
-
-* If the providing package exports a package with an explicit version number, that exact version number will be used as the lower bound
-* If such a lower bound exists, the upper bound is exclusive the next major version number.
-
-For example if importing the `api` package exported at version 1.2.3, the `Import-Package` statement is generated as
-
-
-Import-Package: api;version=[1.2.3,2.0.0)
-
-
-
-This default works well for consumers of the API, since according to above definitions an API is guaranteed to not contain breakages if the major version number is not increased.
-
-For bundles implementing the API, this default does not work well, since from their point of view an *externally visible* change in fact constitutes a breakage, because the implementation is not complete. So if a bundle implements a package a manually crafted import version should be defined which includes the export version of the defining bundle but excludes the next minor version.
-
-For example implementing the `api` package exported at version 1.2.3, would require the following manually created `Import-Package` statement:
-
-
-Import-Package: api;version=[1.2.3,1.3.0)
-
-
-This allows for the implementation to work correctly with bug fixed package exports but as soon as there are any *externally visible* changes, the implementation bundle has to be adapted -- even if this just means increasing the upper version bound in the `Import-Package` statement thus guaranteeing compliance (again).
-
-### Future
-
-Recent versions of the bnd library support automatic differentiation between _use_ and _implementation_ of API and to set the import version ranges accordingly. See [bnd Versioning](http://bnd.bndtools.org/chapters/170-versioning.html) for details.
-
-## References
-
-* [Version Numbers](http://markmail.org/thread/zshobgjwtqrncajt) -- The mail thread discussing version numbering
-* [On Version Numbers](http://blog.meschberger.ch/2009/10/on-version-numbers.html) -- Blog about version numbers
-* [Version Numbering](http://wiki.eclipse.org/index.php/Version_Numbering) -- An Eclipse paper on assigning version numbers. Very good read.
-* [Semantic Versioning](http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf) -- An OSGi Alliance paper on semantic versioning.
-* [bnd Versioning](http://bnd.bndtools.org/chapters/170-versioning.html) -- Describes how the bnd library used by the Maven Bundle plugin supports package versioning

http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/getting-started.md
----------------------------------------------------------------------
diff --git a/content/documentation/getting-started.md b/content/documentation/getting-started.md
deleted file mode 100644
index 5174498..0000000
--- a/content/documentation/getting-started.md
+++ /dev/null
@@ -1,23 +0,0 @@
-title=Getting Started		
-type=page
-status=published
-~~~~~~
-
-We're on the way to update the documentation to make it more easy to get in touch with Sling. At the moment we can give you the following starting points:
-
-{% for label, page in children %}* [{{ page.headers.title }}]({{ page.path }})
-{% endfor %}
-
-## Where to head from here
-
-We recommend you read through following topics to get as fast as possible into Sling:
-
-* [Getting and building Sling](/documentation/development/getting-and-building-sling.html)
-* [Architecture](/documentation/the-sling-engine/architecture.html)
-* [Dispatching Requests](/documentation/the-sling-engine/dispatching-requests.html)
-* [Resources](/documentation/the-sling-engine/resources.html)
-* [{{ refs.ide-tooling.headers.title }}](/documentation/development/ide-tooling.html)
-* [Manipulating Content - The SlingPostServlet (servlets.post)](/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html)
-* [Request Parameters](/documentation/the-sling-engine/request-parameters.html)
-* [Authentication](/documentation/the-sling-engine/authentication.html)
-* [Eventing and Jobs]({{ refs.eventing-and-jobs.path }})


Mime
View raw message