sling-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r1328899 [5/8] - in /sling/site/trunk: content/ templates/
Date Sun, 22 Apr 2012 16:52:16 GMT
Added: sling/site/trunk/content/links.mdtext
--- sling/site/trunk/content/links.mdtext (added)
+++ sling/site/trunk/content/links.mdtext Sun Apr 22 16:52:13 2012
@@ -0,0 +1,81 @@
+Title: Links
+<a name="Links-Links"></a>
+# Links
+Here are some links to other resources
+<a name="Links-Articles"></a>
+## Articles
+   * [Java Content Repository: The Best Of Both Worlds](
+ - by Bertrand Delacretaz on Javalobby - uses the Sling HTTP interface to
+demonstrate JCR features.
+   * [Accessing Relational Data as SLING RESTful URLs](
+ - by Luca Masini
+   * [Your First Day With Sakai Nakamura](
+ - Sakai Nakamura is based on Sling, that introductory article has very
+good explanations of REST and Sling basics, and on why hierarchies are
+useful on the Web.
+<a name="Links-AboutSling"></a>
+## About Sling
+   * [Sling on](
+ - Day's developers blog, regularly includes articles on Sling and JCR.
+Powered by Sling, of course.
+   * [Sling on Lars Trieloff's Blog](
+ - Lars regularly writes on his experiences with Sling. Most notably the
+mini series of three entries introducing Sling and microsling.
+   * [Sling links at](
+ - If you're a user, please tag Sling-related posts with both
+_sling_ and _jcr_ tags, so that they appear in that list.
+   * [Sling on Fisheye](
+ - code repository viewer, activity statistics, etc.
+   * [Sling on ohloh](
+ - activity and community statistics.
+   * [Sling on MarkMail](
+ - searchable mailing list archives.
+<a name="Links-ProjectsusingSling"></a>
+## Projects using Sling
+   * Gert Vanthienen succeeded in installing Sling into the new Apache
+ServiceMix kernel and documented his experience [Sling On ServiceMix Kernel](
+<a name="Links-SlingPresentationsandScreencasts"></a>
+## Sling Presentations and Screencasts
+   * [Presentations tagged with "sling" at slideshare](
+The following screencasts demonstrate Day Software's CRX quickstart
+product, powered by Sling:
+   * [First Steps with CRX Quickstart](
+   * [ in 15 minutes](
+<a name="Links-FromApacheConEU08"></a>
+## From ApacheCon EU 08
+   * [ApacheCon EU 08 Fast Feather Track Presentation on Sling](^apacheconeu08_fft_sling.pdf.html)
+   * [JCR Meetup Presentation on Sling Architecture](^apacheconeu08_jcr_meetup_sling_architecture.pdf.html)
+<a name="Links-FromApacheConUS07"></a>
+## From ApacheCon US 07
+   * [ApacheCon US 07 Fast Feather Track Presentation on Sling](^apacheconus07_fft_sling.pdf.html)
+   * [Feathercast On Day 4 with an interview on Sling with Felix](
+<a name="Links-TechnologyusedbySling"></a>
+## Technology used by Sling
+   * [Apache Jackrabbit](
+ - The reference implementation of the Content Repository for Java (JCR)
+Specification. This implementation is used in Sling as the primary
+   * [JSR 170: Content Repository for Java{tm} technology API](
+ - The specification of the repository API.
+   * [Apache Felix](
+ - The OSGi Framework implementation we use in Sling.
+   * [The OSGi Alliance](
+ - The OSGi Alliance is the specification body defining the OSGi Core and
+Compendium Services. These specifications are at the center of making Sling

Added: sling/site/trunk/content/logging.mdtext
--- sling/site/trunk/content/logging.mdtext (added)
+++ sling/site/trunk/content/logging.mdtext Sun Apr 22 16:52:13 2012
@@ -0,0 +1,223 @@
+Title: Logging
+<a name="Logging-Logging"></a>
+# Logging
+<a name="Logging-Introduction"></a>
+## Introduction
+Logging in Sling is supported by the **
+bundle, which is one of the first bundles installed and started by the
+Sling Launcher. The ** bundle has the
+following tasks:
+   * Implements the OSGi Log Service Specification and registers the
+*LogService* and *LogReader* services
+   * Exports three commonly used logging APIs:
+      ** [Simple Logging Facade for Java (SLF4J)](-
+      ** [Apache Commons Logging](
+      ** [log4j](
+      ** [java.util.logging](
+ (as of r1169918)
+   * Configures logging through our own implementation of the SLF4J backend
+<a name="Logging-InitialConfiguration"></a>
+## Initial Configuration
+The ** bundle gets the initial configuration
+from the following *BundleContext* properties:
+<tr><th> Property </th><th> Default </th><th> Description </th></tr>
+<tr><td> ** </td><td> *INFO* </td><td> Sets the initial
+logging level of the root logger. This may be any of the defined logging
+levels *DEBUG*, *INFO*, *WARN*, *ERROR* and *FATAL*. </td></tr>
+<tr><td> ** </td><td> undefined </td><td> Sets the log file to
+which log messages are written. If this property is empty or missing, log
+messages are written to *System.out*. </td></tr>
+<tr><td> ** </td><td> 5 </td><td> The number of rotated
+files to keep. </td></tr>
+<tr><td> ** </td><td> '.'yyyy-MM-dd </td><td> Defines how
+the log file is rotated (by schedule or by size) and when to rotate. See
+the section _Log File Rotation_ below for full details on log file
+rotation. </td></tr>
+<tr><td> ** </td><td> \{0,date,dd.MM.yyyy HH:mm:ss.SSS\} \*\{4\}\* \[\{2\}\](\{2\}\.html)
+ \{3\} \{5\} </td><td> The *MessageFormat* pattern to use for formatting log
+messages with the root logger. </td></tr>
+<tr><td> ** </td><td> n/a </td><td> Enables the
+*java.util.logging* support. </td></tr>
+<a name="Logging-UserConfiguration"></a>
+## User Configuration
+User Configuration after initial configuration is provided by the
+Configuration Admin Service. To this avail two
+** services are registered
+under the PIDs **
+and ** which may
+receive configuration.
+<a name="Logging-LoggerConfiguration"></a>
+### Logger Configuration
+Loggers (or Categories) can be configured to log to specific files at
+specific levels using configurable patterns. To this avail factory
+configuration instances with factory PID
+** may be created
+and configured with the Configuration Admin Service.
+The following properties may be set:
+<tr><th> Property </th><th> Type </th><th> Default </th><th> Description </th></tr>
+<tr><td> ** </td><td> String </td><td> *INFO* </td><td> Sets the
+logging level of the loggers. This may be any of the defined logging levels
+*DEBUG*, *INFO*, *WARN*, *ERROR* and *FATAL*. </td></tr>
+<tr><td> ** </td><td> String </td><td> undefined </td><td> Sets the log
+file to which log messages are written. If this property is empty or
+missing, log messages are written to *System.out*. This property should
+refer to the file name of a configured Log Writer (see below). If no Log
+Writer is configured with the same file name an implicit Log Writer
+configuration with default configuration is created. </td></tr>
+<tr><td> ** </td><td> String </td><td> \{0,date,dd.MM.yyyy HH:mm:ss.SSS\} \*\{4\}\* \[\{2\}\](\{2\}\.html)
+ \{3\} \{5\} </td><td> The *java.util.MessageFormat* pattern to use for
+formatting log messages with the root logger. This is a
+*java.util.MessageFormat* pattern supporting up to six arguments: \{0\}
+The timestamp of type *java.util.Date*, \{1\} the log marker, \{2\} the
+name of the current thread, \{3\} the name of the logger, \{4\} the debug
+level and \{5\} the actual debug message. If the log call includes a
+Throwable, the stacktrace is just appended to the message regardless of the
+pattern. </td></tr>
+<tr><td> ** </td><td> String[](.html)
+ </td><td> -- </td><td> A list of logger names to which this configuration applies. </td></tr>
+Note that multiple Logger Configurations may refer to the same Log Writer
+Configuration. If no Log Writer Configuration exists whose file name
+matches the file name set on the Logger Configuration an implicit Log
+Writer Configuration with default setup (daily log rotation) is internally
+<a name="Logging-LogWriterConfiguration"></a>
+### Log Writer Configuration
+Log Writer Configuration is used to setup file output and log file rotation
+characteristics for log writers used by the Loggers.
+The following properties may be set:
+<tr><th> Property </th><th> Default </th><th> Description </th></tr>
+<tr><td> ** </td><td> undefined </td><td> Sets the log file to
+which log messages are written. If this property is empty or missing, log
+messages are written to *System.out*. </td></tr>
+<tr><td> ** </td><td> 5 </td><td> The number of rotated
+files to keep. </td></tr>
+<tr><td> ** </td><td> '.'yyyy-MM-dd </td><td> Defines how
+the log file is rotated (by schedule or by size) and when to rotate. See
+the section _Log File Rotation_ below for full details on log file
+rotation. </td></tr>
+See the section _Log File Rotation_ below for full details on the
+** and
+** properties.
+<a name="Logging-LogFileRotation"></a>
+## Log File Rotation
+Log files can grow rather quickly and fill up available disk space. To cope
+with this growth log files may be rotated in two ways: At specific times or
+when the log file reaches a configurable size. The first method is called
+_Scheduled Rotation_ and is used by specifying a *SimpleDateFormat*
+pattern as the log file "size". The second method is called _Size Rotation_
+and is used by setting a maximum file size as the log file size.
+As of version 2.0.6 of the Sling Commons Log bundle, the default value for
+log file scheduling is *'.'yyyy-MM-dd* causing daily log rotation.
+Previously log rotation defaulted to a 10MB file size limit.
+<a name="Logging-ScheduledRotation"></a>
+### Scheduled Rotation
+The rolling schedule is specified by setting the
+** property to a
+*java.text.SimpleDateFormat* pattern. Literal text (such as a leading
+dot) to be included must be _enclosed_ within a pair of single quotes. A
+formatted version of the date pattern is used as the suffix for the rolled
+file name.
+For example, if the log file is configured as */foo/bar.log* and the
+pattern set to *'.'yyyy-MM-dd*, on 2001-02-16 at midnight, the logging
+file */foo/bar.log* will be renamed to */foo/bar.log.2001-02-16* and
+logging for 2001-02-17 will continue in a new */foo/bar.log* file until
+it rolls over the next day.
+It is possible to specify monthly, weekly, half-daily, daily, hourly, or
+minutely rollover schedules.
+<tr><th> DatePattern </th><th> Rollover schedule </th><th> Example </th></tr>
+<tr><td> *'.'yyyy-MM* </td><td> Rollover at the beginning of each month </td><td> At midnight of
+May 31st, 2002 */foo/bar.log* will be copied to */foo/bar.log.2002-05*.
+Logging for the month of June will be output to */foo/bar.log* until it
+is also rolled over the next month. </td></tr>
+<tr><td> *'.'yyyy-ww* </td><td> Rollover at the first day of each week. The first day of
+the week depends on the locale. </td><td> Assuming the first day of the week is
+Sunday, on Saturday midnight, June 9th 2002, the file */foo/bar.log* will
+be copied to */foo/bar.log.2002-23*. Logging for the 24th week of 2002
+will be output to */foo/bar.log* until it is rolled over the next week. </td></tr>
+<tr><td> *'.'yyyy-MM-dd* </td><td> Rollover at midnight each day.</td><td> At midnight, on March
+8th, 2002, */foo/bar.log* will be copied to */foo/bar.log.2002-03-08*.
+Logging for the 9th day of March will be output to */foo/bar.log* until
+it is rolled over the next day.</td></tr>
+<tr><td> *'.'yyyy-MM-dd-a* </td><td> Rollover at midnight and midday of each day.</td><td> at
+noon, on March 9th, 2002, */foo/bar.log* will be copied to 
+*/foo/bar.log.2002-03-09-AM*. Logging for the afternoon of the 9th will
+be output to */foo/bar.log* until it is rolled over at midnight.</td></tr>
+<tr><td> *'.'yyyy-MM-dd-HH* </td><td> Rollover at the top of every hour.</td><td> At
+approximately 11:00.000 o'clock on March 9th, 2002, */foo/bar.log* will
+be copied to */foo/bar.log.2002-03-09-10*. Logging for the 11th hour of
+the 9th of March will be output to */foo/bar.log* until it is rolled over
+at the beginning of the next hour.</td></tr>
+<tr><td> *'.'yyyy-MM-dd-HH-mm* </td><td> Rollover at the beginning of every minute.</td><td> At
+approximately 11:23,000, on March 9th, 2001, */foo/bar.log* will be
+copied to */foo/bar.log.2001-03-09-10-22*. Logging for the minute of
+11:23 (9th of March) will be output to */foo/bar.log* until it is rolled
+over the next minute.</td></tr>
+Do not use the colon ":" character in anywhere in the pattern option. The
+text before the colon is interpeted as the protocol specificaion of a URL
+which is probably not what you want.
+Note that Scheduled Rotation ignores the
+** property since the old log
+files are not numbered but "dated".
+<a name="Logging-SizeRotation"></a>
+### Size Rotation
+Log file rotation by size is specified by setting the
+** property to a plain number or a
+number plus a size multiplier. The size multiplier may be any of *K*,
+*KB*, *M*, *MB*, *G*, or *GB* where the case is ignored and the
+meaning is probably obvious.
+When using Size Rotation, the **
+defines the number of old log file generations to keep. For example to keep
+5 old log files indexed by 0 through 4, set the
+** to *5* (which happens to be
+the default).

Added: sling/site/trunk/content/mappings-for-resource-resolution.mdtext
--- sling/site/trunk/content/mappings-for-resource-resolution.mdtext (added)
+++ sling/site/trunk/content/mappings-for-resource-resolution.mdtext Sun Apr 22 16:52:13 2012
@@ -0,0 +1,295 @@
+Title: Mappings for Resource Resolution
+<a name="MappingsforResourceResolution-MappingsforResourceResolution"></a>
+# Mappings for Resource Resolution
+<a name="MappingsforResourceResolution-Configuration"></a>
+## Configuration
+<a name="MappingsforResourceResolution-Properties"></a>
+### Properties
+The mapping of request URLs to resources is mainly configured in a
+configuration tree which is (by default) located below */etc/map*. The
+actual location can be configured with the
+** property of the
+When dealing with the new resource resolution we have a number of
+properties influencing the process:
+* *sling:match* -- This property when set on a node in the */etc/map* tree (see below) defines a partial regular expression which is used instead of the node's name to match the incoming request. This property is only needed if the regular expression includes characters which are not valid JCR name characters. The list of invalid characters for JCR names is: /, :, \[, \](,-\.html)
+, \*, ', ", \| and any whitespace except blank space. In addition a name
+without a name space may not be *.* or *..* and a blank space is only
+allowed inside the name.
+* *sling:redirect* -- This property when set on a node in the
+*/etc/map* tree (see below) causes a redirect response to be sent to the
+client, which causes the client to send in a new request with the modified
+location. The value of this property is applied to the actual request and
+sent back as the value of *Location* response header.
+* *sling:status* -- This property defines the HTTP status code sent to
+the client with the *sling:redirect* response. If this property is not
+set, it defaults to 302 (Found). Other status codes supported are 300
+(Multiple Choices), 301 (Moved Permanently), 303 (See Other), and 307
+(Temporary Redirect).
+* *sling:internalRedirect* -- This property when set on a node in the
+*/etc/map* tree (see below) causes the current path to be modified
+internally to continue with resource resolution.
+* *sling:alias* -- The property may be set on any resource to indicate an
+alias name for the resource. For example the resource */content/visitors*
+may have the *sling:alias* property set to *besucher* allowing the
+resource to be addressed in an URL as */content/besucher*.
+<a name="MappingsforResourceResolution-NodeTypes"></a>
+### Node Types
+To ease with the definition of redirects and aliases, the following node
+types are defined:
+* *sling:ResourceAlias* -- This mixin node type defines the
+*sling:alias* property and may be attached to any node, which does not
+otherwise allow setting a property named *sling:alias*
+* *sling:MappingSpec* -- This mixin node type defines the
+*sling:match*, *sling:redirect*, *sling:status*, and
+*sling:internaleRedirect* properties to define a matching and redirection
+inside the */etc/map* hierarchy.
+* *sling:Mapping* -- Primary node type which may be used to easily
+construct entries in the */etc/map* tree. The node type extends the
+*sling:MappingSpec* mixin node type to allow setting the required
+matching and redirection. In addition the *sling:Resource* mixin node
+type is extended to allow setting a resource type and the
+*nt:hierarchyNode* node type is extended to allow locating nodes of this
+node type below *nt:folder* nodes.
+Note, that these node types only help setting the properties. The
+implementation itself only cares for the properties and their values and
+not for any of these node types.
+<a name="MappingsforResourceResolution-NamespaceMangling"></a>
+## Namespace Mangling
+There are systems accessing Sling, which have a hard time handling URLs
+containing colons -- *:* -- in the path part correctly. Since URLs
+produced and supported by Sling may colons because JCR Item based resources
+may be namespaced (e.g. *jcr:content*), a special namespace mangling
+feature is built into the *ResourceResolver.resolve* and
+*ResourceResolver(map)* methods.
+Namespace mangling operates such, that any namespace prefix identified in
+resource path to be mapped as an URL in the *map* methods is modified
+such that the prefix is enclosed in underscores and the colon removed.
+_Example_: The path */content/_a_sample/jcr:content/jcr:data.png* is
+modified by namespace mangling in the *map* method to get at
+Conversely the *resolve* methods must undo such namespace mangling to get
+back at the resource path. This is simple done by modifying any path such
+that segments starting with an underscore enclosed prefix are changed by
+removing the underscores and adding a colon after the prefix. There is one
+catch, tough: Due to the way the SlingPostServlets automatically generates
+names, there may be cases where the actual name would be matching this
+mechanism. Therefore only prefixes are modified which are actually
+namespace prefixes.
+_Example_: The path */content/_a_sample/_jcr_content/_jcr_data.png{_*}
+_is modified by namespace mangling in the_ *{_}resolve{_*} _method to
+get_ *_/content/_a_sample/jcr:content/jcr:data.png{_}{*}_. The prefix_
+*_\_a{_}{*}*{*} is not modified because there is no registered
+namespace with prefix *a*. On the other hand the prefix *{_}jcr{_*} is
+modified because there is of course a registered namespace with prefix
+<a name="MappingsforResourceResolution-RootLevelMappings"></a>
+## Root Level Mappings
+Root Level Mappings apply to the request at large including the scheme,
+host.port and uri path. To accomplish this a path is constructed from the
+request as *\{scheme\}/\{host.port\}/\{uri_path\*}. This string is then
+matched against mapping entries below */etc/map* which are structured in
+the content analogously. The longest matching entry string is used and the
+replacement, that is the redirection property, is applied.
+<a name="MappingsforResourceResolution-MappingEntrySpecification"></a>
+### Mapping Entry Specification
+Each entry in the mapping table is a regular expression, which is
+constructed from the resource path below */etc/map*. If any resource
+along the path has a *sling:match* property, the respective value is used
+in the corresponding segment instead of the resource name. Only resources
+either having a *sling:redirect* or *sling:internalRedirect* property
+are used as table entries. Other resources in the tree are just used to
+build the mapping structure.
+Consider the following content
+    /etc/map
+          +-- http
+    	   +--
+    		+-- sling:redirect = ""
+    	   +--
+    		+-- sling:internalRedirect = "/example"
+    	   +--
+    		+-- sling:match = ".+\.example\.com\.80"
+    		+-- sling:redirect = ""
+    	   +-- localhost_any
+    		+-- sling:match = "localhost\.\d*"
+    		+-- sling:internalRedirect = "/content"
+    		+-- cgi-bin
+    		     +-- sling:internalRedirect = "/scripts"
+    		+-- gateway
+    		     +-- sling:internalRedirect = ""
+    		+-- (stories)
+    		     +-- sling:internalRedirect = "/anecdotes/$1"
+This would define the following mapping entries:
+<tr><th> Regular Expression </th><th> Redirect </th><th> Internal </th><th> Description </th></tr>
+<tr><td> http/ </td><td> [](
+ </td><td> no </td><td> Redirect all requests to the Second Level Domain to www </td></tr>
+<tr><td> http/ </td><td> /example </td><td> yes </td><td> Prefix the URI paths of the
+requests sent to this domain with the string */example* </td></tr>
+<tr><td> http/.+\.example\.com\.80 </td><td> [](
+ </td><td> no </td><td> Redirect all requests to sub domains to www. The actual regular
+expression for the host.port segment is taken from the *sling:match*
+property. </td></tr>
+<tr><td> http/localhost\.\d\* </td><td> /content </td><td> yes </td><td> Prefix the URI paths with
+*/content* for requests to localhost, regardless of actual port the
+request was received on. This entry only applies if the URI path does not
+start with */cgi-bin*, *gateway* or *stories* because there are
+longer match entries. The actual regular expression for the host.port
+segment is taken from the *sling:match* property. </td></tr>
+<tr><td> http/localhost\.\d*/cgi-bin </td><td> /scripts </td><td> yes </td><td> Replace the */cgi-bin*
+prefix in the URI path with */scripts* for requests to localhost,
+regardless of actual port the request was received on. </td></tr>
+<tr><td> http/localhost\.\d*/gateway </td><td> [](
+ </td><td> yes </td><td> Replace the */gateway* prefix in the URI path with
+*[]* for requests to localhost, regardless of actual port
+the request was received on. </td></tr>
+<tr><td> http/localhost\.\d*/(stories) </td><td> /anecdotes/stories </td><td> yes </td><td> Prepend the
+URI paths starting with */stories* with */anecdotes* for requests to
+localhost, regardless of actual port the request was received on. </td></tr>
+<a name="MappingsforResourceResolution-RegularExpressionmatching"></a>
+### Regular Expression matching
+As said above the mapping entries are regular expressions which are matched
+against path. As such these regular expressions may also contain capturing
+groups as shown in the example above: *http/localhost\.\d*/(stories)*.
+After matching the path against the regular expression, the replacement
+pattern is applied which allows references back to the capturing groups.
+To illustrate the matching and replacement is applied according to the
+following pseudo code:
+    String path = request.getScheme + "/" + request.getServerName() + "." +
+request.getServerPort() + "/" + request.getPathInfo();
+    String result = null;
+    for (MapEntry entry: mapEntries) {
+        Matcher matcher = entry.pattern.matcher(path);
+        if (matcher.find()) {
+    	StringBuffer buf = new StringBuffer();
+    	matcher.appendReplacement(buf, entry.getRedirect());
+    	matcher.appendTail(buf);
+    	result = buf.toString();
+    	break;
+        }
+    }
+At the end of the loop, *result* contains the mapped path or *null* if
+no entry matches the request *path*.
+*NOTE:* Since the entries in the */etc/map* are also used to reverse map
+any resource paths to URLs, using regular expressions in the Root Level
+Mappings prevent the respective entries from being used for reverse
+mappings. Therefor, it is strongly recommended to not use regular
+expression matching, unless you have a strong need.
+<a name="MappingsforResourceResolution-RedirectionValues"></a>
+### Redirection Values
+The result of matching the request path and getting the redirection is
+either a path into the resource tree or another URL. If the result is an
+URL, it is converted into a path again and matched against the mapping
+entries. This may be taking place repeatedly until an absolute or relative
+path into the resource tree results.
+The following pseudo code summarizes this behaviour:
+    String path = ....;
+    String result = path;
+    do {
+        result = applyMapEntries(result);
+    } while (isURL(result));
+As soon as the result of applying the map entries is an absolute or
+relative path (or no more map entries match), Root Level Mapping terminates
+and the next step in resource resolution, resource tree access, takes
+<a name="MappingsforResourceResolution-ResourceTreeAccess"></a>
+## Resource Tree Access
+The result of Root Level Mapping is an absolute or relative path to a
+resource. If the path is relative -- e.g. *myproject/docroot/sample.gif*
+-- the resource resolver search path (*ResourceResolver.getSearchPath()*
+is used to build absolute paths and resolve the resource. In this case the
+first resource found is used. If the result of Root Level Mapping is an
+absolute path, the path is used as is.
+Accessing the resource tree after applying the Root Level Mappings has four
+* Check whether the path addresses a so called Star Resource. A Star
+Resource is a resource whose path ends with or contains */\**. Such
+resources are used by the *SlingPostServlet* to create new content below
+an existing resource. If the path after Root Level Mapping is absolute, it
+is made absolute by prepending the first search path entry.
+* Check whether the path exists in the repository. if the path is absolute,
+it is tried directly. Otherwise the search path entries are prepended  to
+the path until a resource is found or the search path is exhausted without
+finding a resource.
+* Drill down the resource tree starting from the root, optionally using the
+search path until a resource is found.
+* If no resource can be resolved, a Missing Resource is returned.
+<a name="MappingsforResourceResolution-DrillingDowntheResourceTree"></a>
+### Drilling Down the Resource Tree
+Drilling down the resource tree starts at the root and for each segment in
+the path checks whether a child resource of the given name exists or not.
+If not, a child resource is looked up, which has a *sling:alias* property
+whose value matches the given name. If neither exists, the search is
+terminated and the resource cannot be resolved.
+The following pseudo code shows this algorithm assuming the path is
+    String path = ...; // the absolute path
+    Resource current = getResource("/");
+    String[]
+ segments = path.split("/");
+    for (String segment: segments) {
+        Resource child = getResource(current, segment);
+        if (child == null) {
+    	Iterator<Resource> children = listChildren(current);
+    	current = null;
+    	while (children.hasNext()) {
+    	    child =;
+    	    if (segment.equals(getSlingAlias(child))) {
+    		current = child;
+    		break;
+    	    }
+    	}
+    	if (current == null) {
+    	    // fail
+    	    break;
+    	}
+        } else {
+    	current = child;
+        }
+    }

Added: sling/site/trunk/content/maven-archetypes.mdtext
--- sling/site/trunk/content/maven-archetypes.mdtext (added)
+++ sling/site/trunk/content/maven-archetypes.mdtext Sun Apr 22 16:52:13 2012
@@ -0,0 +1,54 @@
+Title: Maven Archetypes
+Sling includes four Maven archetypes to quick start development. See [](
+ for general information on using Maven archetypes. The Maven groupId for
+all Sling archetypes is **.
+<a name="MavenArchetypes-sling-launchpad-standalone-archetype"></a>
+### sling-launchpad-standalone-archetype
+This archetype generates a Maven project which will build a standalone
+Launchpad JAR file using the default bundle set. For demonstration
+purposes, the generated project includes an extra bundle list file
+(*src/main/bundles/list*) which includes Apache Felix FileInstall as well
+as a test configuration file (*src/test/config/*).
+<a name="MavenArchetypes-sling-launchpad-webapp-archetype"></a>
+### sling-launchpad-webapp-archetype
+This archetype generates a Maven project which will build a Launchpad WAR
+file using the default bundle set. For demonstration purposes, the
+generated project includes an extra bundle list file
+(*src/main/bundles/list*) which includes Apache Felix FileInstall as well
+as a test configuration file (*src/test/config/*).
+<a name="MavenArchetypes-sling-intitial-content-archetype"></a>
+### sling-intitial-content-archetype
+This archetype generates a Maven project which will build an OSGi bundle
+that supports JCR NodeType registration (in
+*SLING-INF/nodetypes/nodetypes.cnd*) and initial content loading (in
+*SLING-INF/scripts* and *SLING-INF/content*).
+<a name="MavenArchetypes-sling-servlet-archetype"></a>
+### sling-servlet-archetype
+This archetype generates a Maven project which will build an OSGi bundle
+containing two Servlets registered with Sling, one registered by path and
+one registered by resource type.
+<a name="MavenArchetypes-sling-bundle-archetype"></a>
+### sling-bundle-archetype
+This archetype generates a Maven project which will build a basic OSGi
+bundle including support for the Felix SCR Annotations. It is
+pre-configured to install using the Felix Web Console when the profile
+*autoInstallBundle* is activated.
+<a name="MavenArchetypes-sling-jcrinstall-bundle-archetype"></a>
+### sling-jcrinstall-bundle-archetype
+This archetype generates a Maven project which will build a basic OSGi
+bundle including support for the Felix SCR Annotations. It is
+pre-configured to install using a WebDAV PUT into the JCR when the profile
+*autoInstallBundle* is activated.

Added: sling/site/trunk/content/maven-launchpad-plugin.mdtext
--- sling/site/trunk/content/maven-launchpad-plugin.mdtext (added)
+++ sling/site/trunk/content/maven-launchpad-plugin.mdtext Sun Apr 22 16:52:13 2012
@@ -0,0 +1,205 @@
+Title: Maven Launchpad Plugin
+<a name="MavenLaunchpadPlugin-MavenLaunchpadPlugin"></a>
+# Maven Launchpad Plugin
+The Maven Launchpad Plugin provides goals which facilitate the creation of
+OSGi applications. It supports the following runtime scenarios:
+* A WAR file suitable for running in a JavaEE servlet container.
+* A standalone Java application, with HTTP support from the Felix
+HttpService implementation
+* Inside Apache Karaf
+In addition, the Maven Launchpad Plugin supports the publishing of an
+application descriptor, in the form of a *bundle list*, as a Maven
+artifact. This descriptor can then be used by downstream application
+builders as the basis for other applications. In Sling, this is embodied by
+two Maven projects:
+* [](
+ - produces an application descriptor.
+* [](
+ - uses the application descriptor from ** and
+adds two bundles.
+Maven Launchpad Plugin provides the following goals: 
+<tr><th> Goals </th><th> Description </th></tr>
+<tr><td> launchpad:prepare-package </td><td> Create the file system structure required by
+Sling's Launchpad framework. </td></tr>
+<tr><td> launchpad:attach-bundle-list </td><td> Attach the bundle list descriptor to the
+current project as a Maven artifact. </td></tr>
+<tr><td> launchpad:create-karaf-descriptor </td><td> Create an Apache Karaf Feature
+descriptor. </td></tr>
+<tr><td> launchpad:create-bundle-jar </td><td> Create a JAR file containing the bundles in
+a Launchpad-structured JAR file. </td></tr>
+<tr><td> launchpad:check-bundle-list-for-snapshots </td><td> Validate that the bundle list
+does not contain any SNAPSHOT versions. </td></tr>
+<tr><td> launchpad:run </td><td> Run a Launchpad application. </td></tr>
+<tr><td> launchpad:start </td><td> Start a Launchpad application. </td></tr>
+<tr><td> launchpad:stop </td><td> Stop a Launchpad application. </td></tr>
+<tr><td> launchpad:output-bundle-list </td><td> Output the bundle list to the console as
+XML. (added in version 2.0.8) </td></tr>
+<a name="MavenLaunchpadPlugin-GeneralConfiguration"></a>
+### General Configuration
+In general, the bulk of the configuration of the Maven Launchpad Plugin is
+concerned with setting up the bundle list which all of the goals will use.
+This bundle list is created using the following steps:
+1. If *includeDefaultBundles* is *true* (the default), the default
+bundle list is loaded. By default, this is
+but can be overridden by setting the *defaultBundleList* plugin
+1. If *includeDefaultBundles* is *false*, an empty list is created.
+1. If the bundle list file exists (by default, at
+*src/main/bundles/list.xml*), the bundles defined in it are added to the
+bundle list.
+1. If the *additionalBundles* plugin parameter is defined, those bundles
+are added to the bundle list.
+1. If the *bundleExclusions* plugin parameter is defined, those bundles
+are removed from the bundle list.
+When a bundle is added to the bundle list, if a bundle with the same
+groupId, artifactId, type, and classifier is already in the bundle list,
+the version of the existing bundle is modified. However, the start level of
+a bundle is never changed once that bundle is added to the bundle list.
+The plugin may also contribute bundles to (or remove bundles from) the
+bundle list as it sees fit.
+<a name="MavenLaunchpadPlugin-FrameworkConfiguration"></a>
+### Framework Configuration
+For the *run* and *start* goals, the plugin will look for a file named
+*src/test/config/*. If this file is present, it will be
+filtered using standard Maven filtering and used to populate the OSGi
+framework properties. This can be used, for example, to specify a
+*repository.xml* file to be used during development:
+    sling.repository.config.file.url=${basedir}/src/test/config/repository.xml
+<a name="MavenLaunchpadPlugin-BundleListFiles"></a>
+## Bundle List Files
+The bundle list file uses a simple XML syntax representing a list of
+bundles organized into start levels:
+    <?xml version="1.0"?>
+    <bundles>
+        <startLevel level="0">
+    	<bundle>
+    	    <groupId>commons-io</groupId>
+    	    <artifactId>commons-io</artifactId>
+    	    <version>1.4</version>
+    	</bundle>
+    	<bundle>
+    	    <groupId>commons-collections</groupId>
+    	    <artifactId>commons-collections</artifactId>
+    	    <version>3.2.1</version>
+    	</bundle>
+        </startLevel>
+        <startLevel level="10">
+    	<bundle>
+    	    <groupId>org.apache.felix</groupId>
+    	    <artifactId>org.apache.felix.eventadmin</artifactId>
+    	    <version>1.0.0</version>
+    	</bundle>
+        </startLevel>
+        <startLevel level="15">
+    	<bundle>
+    	    <groupId></groupId>
+    	    <artifactId></artifactId>
+    	    <version>2.0.2-incubator</version>
+    	</bundle>
+        </startLevel>
+    </bundles>
+Within each *bundle* element, *type* and *classifier* are also
+<a name="MavenLaunchpadPlugin-ArtifactDefinition"></a>
+## Artifact Definition
+The *defaultBundleList*, *jarWebSupport*, *additionalBundles*, and
+*bundleExclusions* parameters are configured with artifact definitions.
+This is done using a syntax similar to Maven dependency elements:
+    <configuration>
+    ...
+      <jarWebSupport>
+        <groupId>GROUP_ID</groupId>
+        <artifactId>ARTIFACT_ID</artifactId>
+        <version>VERSION</version>
+        <!-- type and classifier can also be specified if needed -->
+      </jarWebSupport>
+    ...
+    </configuration>
+For example, to use Pax Web instead of Felix HttpService as the HttpService
+provider, use the following:
+    <configuration>
+    ...
+      <jarWebSupport>
+        <groupId>org.ops4j.pax.web</groupId>
+        <artifactId>pax-web-service</artifactId>
+        <version>RELEASE</version>
+        <!-- type and classifier can also be specified if needed -->
+      </jarWebSupport>
+    ...
+    </configuration>
+In the case of *additionalBundles* and *bundleExclusions*, these are
+arrays of definitions, so an intermediate *bundle* element is necessary:
+    <configuration>
+    ...
+      <additionalBundles>
+        <bundle>
+          <groupId>GROUP_ID</groupId>
+          <artifactId>ARTIFACT_ID</artifactId>
+          <version>VERSION</version>
+          <!-- type and classifier can also be specified if needed -->
+        </bundle>
+      </additionalBundles>
+    ...
+    </configuration>
+By default, bundles are added to start level 0. To change, this use the
+*startLevel* element within each additional bundle definition.
+<a name="MavenLaunchpadPlugin-IntegrationTesting"></a>
+## Integration Testing
+For integration testing examples, see */samples/inplace-integration-test*
+and *launchpad/testing* in the Sling source tree.
+<a name="MavenLaunchpadPlugin-BundleListRewriting"></a>
+## Bundle List Rewriting
+The Maven Launchpad Plugin supports the use of rules to rewrite the bundle
+list. These rules are executed by the [Drools](
+ rule engine. Typically, this is used along with Maven profiles. For
+example, Sling's testing project includes a profile called
+*test-reactor-sling-bundles*. When activated, this profile runs a Drools
+rule file which scans the project list from the Maven reactor and modifies
+the version number for bundles which were contained within the reactor.
+In order for rules to interact with the Maven build, the following global
+variables are made available:
+ * *mavenSession* - an instance of
+ * *mavenProject* - an instance of

Added: sling/site/trunk/content/maventipsandtricks.mdtext
--- sling/site/trunk/content/maventipsandtricks.mdtext (added)
+++ sling/site/trunk/content/maventipsandtricks.mdtext Sun Apr 22 16:52:13 2012
@@ -0,0 +1,82 @@
+Title: MavenTipsAndTricks
+Here's our collection of tips and tricks for building Sling with [Maven](
+<a name="MavenTipsAndTricks-Mavenlocalrepository"></a>
+# Maven local repository
+The first time you run a Maven build, or when Maven needs additional build
+components, it downloads plugins and dependencies under its _local
+repository_ folder on your computer. By default, this folder is named
+_.m2/repository_ in your home directory.
+Maven uses this repository as a cache for artifacts that it might need for
+future builds, which means that the first Sling build usually takes much
+longer than usual, as Maven needs to download many tools and dependencies
+into its local repository while the build progresses.
+The build might fail if one of those downloads fails, in that case it might
+be worth retrying the build, to check if that was just a temporary
+connection problem, or if there's a more serious error.
+In some cases, the local Maven repository might get corrupted - if your
+build fails on a computer and works on another one, clearing the local
+repository before restarting the build might be worth trying.
+<a name="MavenTipsAndTricks-Mavensettings"></a>
+# Maven settings
+<a name="MavenTipsAndTricks-Ignoreyourlocalsettings"></a>
+## Ignore your local settings
+To make sure you're getting the same results as we are when building Sling,
+it is recommend to ignore any local settings.
+On unixish platforms, using
+    mvn -s /dev/null ...
+does the trick.
+Does anyone have a similar command-line option that works under Windows?
+<a name="MavenTipsAndTricks-"></a>
+<a name="MavenTipsAndTricks-MAVEN_OPTS"></a>
+The MAVEN_OPTS environment variable defines options for the JVM that
+executes Maven.
+Set it according to your platform, i.e. *export MAVEN_OPTS=...* on
+unixish systems or *set MAVEN_OPTS=...* on Windows.
+<a name="MavenTipsAndTricks-IncreaseJVMmemoryifneeded"></a>
+## Increase JVM memory if needed
+If getting an OutOfMemoryException when running mvn, try setting
+    MAVEN_OPTS="-Xmx256M -XX:MaxPermSize=256m"
+to allocate 256MB of RAM to Maven.
+<a name="MavenTipsAndTricks-DebuggingcodelaunchedbyMaven"></a>
+## Debugging code launched by Maven
+To run the Sling launchpad webapp in debug mode from Maven, for example,
+use something like
+    MAVEN_OPTS="-agentlib:jdwp=transport=dt_socket,address=30303,server=y,suspend=n"
+And then connect to port 30303 with a remote JVM debugger (most IDEs do
+<a name="MavenTipsAndTricks-AvoidspacesinMavenrepositoryandworkspacepaths"></a>
+## Avoid spaces in Maven repository and workspace paths
+Some Maven plugins do not like spaces in paths. It is better to avoid
+putting your Maven repository, or your code, under paths like _Documents
+and Settings_, for example.

Added: sling/site/trunk/content/media.mdtext
--- sling/site/trunk/content/media.mdtext (added)
+++ sling/site/trunk/content/media.mdtext Sun Apr 22 16:52:13 2012
@@ -0,0 +1,10 @@
+Title: Media
+This page holds all media required for the Apache Sling website. The media
+are attachments and can be addressed using the following URL:
+ (followed by the actual name
+of the attachment).
+Currently, some of these attachments are used by the overall site template
+(only visible/editable by Confluence administrators).

Added: sling/site/trunk/content/monitoring-requests.mdtext
--- sling/site/trunk/content/monitoring-requests.mdtext (added)
+++ sling/site/trunk/content/monitoring-requests.mdtext Sun Apr 22 16:52:13 2012
@@ -0,0 +1,21 @@
+Title: Monitoring Requests
+<a name="MonitoringRequests-MonitoringRequests"></a>
+# Monitoring Requests
+Sling provides a simple OSGi console plugin to monitor recent requests.
+This is quite useful when debugging and to understand how things work,
+though it's obviously not a replacement for full-blown HTTP trafic
+monitoring tools.
+The console plugin is available at /system/console/requests, listed as
+_Recent Requests_ in the console menu.
+The plugin keeps track of the latest 20 requests processed by Sling, and
+displays the information provided by the RequestProgressTracker, for the
+selected request. The screenshot below shows an example.
+Any information that's added to the RequestProgressTracker (which is
+available from the SlingHttpServletRequest object) during request
+processing will be displayed by this plugin.
+!sling-requests-plugin.jpg|align=left, alt=Recent Requests plugin!

Added: sling/site/trunk/content/navigation.mdtext
--- sling/site/trunk/content/navigation.mdtext (added)
+++ sling/site/trunk/content/navigation.mdtext Sun Apr 22 16:52:13 2012
@@ -0,0 +1,56 @@
+Title: Navigation
+[Become a Sponsor](
+[Buy Stuff](
+  <iframe src=""
+style="border-width:0; float: left" frameborder="0" scrolling="no"
+width="135" height="135"></iframe>
+  <p style="height: 135px"></p>

Added: sling/site/trunk/content/news.mdtext
--- sling/site/trunk/content/news.mdtext (added)
+++ sling/site/trunk/content/news.mdtext Sun Apr 22 16:52:13 2012
@@ -0,0 +1,169 @@
+Title: News
+<a name="News-News"></a>
+# News
+* New Releases: Apache Sling Commons Testing 2.0.10, Apache Sling Commons
+Scheduler 2.3.4, Apache Sling Commons Log 3.0.0, Apache Sling Commons Log
+Service 1.0.0, Apache Sling Adapter 2.0.12, Apache Sling Installer Core
+3.3.4, Apache Sling Launchpad API 1.1.0, Apache Sling Launchpad Installer
+1.1.0, and Apache Sling Maven JSPC Plugin 2.0.6 (February 7th, 2012)
+* New Releases: Apache Sling API 2.2.4, Apache Sling Adapter 2.0.10, Apache
+Sling Scripting JSP Taglib 2.1.6, Apache Sling Rewriter 1.0.2, Apache Sling
+JCR ContentLoader 2.1.4, Apache Sling JCR Base 2.1.2, Apache Sling Servlet
+Resolver 2.1.2, and Apache Sling Security 1.0.0 (January 30th, 2012)
+* New Releases: Apache Sling Scripting API 2.1.4, Apache Sling Scripting
+Core 2.0.20, Apache Sling i18n 2.2.0, Apache Sling Installer Core 3.3.2,
+Apache Sling Scripting Java 2.0.2, and Apache Sling Scripting JSP 2.0.20
+(January 16th, 2012)
+* New Releases: Apache Adapter Annotations 1.0.0 and Apache Sling Maven
+Sling Plugin 2.1.0 (January 14th, 2012)
+* New Releases: Apache Sling Settings 1.1.0, Apache Sling Commons
+ClassLoader 1.2.4, Apache Sling Commons Scheduler 2.3.2, Apache Sling Event
+3.1.2, Apache Sling Installer Core 3.3.0, Apache Sling Installer
+Configuration Factory 1.0.4, Apache Sling Launchpad Installer 1.0.6, Apache
+Sling JCR Installer 3.1.2, and Apache Sling Thread Dumper 0.2.2 (January
+6th, 2012)
+* New Release: Apache Sling Jackrabbit User Manager 2.2.0 (November 15th,
+* New Release: Apache Sling Maven Sling Plugin 2.0.6 (October 21st, 2011)
+* New Release: Apache Sling Maven Launchpad Plugin 2.1.0 (September 9th,
+* New Releases: Apache Sling Resource Bundle 1.0.0 and Parent POM 12
+* New Releases: Apache Sling API 2.2.2, Apache Sling Commons Scheduler
+2.3.0, Apache Sling Commons OSGi 2.1.0, Apache Sling Scripting Core 2.0.18,
+Apache Sling Installer Core 3.2.2, Apache Sling Installer Configuration
+Factory 1.0.2, Apache Sling Launchpad Installer 1.0.4, Apache Sling File
+Installer 1.0.2 (August 16th, 2011)
+* New Release: Apache Sling Scripting JSP Support 2.0.18 (August 15th,
+* Released new Apache Sling Parent POM 11 (August 8, 2011)
+* New Release: Apache Sling Internationalization 2.1.2 (July 15, 2011)
+* New Releases: Apache Sling Event 3.1.0, Apache Sling OSGi Installer
+3.2.0, Apache Sling JCR Installer 3.1.0, Apache Sling Installer
+Configuration Factory 1.0.0, Apache Sling Launchpad Installer 1.0.2 (July
+13th, 2011)
+* New Release: Apache Sling Engine 2.2.4 (June 22nd, 2011)
+* New Releases: Apache Sling Launchpad Standalone Archetype 1.0.0,
+Launchpad Webapp Archetype 1.0.0 (May 13th, 2011)
+* New Releases: Apache Sling Scripting JSP Support 2.0.16, JSP Taglib 2.1.2
+(May 3rd, 2011)
+* New releases: Apache Sling Test Tools 1.0.2, JUnit Core 1.0.6, JUnit
+Remote Tests Runners 1.0.6, JUnit Scriptable Tests Provider 1.0.6, Sample
+Integration Tests 1.0.6, Sample Server-Side Tests 1.0.6, Failing
+Server-Side Tests 1.0.6 (April 26th, 2011)
+* New releases: Apache Sling I18N 2.1.0 (April 12, 2011)
+* New releases: [Apache Sling 6](
+, Apache Sling Launchpad Content 2.0.6 (March 28, 2011)
+* New releases: Apache Sling Launchpad Integration Tests 1.0.0, Apache
+Sling Launchpad Testing Services 2.0.8, Apache Sling Launchpad Testing
+Services WAR 2.0.8 (March 04, 2011)
+* New releases: Apache Sling Javascript 2.0.12 (February 26, 2011)
+* New releases: Apache Sling Explorer 1.0.2, Apache Sling JCR Resource
+2.0.10, Apache Sling Engine 2.2.2, Apache Sling Installer IT Testing 3.1.2
+(February 24, 2011)
+* New releases: Apache Sling Launchpad API 1.0.0, Launchpad Installer 1.0.0
+Launchpad Base 2.3.0, Maven Launchpad Plugin 2.0.10, Apache Sling Commons
+Testing 2.0.8 (February 20, 2011)
+* New release: Apache Sling Servlets Get 2.1.2 (February 18, 2011)
+* Carl Hall added as a committer (February 18, 2011)
+* New releases: Apache Sling Installer Core 3.1.2, Apache Sling JCR
+Installer 3.0.4, and Apache Sling Event 3.0.2 (February 4, 2011)
+* New release: Apache Sling Scripting Core 2.0.16 (January 29, 2011)
+* New releases: Apache Sling JCR Resource 2.0.8, Apache Sling Engine 2.2.0,
+Apache Sling Bundle Resource Provider 2.0.6, Apache Sling File Resource
+Provider 1.0.2, Apache Sling Auth Core 1.0.6, Apache Sling Auth Selector
+1.0.4 (January 28, 2011)
+* New releases: Apache Sling Commons Compiler 2.0.2, Apache Sling JCR
+Compiler 2.0.2, Apache Sling Commons Log 2.1.2, Apache Sling Event 3.0.0,
+Apache Sling Scripting JSP 2.0.14, Apache Sling Installer Core 3.1.0,
+Apache Sling JCR Installer 3.0.2 (January 21, 2011)
+* New release: Apache Sling Maven Launchpad Plugin 2.0.8 (December 20,
+* New releases: Apache Sling Commons Compiler 2.0.0, Apache Sling i18n
+2.0.4, Apache Sling Commons Json 2.0.6, Apache Sling Commons Log 2.1.0,
+Apache Sling Scripting Java 2.0.0, Apache Sling Scripting JST 2.0.4, Apache
+Sling Scripting API 2.1.2, Apache Sling Scripting JSP 2.0.12, Apache Sling
+Scripting Javascript 2.0.10, Apache Sling JCR Compiler 2.0.0, Apache Sling
+Auth Core 1.0.4, Apache Sling Auth Selector 1.0.2, Apache Sling Auth Form
+1.0.2, Apache Sling Auth OpenId 1.0.2, Apache Sling JCR ContentLoader 2.1.2
+(December 20, 2010)
+* New releases: Apache Sling API 2.20, Apache Sling Adapter 2.0.8, Apache
+Sling Commons ClassLoader 1.2.2, Apache Sling JCR ClassLoader 3.1.4, Apache
+Sling Parent POM 10 (December 13, 2010)
+* New release: Apache Sling JCR Web Console Plugin 1.0.0 (November 16,
+* New releases:  Apache Sling JCR Access Manager 2.1.0, JCR User Manager
+2.1.0, JCR WebDAV support 2.1.0, and JCR DavEX support 1.0.0 (November 8,
+* New release: Apache Sling Explorer 1.0.0 (November 1, 2010)
+* New release: Apache Sling Scripting Core 2.0.14 (October 25, 2010)
+* New releases: Apache Sling Commons Threads 3.1.0, Apache Sling Event
+2.4.2, Apache Sling I18N 2.0.2, Apache Sling Rewriter 1.0.0, and Apache
+Sling Settings 1.0.2 (October 15, 2010)
+* New releases: Apache Sling Installer Core 3.0.0, Apache Sling Installer
+File Provider 1.0.0, and Apache Sling Installer JCR Provider 3.0.0
+(September 24, 2010)
+* New release: Apache Sling Commons Testing 2.0.6 (September 20, 2010)
+* New releases: Apache Sling JCR API 2.1.0, Apache Sling JCR Base 2.1.0,
+Apache Sling JCR Content Loader 2.1.0, Apache Sling Jackrabbit Server 2.1.0
+(September 10, 2010)
+* New releases: Apache Sling Commons Threads 3.0.2, Apache Sling Event
+2.4.0 (September 06, 2010)
+* New releases: Apache Sling Commons ClassLoader 1.2.0, Apache Sling JCR
+ClassLoader 3.1.2 (August 30, 2010)
+* New release: Apache Sling Web Console Branding 1.0.0, Apache Sling Web
+Console Security Provider 1.0.0 (August 25, 2010)
+* New release: Apache Sling API 2.1.0 (August 21, 2010)
+* New release: Apache Sling GWT Integration 3.0.0 (July 30, 2010)
+* New releases: Apache Sling Commons OSGi 2.0.6, Launchpad Base 2.2.0 and
+Maven Launchpad Plugin 2.0.6 (April 27, 2010)
+* New releases: Apache Sling Event 2.3.0, Apache Sling Scripting Core
+2.1.0, Apache Commons MIME 2.1.4, and Apache Sling FileResource Provider
+1.0.0 (March 1, 2010)
+* Eric Norman added as a committer (February 17, 2010)
+* New release: Apache Sling Sample Path Based Resource Type Provider 2.0.4
+(February 22, 2010)
+* New releases: Apache Sling Event 2.2.0, Apache Sling Scripting API 2.1.0,
+and Apache Sling Thread Dumper 0.2.0 (Feburary 19, 2010)
+* New releases: Apache Sling JCR WebDav 2.0.8, Apache Sling JCR
+ContentLoader 2.0.6, Apache Sling JCR UserManager 2.0.4, Apache Sling JCR
+Server 2.0.6, Apache Sling JCR AccessManager 2.0.4, Apache Sling JCR Base
+2.0.6 (February 17, 2010)
+* New releases: Apache Sling Commons ClassLoader 1.1.4, and Apache Sling
+JCR ClassLoader 3.1.0 (February 8, 2010)
+* New release: Apache Sling JCR API 2.0.6 (January 29, 2010)
+* New releases: Apache Sling Commons ClassLoader 1.1.2, Apache Sling
+Commons Scheduler 2.2.0, Apache Sling Commons Threads 3.0.0, Apache Sling
+Event 2.1.0, and Apache Sling Servlets Get 2.0.8 (December 21, 2009)
+* Apache Sling MIME type mapping support, Version 2.1.2, is released
+(December 15, 2009)
+* Justin Edelson added as a committer (December 7, 2009)
+* New releases: Apache Sling Commons HTML 1.0.0, Apache Sling Commons
+Compiler 1.0.0, Apache Sling JCR Compiler 1.0.0, Apache Sling JCR Prefs
+1.0.0, and Apache Sling Scripting Java 1.0.0 (December 2, 2009)
+* New releases: Apache Sling Parent POM 8, Apache Sling Launchpad Base
+2.1.0, Apache Sling Commons ClassLoader 1.1.0, Apache Sling JCR ClassLoader
+3.0.0, Apache Sling Scripting Core 2.0.8, Apache Sling Scripting JSP 2.0.8,
+Apache Sling Scripting JSP Taglib 2.0.6, and Apache Sling Scripting
+JavaScript 2.0.6 (November 28, 2009)
+* New releases: Apache Sling Engine 2.0.6, Apache Sling Adapter 2.0.4,
+Apache Sling JCR Resource 2.0.6, Apache Sling Commons ClassLoader 1.0.0,
+Apache Sling Event 2.0.6, Apache Sling JCR ClassLoader 2.0.6, Apache Sling
+Scripting Core 2.0.6, Apache Sling Servlets Resolver 2.0.8 (October 13,
+* New releases: Apache Sling API 2.0.8, Apache Sling Commons HTML 0.9.0,
+Apache Sling Commons ClassLoader 0.9.0, Apache Sling Commons Scheduler
+2.1.0, and Apache Sling Servlets Get 2.0.6 (October 02, 2009)
+* New releases: Apache Sling API 2.0.6 and Apache Sling JCR API 2.0.4
+(August 17, 2009)
+* Apache Sling OSGi LogService Implementation, Version 2.0.6, is released
+(August 5, 2009)
+* Ian Boston added as a member of the PMC (July 25, 2009)
+* Ian Boston added as a committer (July 9, 2009)
+* Sling site at live (June 29, 2009)
+* Mailing lists moved to dev(a) and
+commits(a) (June 29, 2009)
+* SVN moved to (June 18, 2009)
+* Apache Sling has graduated into a top level project! (June 17, 2009)

Added: sling/site/trunk/content/old-stuff.mdtext
--- sling/site/trunk/content/old-stuff.mdtext (added)
+++ sling/site/trunk/content/old-stuff.mdtext Sun Apr 22 16:52:13 2012
@@ -0,0 +1,4 @@
+Title: Old Stuff
+Should either be deleted or reviewed and updated to match the current code:

Added: sling/site/trunk/content/openid-authenticationhandler.mdtext
--- sling/site/trunk/content/openid-authenticationhandler.mdtext (added)
+++ sling/site/trunk/content/openid-authenticationhandler.mdtext Sun Apr 22 16:52:13 2012
@@ -0,0 +1,298 @@
+Title: OpenID AuthenticationHandler
+<a name="OpenIDAuthenticationHandler-OpenIDAuthenticationHandler"></a>
+# OpenID AuthenticationHandler
+The OpenID Authentication Handler supports authentication of request users
+using the [OpenID](
+ authentication protocol. If the user has successfully authenticated with
+his OpenID provider a signed OpenID identity is further used to identify
+the user.
+Since generally an OpenID identity is an URL and URLs may not be used as
+JCR user names, an association mechanism is used by the OpenID
+authentication handler to associate an OpenID identity with an existing JCR
+user: The OpenID identity URL is set as the value of a JCR user property.
+When a user authenticates with his OpenID identity the matching user
+searched for by looking for a match in this property.
+_NOTE:_ This association currently only works with Jackrabbit (or
+Jackrabbit based repositories) because user management is not part of the
+JCR 2 specification and the OpenID authentication handler uses the
+Jackrabbit *UserManager* to find users by a user property value.
+The OpenID Authentication Handler is maintained in the [Sling SVN](
+<a name="OpenIDAuthenticationHandler-CredentialsExtraction"></a>
+### Credentials Extraction
+Theoretically each request with the *openid_identifier* request parameter
+set may initiate an OpenID authentication process which involves resolving
+the OpenID provider for the identifier and subsequently authentication with
+the provider authorizing the Sling instance to use the OpenID identity.
+This initiation, though, is not possible if the request already contains a
+valid and validated OpenID identifier either set as a request attribute or
+set in the HTTP Session or the OpenID cookie. In these situations, the
+current association of a client with an OpenID identity must first be
+removed by logging out, e.g. by requesting */system/sling/logout.html*
+which causes the current OpenID user data to be removed by either removing
+it from the HTTP Session or by clearing the OpenID cookie.
+<a name="OpenIDAuthenticationHandler-Phase1:FormSubmission"></a>
+### Phase 1: Form Submission
+Requesting an OpenID identifier is initiated by the Sling Authenticator
+deciding, that authentication is actually required to process a request and
+the OpenID Authentication Handler being selected to request credentials
+In this case the OpenID authenticator causes a form to be rendered by
+redirecting the client to the URL indicated by the *form.login.form*
+configuration parameter. This redirection request may accompanied by the
+following parameters:
+<tr><th> Request Parameter </th><th> Description </th></tr>
+<tr><td> *resource* </td><td> The location to which the user initially requested access
+and that caused the *requestCredentials* method to be called. This may
+not be set (or be set to an empty string). </td></tr>
+<tr><td> *j_reason* </td><td> The reason why an earlier attempt at authentication with
+the OpenID authentication handler failed. This request parameter is only
+set if the same named request attribute has been set by the
+*extractCredentials* or the *authenticationFailed* method. The value of
+the parameter is the name of one of the *OpenIDFailure* constants. </td></tr>
+<tr><td> *j_openid_identity* </td><td> The OpenID identity which could not successfully
+be associated with an existing JCR user. This request parameter is only set
+if the *authenticationFailed* method has been called due to inability to
+associate an existing and validated OpenID identity with an existing JCR
+user. </td></tr>
+The OpenID Authentication handlers supports the following request
+parameters submitted by the HTML form:
+* *openid_identifier* -- OpenID Claimed Identifier. This may be any
+actual OpenID identity URL or the URL of OpenID Provider such as
+,, or
+* *sling:authRequestLogin* -- This request parameter is recommended to be
+set with a hidden field to the value _OpenID_ to ensure the request is
+handled by the OpenID Authentication Handler.
+* *resource* -- The *resource* request parameter should be sent back to
+ensure the user is finally redirected to requested target resource after
+successful authentication. If this request parameter is not set, or is set
+to an empty string, it is assumed to be the request context root path.
+The OpenID Authentication Handler provides a default login form registered
+at */system/sling/openid/login*.
+<a name="OpenIDAuthenticationHandler-Configuration"></a>
+### Configuration
+The OpenID AuthenticationHandler is configured with configuration provided
+by the OSGi Configuration Admin Service using the
+** service PID.
+<tr><th> Parameter </th><th> Default </th><th> Description </th></tr>
+<tr><td> *path* </td><td> -- </td><td> Repository path for which this authentication handler
+should be used by Sling. If this is empty, the authentication handler will
+be disabled. </td></tr>
+<tr><td> *openid.login.form* </td><td> */system/sling/openid/login* </td><td> This should
+provide a way to capture the user's OpenID identifier.	This is not the
+OpenID Provider's login page, however, it does not have to be a local URL.
+If it is a local Sling URL, it must be accessible by the anonymous user.
+The user is HTTP Redirect'ed to this URL.  This page should POST back the
+user's OpenID identifier (as named by the "OpenID identifier form field"
+property) to the originally requested URL set in the "resource" request
+parameter. </td></tr>
+<tr><td> *openid.login.identifier* </td><td> *openid_identifier* </td><td> The name of the
+form parameter that provides the user's OpenID identifier. By convention
+this is *openid_identifier*. Only change this if you have a very good
+reason to do so. </td></tr>
+<tr><td> *openid.external.url.prefix* </td><td> -- </td><td> The prefix of URLs generated for
+the *ReturnTo* and *TrustRoot* properties of the OpenID request to the
+OpenID provider. Thus this URL prefix should bring back the authenticated
+user to this Sling instance. Configuring this property is usually necessary
+when running Sling behind a proxy (like Apache) since proxy mapping is not
+performed on the OpenID ReturnTo and TrustRoot URLs as they are sent to the
+OpenID Provider as form parameters.  If this property is empty, the URLs
+are generated using the hostname found in the original request.</td></tr>
+<tr><td> *openid.use.cookie* </td><td> *true* </td><td>  Whether to use a regular Cookie or an
+HTTP Session to cache the OpenID authentication details. By default a
+regular cookie is used to prevent use of HTTP Sessions. </td></tr>
+<tr><td> *openid.cookie.domain* </td><td> -- </td><td> Domain of cookie used to persist
+authentication. This defaults to the host name of the Sling server but may
+be set to a different value to share the cookie amongst a server farm or if
+the server is running behind a proxy. Only used if 'Use Cookie' is checked.
+<tr><td> ** </td><td> *sling.openid* </td><td> Name of cookie used to
+persist authentication. Only used if 'Use Cookie' is checked. </td></tr>
+<tr><td> *openid.cookie.secret.key* </td><td> *secret* </td><td> Secret key used to create a
+signature of the cookie value to prevent tampering. Only used if 'Use
+Cookie' is true. </td></tr>
+<tr><td> *openid.user.attr* </td><td> *openid.user* </td><td> Name of the JCR
+SimpleCredentials attribute to to set with the OpenID User data. This
+attribute is used by the OpenID LoginModule to validate the OpenID user
+authentication data. </td></tr>
+<tr><td> ** </td><td> *openid.identity* </td><td>	The name of the JCR
+User attribute listing one or more OpenID Identity URLs with which a user
+is associated. The property may be a multi- or single-valued. To resolve a
+JCR user ID from an OpenID identity a user is searched who lists the
+identity in this property. </td></tr>
+<a name="OpenIDAuthenticationHandler-AuthenticationHandlerimplementation"></a>
+### AuthenticationHandler implementation
+<a name="OpenIDAuthenticationHandler-extractCredentials"></a>
+#### extractCredentials
+To extract authentication information from the request, the Sling OpenID
+Authentication handler considers the following information in order:
+1. The OpenID credentials cookie or OpenID User data in the HTTP Session
+(depending on the *openid.use.cookie* configuration)
+1. Otherwise the *openid_identifier* request parameter (or a different
+request parameter depending on the *openid.login.identifier*
+If the OpenID credentials already exist in the request, they are validated
+and returned if valid
+If the existing credentials fail to validate, authentication failure is
+assumed and the credentials are removed from the request, either by
+clearing the OpenID cookie or by removing the OpenID User data from the
+HTTP Session.
+If no OpenID credentials are found in the request, the request parameter is
+considered and if set is used to resolve the actual OpenID identity of the
+user. This involves redirecting the client to the OpenID provider resolved
+from the OpenID identifier supplied.
+If the supplied OpenID identifier fails to resolve to an OpenID provider or
+if the identifier fails to be resolved to a validated OpenID identity,
+authentication fails.
+<a name="OpenIDAuthenticationHandler-requestCredentials"></a>
+#### requestCredentials
+If the *sling:authRequestLogin* parameter is set to a value other than
+*OpenID* this method immediately returns *false*.
+If the parameter is not set or is set to *OpenID* this method continues
+with first invalidating any cached OpenID credentials (same as
+*dropCredentials* does) and then redirecting the client to the login form
+configured with the *openid.login.form* configuration property. The
+redirect is provided with up to three request parameters:
+<tr><th> Request Parameter </th><th> Description </th></tr>
+<tr><td> *resource* </td><td> The location to which the user initially requested access
+and that caused the *requestCredentials* method to be called. </td></tr>
+<tr><td> *j_reason* </td><td> The reason why an earlier attempt at authentication with
+the OpenID authentication handler failed. This request parameter is only
+set if the same named request attribute has been set by the
+*extractCredentials* or the *authenticationFailed* method. The value of
+the parameter is the name of one of the *OpenIDFailure* constants. </td></tr>
+<tr><td> *j_openid_identity* </td><td> The OpenID identity which could not successfully
+be associated with an existing JCR user. This request parameter is only set
+if the *authenticationFailed* method has been called due to inability to
+associate an existing and validated OpenID identity with an existing JCR
+user. </td></tr>
+<a name="OpenIDAuthenticationHandler-dropCredentials"></a>
+#### dropCredentials
+Invalidates the OpenID identity currently stored with the request. This
+means to either remove the OpenID cookie or to remove the OpenID
+information from the HTTP Session. This method does not write to the
+response (except setting the *Set-Cookie* header to remove the OpenID
+cookie if required) and does not commit the response.
+<a name="OpenIDAuthenticationHandler-AuthenticationFeedbackHandlerimplementation"></a>
+### AuthenticationFeedbackHandler implementation
+<a name="OpenIDAuthenticationHandler-authenticationFailed"></a>
+#### authenticationFailed
+This method is called, if the Credentials provided by the Authentication
+Handler could not be validated by the Jackrabbit authentication
+infrastructure. One cause may be that the integration with Jackrabbit has
+not been completed (see _Integration with Jackrabbit_ below). Another, more
+probably cause, is that the validated OpenID identifier cannot be
+associated with an existing JCR user.
+The OpenID Authentication Handler implementation of the
+*authenticationFailed* method sets the *j_reason* request attribute to
+*OpenIDFailure.REPOSITORY* and sets the *j_openid_identity* request
+attribute to the OpenID identity of the authenticated user.
+A login form provider may wish to act upon this situation and provide a
+login form to the user to allow to his OpenID identity with an existing JCR
+In addition, the current OpenID identity is invalidated thus the cached
+OpenID information is removed from the HTTP Session or the OpenID cookie is
+cleaned. This will allow the user to present a different OpenID identifier
+to retry or it will require the OpenID identity to be revalidated with the
+OpenID provider if the identity is associated with a JCR user.
+<a name="OpenIDAuthenticationHandler-authenticationSucceeded"></a>
+#### authenticationSucceeded
+The OpenID Authentication Handler implementation of the
+*authenticationSucceeded* method just calls the
+*DefaultAuthenticationFeedbackHandler.handleRedirect* method to redirect
+the user to the initially requested location.
+<a name="OpenIDAuthenticationHandler-IntegrationwithJackrabbit"></a>
+### Integration with Jackrabbit
+The OpenID authentication handler can be integrated in two ways into the
+Jackrabbit authentication mechanism which is based on JAAS *LoginModule*.
+One integration is by means of a *LoginModulePlugin* which plugs into the
+extensible *LoginModule* architecture supported by the Sling Jackrabbit
+Embedded Repository bundle.
+The other integration option is the *trusted_credentials_attribute*
+mechanism supported by the Jackrabbit *DefaultLoginModule*. By setting
+the *trusted_credentials_attribute* parameter of the Jackrabbit
+*DefaultLoginModule* and the *openid.user.attr* configuration property
+of the OpenID Authentication Handler to the same value, the existence of an
+attribute of that name in the *SimpleCredentials* instance provided to
+the *Repository.login* method signals pre-authenticated credentials,
+which need not be further checked by the *DefaultLoginModule*.
+<a name="OpenIDAuthenticationHandler-SecurityConsiderations"></a>
+### Security Considerations
+OpenIDAuthentication has some limitations in terms of security:
+1. User name and password are transmitted in plain text in the initial form
+1. The Cookie used to provide the authentication state or the HTTP Session
+ID may be stolen.
+1. When using the *trusted_credentials_attribute* mechanism, any intruder
+knowing the attribute name may log into the repository as any existing JCR
+user. The better option is to be based on the *LoginModulePlugin*
+To prevent eavesdroppers from sniffing the credentials or stealing the
+Cookie a secure transport layer should be used such as TLS/SSL, VPN or

Added: sling/site/trunk/content/osgi-installer.mdtext
--- sling/site/trunk/content/osgi-installer.mdtext (added)
+++ sling/site/trunk/content/osgi-installer.mdtext Sun Apr 22 16:52:13 2012
@@ -0,0 +1,103 @@
+Title: OSGi Installer
+<a name="OSGiInstaller-Overview"></a>
+# Overview
+The OSGi installer is a central service for handling installs, updates and
+uninstall of "artifacts". By default, the installer supports bundles and
+has an extension for handling configurations for the OSGi configuration
+The OSGi installer itself is "just" the central service managing the tasks
+and states of the artifacts. The artifacts can be provided through various
+providers, e.g. through a file system provider reading artifacts from
+configured directories or the jcr provider reading artifacts from a JCR
+A provider is just scanning for artifacts and their removal. It informs the
+OSGi installer about new artifacts and removed artifacts. The provider
+itself has usually no knowledge about the contents of an artifact. It does
+not know about bundles, configurations etc.
+As the OSGi installer itself is not performing the actual install, update
+or removal of an artifact, its possible to install transformers and
+installer factories. A transformer inspects the artifacts and tries to
+detect its type. By default, detecting of bundles and configurations is
+supported. The final service is an installer factory creating the actual
+task, like install this bundle, update that bundle etc.
+It's possible to add own providers, transformers and installer factories to
+support custom scenarios.
+<a name="OSGiInstaller-ArtifactHandling"></a>
+## Artifact Handling
+Once an artifact is detected by a transformer, it gets a unique id. By
+default a bundle gets the symbolic name as the unique identifier and a
+configuration the PID.
+In addition to this id, an artifact gets a priority information from the
+provider. The priority is used if an artifact with the same id is provided
+several times from different locations. For example if a file system
+provider is scanning two directories and an artifact with the same id (like
+a configuration) is added to both directories, one should have precedence
+over the other. This is handled by the priority.
+Artifacts with the same unique id are grouped and then sorted by priority
+and maybe other artifact dependent metadata like the bundle version. Only
+the first artifact in this sorted group is tried to be applied!
+<a name="OSGiInstaller-BundleHandling"></a>
+## Bundle Handling
+In general, the OSGi installer always tries to install the highest version
+of a bundle if several bundles with the same symbolic name are provided. In
+this case higher version wins over priority.
+If an installed bundle is removed by a provider, for example deleted in the
+repository, the OSGi installer uninstall the bundle.
+If a bundle is removed from a provider which is currently not installed,
+this has no effect at all.
+If an installed bundle is removed and another version of this bundle is
+provided (a lower version), than this one is installed instead. This is
+basically a downgrade of the bundle.
+If a bundle is installed and a higher version is provided, an upgrade is
+If an installed bundle is managed via any other OSGi tooling, like
+uninstalling it through the web console, the OSGi installer does no action
+at all!
+If a failure occurs during bundle installation or update, the OSGi
+installer will retry this as soon as another bundle has been installed. The
+common use case is an application installation with several bundles where
+one bundle depends on another. As they are installed in arbitrary order,
+this mechanism ensures that in the end all bundles are properly wired and
+When all artifacts have been processed (either install, update or delete),
+a package refresh is automatically called.
+<a name="OSGiInstaller-VersionsandSnapshots"></a>
+### Versions and Snapshots
+The OSGi installer asumes that a symbolic name and version (not a snapshot
+version) uniquely identifies a bundle. Obviously this is a common
+development requirement that a released version of an artifact never
+changes over time. Therefore, once a bundle with a specific version is
+installed, it will not be reinstalled if the corresponding artifact
+changes. For example, if  bundle A with version 1.0 is put into the JCR
+repository, it gets installed. If now this jar in the repository is
+overwritten either with the same contents or with a different one, and this
+new artifact has again A as the symbolic name and version set to 1.0,
+nothing will happen as this exact bundle is already installed.
+During development, SNAPSHOT versions should be used, like 1.0.0-SNAPSHOT
+(using the Maven convention). If a bundle with a snapshot version is
+changed, it gets updated by the OSGI installer.
+<a name="OSGiInstaller-ConfigurationHandling"></a>
+## Configuration Handling
+In general the OSGi installer installs the configuration with the highes
+priority. For example in combination with the JCR installer provider, a
+configuration from _/apps_ is preferred over a configuration for the same
+service from _/libs_.

Added: sling/site/trunk/content/plugins.mdtext
--- sling/site/trunk/content/plugins.mdtext (added)
+++ sling/site/trunk/content/plugins.mdtext Sun Apr 22 16:52:13 2012
@@ -0,0 +1,4 @@
+Title: Plugins
+These pages present the various Maven Plugins of Sling:

Added: sling/site/trunk/content/project-information.mdtext
--- sling/site/trunk/content/project-information.mdtext (added)
+++ sling/site/trunk/content/project-information.mdtext Sun Apr 22 16:52:13 2012
@@ -0,0 +1,141 @@
+Title: Project Information
+<a name="ProjectInformation-Slingprojectinformation"></a>
+# Sling project information
+This document provides an overview of the various documents and links that
+are part of this project's general information:
+* [Community Roles and Processes](apache-sling-community-roles-and-processes.html)
+* [Project Team](project-team.html)
+* [Mailing Lists](#lists.html)
+* [Issue Tracking](#issues.html)
+* [Source Repository](#source.html)
+* [Continuous Integration](#ci.html)
+* [Project License](project-license.html)
+<a name="ProjectInformation-MailingLists"></a>
+## Mailing Lists
+These are the mailing lists that have been established for this project.
+For each list, there is a subscribe, unsubscribe, and an archive link.
+<tr><th> Name </th><th> Subscribe </th><th> Unsubscribe </th><th> Post </th><th> Archive </th><th> Other Archives </th></tr>
+<tr><td> Sling Users List </td><td> [Subscribe](
+ </td><td> [Unsubscribe</td><td>]
+ </td><td> users at </td><td> [</td><td>]
+ </td><td> [</td><td>]
+ [MarkMail</td><td>]
+ [Nabble</td><td>]
+ </td></tr>
+<tr><td> Sling Developers List </td><td> [Subscribe](
+ </td><td> [Unsubscribe</td><td>]
+ </td><td> dev at </td><td> [</td><td>]
+ </td><td> [</td><td>]
+ [MarkMail</td><td>]
+ [Nabble</td><td>]
+ </td></tr>
+<tr><td> Sling Source Control List </td><td> [Subscribe](
+ </td><td> [Unsubscribe</td><td>]
+ </td><td> </td><td> [</td><td>]
+ </td><td> [</td><td>]
+ [MarkMail</td><td>]
+ </td></tr>
+<a name="ProjectInformation-IssueTracking"></a>
+## Issue Tracking
+This project uses JIRA a J2EE-based, issue tracking and project management
+application. Issues, bugs, and feature requests should be submitted to the
+following issue tracking system for this project.
+The issue tracker can be found at [](
+<a name="ProjectInformation-SourceRepository"></a>
+## Source Repository
+This project uses Subversion to manage its source code. Instructions on
+Subversion use can be found at [](
+<a name="ProjectInformation-WebAccess"></a>
+### Web Access
+The following is a link to the online source repository.
+<a name="ProjectInformation-Anonymousaccess"></a>
+### Anonymous access
+The source can be checked out anonymously from SVN with this command:
+    $ svn checkout sling
+<a name="ProjectInformation-Developeraccess"></a>
+### Developer access
+Everyone can access the Subversion repository via HTTPS, but Committers
+must checkout the Subversion repository via HTTPS.
+    $ svn checkout sling
+To commit changes to the repository, execute the following command to
+commit your changes (svn will prompt you for your password)
+    $ svn commit --username your-username -m "A message"
+<a name="ProjectInformation-Accessfrombehindafirewall"></a>
+### Access from behind a firewall
+For those users who are stuck behind a corporate firewall which is blocking
+http access to the Subversion repository, you can try to access it via the
+developer connection:
+    $ svn checkout sling
+<a name="ProjectInformation-Accessthroughaproxy"></a>
+### Access through a proxy
+The Subversion client can go through a proxy, if you configure it to do so.
+First, edit your "servers" configuration file to indicate which proxy to
+use. The files location depends on your operating system. On Linux or Unix
+it is located in the directory "~/.subversion". On Windows it is in
+"%APPDATA%\Subversion". (Try "echo %APPDATA%", note this is a hidden
+There are comments in the file explaining what to do. If you don't have
+that file, get the latest Subversion client and run any command; this will
+cause the configuration directory and template files to be created.
+Example : Edit the 'servers' file and add something like :
+    [global]
+    http-proxy-host =
+    http-proxy-port = 3128
+<a name="ProjectInformation-ContinuousIntegration"></a>
+## Continuous Integration
+Sling builds run automatically on the ASF's [Jenkins build server](
+, triggered by SVN changes and daily.
+See [SLING-920](
+ for Hudson configuration information.

View raw message