You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@sling.apache.org by bd...@apache.org on 2017/06/19 12:41:24 UTC
[18/53] sling-site git commit: asf-site branch created for published
content
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/development/jsr-305.md
----------------------------------------------------------------------
diff --git a/content/documentation/development/jsr-305.md b/content/documentation/development/jsr-305.md
deleted file mode 100644
index 8080d91..0000000
--- a/content/documentation/development/jsr-305.md
+++ /dev/null
@@ -1,115 +0,0 @@
-title=Leveraging JSR-305 null annotations to prevent NullPointerExceptions
-type=page
-status=published
-~~~~~~
-
-[TOC]
-
-# Introduction
-The Sling API forces developers to sometimes check for `null` return values. Most prominently this is the case for [`Adaptable.adaptTo`](https://sling.apache.org/apidocs/sling8/org/apache/sling/api/adapter/Adaptable.html#adaptTo-java.lang.Class-) and [`ResourceResolver.getResource`](https://sling.apache.org/apidocs/sling8/org/apache/sling/api/resource/ResourceResolver.html#getResource-java.lang.String-). This is often forgotten, which may lead to `NullPointerException`s. Sling API 2.9.0 introduced the JSR-305 annotations ([SLING-4377](https://issues.apache.org/jira/browse/SLING-4377)) which allow tools to check automatically for missing null checks in the code.
-
-# Annotations
-The annotations used within Sling are based on the [JSR-305](https://jcp.org/en/jsr/detail?id=305) which is dormant since 2012. Nevertheless those annotations are understood by most of the tools and used by other Apache Projects like Apache Oak [OAK-37](https://issues.apache.org/jira/browse/OAK-37).
-
-Due to the fact that Eclipse and FindBugs are interpreting annotations differently ([Findbugs-1355](https://sourceforge.net/p/findbugs/bugs/1355/)). Sling only uses the following two different annotations which are supported by both tools:
-
-1. `javax.annotation.CheckForNull`
-1. `javax.annotation.Nonnull`
-
-Annotations which support setting the default null semantics of return values and or parameters on a package level cannot be leveraged for that reason.
-
-The annotations have a retention policy of `runtime`, therefore bundles using these automatically have a `Import-Package` header listing `javax.annotation`. That package is by default exported by the system bundle (as this package is also part of the [JRE](https://docs.oracle.com/javase/7/docs/api/javax/annotation/package-summary.html)). To be able to resolve the bundle through this exported package from the system bundle you should use the `com.google.code.findbugs:jsr305` artifact in version 3.0.0 as that exports the package `javax.annotation` in no specific version. Newer versions use version directives which automatically restrict the version range for the generated `Import-Package` header to `[3,4)` [which usually cannot be resolved at run time](https://github.com/amaembo/jsr-305/issues/31).
-
-# Use With Eclipse
-Eclipse since Juno supports [null analysis based on any annotations](http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fpreferences%2Fjava%2Fcompiler%2Fref-preferences-errors-warnings.htm&anchor=null_analysis). Those need to be enabled in
-*Preferences->Java->Compiler->Errors/Warnings* via **Enable annoation-based null analysis**.
-Also the annotations need to be configured. For Sling/JSR 305 those are
-
-* `javax.annotation.CheckForNull` as **'Nullable' annotation** (primary annotation)
-* `javax.annotation.Nonnull` as **'NonNull' annotation** (primary annotation)
-
-
-
-Unfortunately Eclipse cannot infer information about fields which are for sure either null or not null (reasoning is available in [https://wiki.eclipse.org/JDT_Core/Null_Analysis/Options#Risks_of_flow_analysis_for_fields](https://wiki.eclipse.org/JDT_Core/Null_Analysis/Options#Risks_of_flow_analysis_for_fields) and [Eclipse Bug 247564](https://bugs.eclipse.org/bugs/show_bug.cgi?id=247564)). This also affecs constants (static final fields) or enums which are known to be non null, but still Eclipse will emit a warning like *The expression of type 'String' needs unchecked conversion to conform to '@Nonnull String'*. The only known workaround is to disable the **"Unchecked conversion from non-annotated type to @NonNull type"** or to annotate also the field with `@Nonnull`.
-
-More information are available at [https://wiki.eclipse.org/JDT_Core/Null_Analysis](https://wiki.eclipse.org/JDT_Core/Null_Analysis).
-
-Since Eclipse 4.5 (Mars) **external annotations** are supported as well (i.e. annotations maintained outside of the source code of the libraries, e.g. for the JRE, Apache Commons Lang). There are some external annotations being mainted at [lastnpe.org](http://www.lastnpe.org/) and [TraceCompass](https://github.com/tracecompass/tracecompass/tree/master/common/org.eclipse.tracecompass.common.core/annotations). There is no official repository yet though ([Eclipse Bug 449653](https://bugs.eclipse.org/bugs/show_bug.cgi?id=449653)).
-[Lastnpe.org](http://www.lastnpe.org/) provides also an m2e extension to ease setting up the classpaths with external annotations from within your pom.xml.
-
-# Use With Maven
-
-## Leveraging Eclipse JDT Compiler (recommended)
-
-You can use Eclipse JDT also in Maven (with null analysis enabled) for the regular compilation. That way it will give out the same warnings/errors as Eclipse and will also consider external annotations.
-JDT in its most recent version is provided by the `tycho-compiler-plugin` which can be hooked up with the `maven-compiler-plugin`.
-The full list of options for JDT is described in [here](http://help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-using_batch_compiler.htm).
-This method was presented by Michael Vorburger in his presentation [The end of the world as we know it](https://www.slideshare.net/mikervorburger/the-end-of-the-world-as-we-know-it-aka-your-last-nullpointerexception-1b-bugs/14).
-
-::xml
-<plugin>
-<artifactId>maven-compiler-plugin</artifactId>
-<version>3.5.1</version>
-<configuration>
-<source>1.8</source>
-<target>1.8</target>
-<showWarnings>true</showWarnings>
-<compilerId>jdt</compilerId>
-<compilerArguments>
-<!-- just take the full Maven classpath as external annotations -->
-<annotationpath>CLASSPATH</annotationpath>
-</compilerArguments>
-<!-- maintain the org.eclipse.jdt.core.prefs properties to options listed on
-http://help.eclipse.org/neon/index.jsp?topic=/org.eclipse.jdt.doc.user/tasks/task-using_batch_compiler.htm -->
-<compilerArgument>-err:nullAnnot,null,-missingNullDefault</compilerArgument>
-</configuration>
-<dependencies>
-<dependency>
-<groupId>org.eclipse.tycho</groupId>
-<artifactId>tycho-compiler-jdt</artifactId>
-<version>1.0.0</version>
-</dependency>
-</dependencies>
-</plugin>
-
-## Leveraging FindBugs
-You can also let Maven automatically run FindBugs to execute those checks via the **findbugs-maven-plugin**. For that just add the following plugin to your `pom.xml`
-
-::xml
-<plugin>
-<groupId>org.codehaus.mojo</groupId>
-<artifactId>findbugs-maven-plugin</artifactId>
-<version>3.0.0</version>
-<configuration>
-<visitors>InconsistentAnnotations,NoteUnconditionalParamDerefs,FindNullDeref,FindNullDerefsInvolvingNonShortCircuitEvaluation</visitors>
-</configuration>
-<executions>
-<execution>
-<id>run-findbugs-fornullchecks</id>
-<goals>
-<goal>check</goal>
-</goals>
-</execution>
-</executions>
-</plugin>
-
-
-The results are often very imprecise ([MFINDBUGS-208](http://jira.codehaus.org/browse/MFINDBUGS-208)), especially when it comes to line numbers, therefore it is best to start the Findbugs GUI in case of errors found by this plugin via `mvn findbugs:gui`.
-
-
-# Use With FindBugs
-FindBugs evaluates the JSR-305 annotations by default. You can restrict the rules to only the ones which check for those annotations, which are
-
-* InconsistentAnnotations
-* NoteUnconditionalParamDerefs
-* FindNullDeref
-* FindNullDerefsInvolvingNonShortCircuitEvaluation
-
-A complete list of visitors class names in Findbugs can be found in the [sourcecode](https://code.google.com/p/findbugs/source/browse/#git%2Ffindbugs%2Fsrc%2Fjava%2Fedu%2Fumd%2Fcs%2Ffindbugs%2Fdetect%253Fstate%253Dclosed). The according [bug patterns](http://findbugs.sourceforge.net/bugDescriptions.html) have an identifier (in parenthesis) for which you can search in the according Java classes, in case you want to extend the checks.
-
-Findbugs is also integrated in [SonarQube](http://docs.sonarqube.org/display/SONAR/Findbugs+Plugin) but for SonarQube you should now rather use the native Java plugin
-(look at [Use with SonarQube](#use-with-sonarqube)).
-
-# Use with SonarQube
-
-At least rule [squid:S2259](https://sonarqube.com/coding_rules#rule_key=squid%3AS2259) in SonarQube supports JSR-305 annotations as well for null checks.
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/development/logging.md
----------------------------------------------------------------------
diff --git a/content/documentation/development/logging.md b/content/documentation/development/logging.md
deleted file mode 100644
index 53bcd91..0000000
--- a/content/documentation/development/logging.md
+++ /dev/null
@@ -1,566 +0,0 @@
-title=Logging
-type=page
-status=published
-~~~~~~
-
-<div class="note">
-This document is for the new (November 2013) 4.x release of the Sling Commons Log components. Refer to
-<a href="http://sling.apache.org/documentation/legacy/logging.html">Logging 3.x</a> for older versions.
-</div>
-
-[TOC]
-
-## Introduction
-
-Logging in Sling is supported by the `org.apache.sling.commons.log` bundle, which is one of the first bundles installed
-and started by the Sling Launcher. This bundle along with other bundles manages the Sling Logging and provides the
-following features:
-
-* 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)](http://www.slf4j.org)
-* [Apache Commons Logging](http://jakarta.apache.org/commons/logging)
-* [log4j](http://logging.apache.org/log4j/index.html)
-* [java.util.logging](http://download.oracle.com/javase/6/docs/api/java/util/logging/package-summary.html)
-* Configures logging through Logback which is integrated with the OSGi environment
-* Allows logging to be configured both via editing Logback xml or via OSGi Configurations
-
-### v5.0.0 release
-
-With Sling Log 5.0.0. release the webconsole support has been moved to a
-different bundle named Sling Commons Log WebConsole (org.apache.sling.commons.log.webconsole:1.0.0)
-
-Also with this release Logback 1.1.7 version is embedded and thus it requires
-slf4j-api:1.7.15. See [SLING-6144][SLING-6144] for details
-
-## WebConsole Plugin
-
-The Web Console Plugin supports the following features:
-
-* Display the list of loggers which have levels or appenders configured.
-* List the file appenders with the location of current active log files.
-* Show the contents of LogBack config files.
-* Show the contents of various Logback config fragments.
-* Show Logback Status logs.
-* Inline edit the Logger setting
-* Configure Logger with content assist for logger names
-* Provides links to log file content allows log file content to be viewed from Web UI
-
-<img src="sling-log-support.png" />
-
-## WebTail
-
-The Web Console Plugin also supports tailing of the current active log files.
-It generates link to all active log files which can be used to see there content
-from within the browser. The url used is like
-
-```
-http://localhost:8080/system/console/slinglog/tailer.txt?tail=1000&grep=lucene&name=%2Flogs%2Ferror.log
-```
-
-It supports following parameters
-
-* `name` - Appender name like _/logs/error.log_
-* `tail` - Number of lines to include in dump. -1 to include whole file
-* `grep` - Filter the log lines based on `grep` value which can be
-* Simple string phrase - In this case search is done in case insensitive way via String.contains
-* regex - In this case the search would be done via regex pattern matching
-
-## Initial Configuration
-
-The `org.apache.sling.commons.log` bundle gets its initial configuration from the following `BundleContext` properties:
-
-
-| Property | Default | Description |
-|--|--|--|
-| `org.apache.sling.commons.log.level` | `INFO` | Sets the initial logging level of the root logger. This may be any of the defined logging levels `DEBUG`, `INFO`, `WARN`, `ERROR` and `FATAL`. |
-| `org.apache.sling.commons.log.file` | undefined | Sets the log file to which log messages are written. If this property is empty or missing, log messages are written to `System.out`. |
-| `org.apache.sling.commons.log.file.number` | 5 | The number of rotated files to keep. |
-| `org.apache.sling.commons.log.file.size` | '.'yyyy-MM-dd | 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. |
-| `org.apache.sling.commons.log.pattern` | {0,date,dd.MM.yyyy HH:mm:ss.SSS} *{4}* [{2}]({{ refs.-2.path }}) {3} {5} | The `MessageFormat` pattern to use for formatting log messages with the root logger. |
-| `org.apache.sling.commons.log.julenabled` | n/a | Enables the `java.util.logging` support. |
-| `org.apache.sling.commons.log.configurationFile` | n/a | Path for the Logback config file which would be used to configure logging. If the path is not absolute then it would be resolved against Sling Home |
-| `org.apache.sling.commons.log.packagingDataEnabled` | true | Boolean property to control packaging data support of Logback. See [Packaging Data][11] section of Logback for more details |
-| `org.apache.sling.commons.log.numOfLines` | 1000 | Number of lines from each log files to include while generating the dump in 'txt' mode. If set to -1 then whole file would be included |
-| `org.apache.sling.commons.log.maxOldFileCountInDump` | 3 | Maximum number of old rolled over files for each active file to be included while generating the dump as part of Status zip support |
-| `sling.log.root` | Sling Home | The directory, which is used to resolve relative path names against. If not specified it would map to sling.home. Since [4.0.2](https://issues.apache.org/jira/browse/SLING-4225)|
-
-## User Configuration - OSGi Based
-
-User Configuration after initial configuration is provided by the Configuration Admin Service. To this avail two
-`org.osgi.services.cm.ManagedServiceFactory` services are registered under the PIDs `org.apache.sling.commons.log.LogManager.factory.writer`
-and `org.apache.sling.commons.log.LogManager.factory.config` to receive configurations.
-
-
-### 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 `org.apache.sling.commons.log.LogManager.factory.config`
-may be created and configured with the Configuration Admin Service.
-
-The following properties may be set:
-
-| Property | Type | Default | Description |
-|--|--|--|--|
-| `org.apache.sling.commons.log.level` | `String` | `INFO` | Sets the logging level of the loggers. This may be any of the defined logging levels `DEBUG`, `INFO`, `WARN`, `ERROR` and `FATAL`. |
-| `org.apache.sling.commons.log.file` | `String` | undefined | 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. |
-| `org.apache.sling.commons.log.pattern` | `String` | {0,date,dd.MM.yyyy HH:mm:ss.SSS} *{4}* [{2}]({{ refs.-2.path }}) {3} {5} | 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 log level and {5} the actual log message. If the log call includes a Throwable, the stacktrace is just appended to the message regardless of the pattern. |
-| `org.apache.sling.commons.log.names` | `String[]` | -- | A list of logger names to which this configuration applies. |
-| `org.apache.sling.commons.log.additiv` | `Boolean` | false | If set to false then logs from these loggers would not be sent to any appender attached higher in the hierarchy |
-
-
-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 created. While the log level configuration is case insensitive, it
-is suggested to always use upper case letters.
-
-
-### 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:
-
-| Property | Default | Description |
-|--|--|--|
-| `org.apache.sling.commons.log.file` | undefined | Sets the log file to which log messages are written. If this property is empty or missing, log messages are written to `System.out`. |
-| `org.apache.sling.commons.log.file.number` | 5 | The number of rotated files to keep. |
-| `org.apache.sling.commons.log.file.size` | '.'yyyy-MM-dd | 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. |
-
-See the section *Log File Rotation* below for full details on the `org.apache.sling.commons.log.file.size` and
-`org.apache.sling.commons.log.file.number` properties.
-
-#### 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. In previous version, log rotation defaults to a 10MB file size limit.
-
-##### Scheduled Rotation
-
-The rolling schedule is specified by setting the `org.apache.sling.commons.log.file.size` 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. Internally
-the Log bundle configures a `TimeBasedRollingPolicy` for the appender. Refer to [TimeBasedRollingPolicy][10] for
-more details around the pattern format
-
-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.
-
-| DatePattern | Rollover schedule | Example |
-|--|--|--|
-| `'.'yyyy-MM` | Rollover at the beginning of each month | 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. |
-| `'.'yyyy-ww` | Rollover at the first day of each week. The first day of the week depends on the locale. | 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. |
-| `'.'yyyy-MM-dd` | Rollover at midnight each day.| 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.|
-| `'.'yyyy-MM-dd-a` | Rollover at midnight and midday of each day.| 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.|
-| `'.'yyyy-MM-dd-HH` | Rollover at the top of every hour.| 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.|
-| `'.'yyyy-MM-dd-HH-mm` | Rollover at the beginning of every minute.| 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.|
-
-Do not use the colon ":" character in anywhere in the pattern option. The text before the colon is interpreted as the
-protocol specification of a URL which is probably not what you want.
-
-Note that Scheduled Rotation ignores the `org.apache.sling.commons.log.file.number` property since the old log files are
-not numbered but "dated".
-
-##### Size Rotation
-
-Log file rotation by size is specified by setting the `org.apache.sling.commons.log.file.size` 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 `org.apache.sling.commons.log.file.number` 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 `org.apache.sling.commons.log.file.number`
-to `5` (which happens to be the default).
-
-## Logback Integration
-
-Logback integration provides following features
-
-* LogBack configuration can be provided via Logback config xml
-* Supports Appenders registered as OSGi Services
-* Supports Filters and TurboFilters registered as OSGi Services
-* Support providing Logback configuration as fragments through OSGi Service Registry
-* Support for referring to Appenders registered as OSGi services from with Logback config
-* Exposes Logback runtime state through the Felix WebConsole Plugin
-
-The following sections provide more details.
-
-### TurboFilters as OSGi Services
-
-[Logback TurboFilters][3] operate globally and are invoked for every Logback call. To register an OSGi `TurboFilter`,
-just to register an service that implements the `ch.qos.logback.classic.turbo.TurboFilter` interface.
-
-:::java
-import import ch.qos.logback.classic.turbo.MatchingFilter;
-
-SimpleTurboFilter stf = new SimpleTurboFilter();
-ServiceRegistration sr = bundleContext.registerService(TurboFilter.class.getName(), stf, null);
-
-private static class SimpleTurboFilter extends MatchingFilter {
-@Override
-public FilterReply decide(Marker marker, Logger logger, Level level, String format,
-Object[] params, Throwable t) {
-if(logger.getName().equals("turbofilter.foo.bar")){
-return FilterReply.DENY;
-}
-return FilterReply.NEUTRAL;
-}
-}
-
-As these filters are invoked for every call they must execute quickly.
-
-### Filters as OSGi services
-
-[Logback Filters][1] are attached to appenders and are used to determine if any LoggingEvent needs to
-be passed to the appender. When registering a filter the bundle needs to configure a service property
-`appenders` which refers to list of appender names to which the Filter must be attached
-
-
-:::java
-import ch.qos.logback.core.filter.Filter;
-
-SimpleFilter stf = new SimpleFilter();
-Dictionary<String, Object> props = new Hashtable<String, Object>();
-props.put("appenders", "TestAppender");
-ServiceRegistration sr = bundleContext.registerService(Filter.class.getName(), stf, props);
-
-private static class SimpleFilter extends Filter<ILoggingEvent> {
-
-@Override
-public FilterReply decide(ILoggingEvent event) {
-if(event.getLoggerName().equals("filter.foo.bar")){
-return FilterReply.DENY;
-}
-return FilterReply.NEUTRAL;
-}
-}
-
-If the `appenders` value is set to `*` then the filter would be registered with all the appenders (`Since 4.0.4`)
-
-### Appenders as OSGi services
-
-[Logback Appenders][2] handle the logging events produced by Logback. To register an OSGi `Appender`,
-just register a service that implements the `ch.qos.logback.core.Appender` interface. Such a service must
-have a `loggers` service property, which refers to list of logger names to which the Appender must be attached.
-
-:::java
-Dictionary<String,Object> props = new Hashtable<String, Object>();
-
-String[] loggers = {
-"foo.bar:DEBUG",
-"foo.bar.zoo:INFO",
-};
-
-props.put("loggers",loggers);
-sr = bundleContext.registerService(Appender.class.getName(),this,props);
-
-### Logback Config Fragment Support
-
-Logback supports including parts of a configuration file from another file (See [File Inclusion][4]). This module
-extends that support by allowing other bundles to provide config fragments. There are two ways to achieve that,
-described below.
-
-#### Logback config fragments as String objects
-
-If you have the config as string then you can register that String instance as a service with property `logbackConfig`
-set to true. The Sling Logback Extension monitors such objects and passes them to logback.
-
-
-:::java
-Properties props = new Properties();
-props.setProperty("logbackConfig","true");
-
-String config = "<included>n" +
-" <appender name="FOOFILE" class="ch.qos.logback.core.FileAppender">n" +
-" <file>${sling.home}/logs/foo.log</file>n" +
-" <encoder>n" +
-" <pattern>%d %-5level %logger{35} - %msg %n</pattern>n" +
-" </encoder>n" +
-" </appender>n" +
-"n" +
-" <logger name="foo.bar.include" level="INFO">n" +
-" <appender-ref ref="FOOFILE" />n" +
-" </logger>n" +
-"n" +
-"</included>";
-
-registration = context.registerService(String.class.getName(),config,props);
-
-
-If the config needs to be updated just re-register the service so that changes are picked up.
-
-#### Logback config fragments as ConfigProvider instances
-
-Another way to provide config fragments is with services that implement the
-`org.apache.sling.commons.log.logback.ConfigProvider` interface.
-
-:::java
-@Component
-@Service
-public class ConfigProviderExample implements ConfigProvider {
-public InputSource getConfigSource() {
-return new InputSource(getClass().getClassLoader().getResourceAsStream("foo-config.xml"));
-}
-}
-
-If the config changes then sending an OSGi event with the `org/apache/sling/commons/log/RESET` topic
-resets the Logback runtime.
-
-:::java
-eventAdmin.sendEvent(new Event("org/apache/sling/commons/log/RESET",new Properties()));
-
-### External Config File
-
-Logback can be configured with an external file. The file name can be specified through
-
-1. OSGi config - Look for a config with name `Apache Sling Logging Configuration` and specify the config file path.
-2. OSGi Framework Properties - Logback support also looks for a file named according to the OSGi framwork `org.apache.sling.commons.log.configurationFile` property.
-
-If you are providing an external config file then to support OSGi integration you need to add following
-action entry:
-
-:::xml
-<newRule pattern="*/configuration/osgi"
-actionClass="org.apache.sling.commons.log.logback.OsgiAction"/>
-<newRule pattern="*/configuration/appender-ref-osgi"
-actionClass="org.apache.sling.commons.log.logback.OsgiAppenderRefAction"/>
-<osgi/>
-
-The `osgi` element enables the OSGi integration support
-
-### Java Util Logging (JUL) Integration
-
-The bundle also support [SLF4JBridgeHandler][9]. The two steps listed below enable the JUL integration.
-This allows for routing logging messages from JUL to the Logbback appenders.
-
-1. Set the `org.apache.sling.commons.log.julenabled` framework property to true.
-
-
-If `org.apache.sling.commons.log.julenabled` is found to be true then [LevelChangePropagator][8] would be
-registered automatically with Logback
-
-### <a name="config-override"></a>Configuring OSGi appenders in the Logback Config
-
-So far Sling used to configure the appenders based on OSGi config. This provides a very limited
-set of configuration options. To make use of other Logback features you can override the OSGi config
-from within the Logback config file. OSGi config based appenders are named based on the file name.
-
-For example, for the following OSGi config
-
-org.apache.sling.commons.log.file="logs/error.log"
-org.apache.sling.commons.log.level="INFO"
-org.apache.sling.commons.log.file.size="'.'yyyy-MM-dd"
-org.apache.sling.commons.log.file.number=I"7"
-org.apache.sling.commons.log.pattern="{0,date,dd.MM.yyyy HH:mm:ss.SSS} *{4}* [{2}] {3} {5}"
-
-The Logback appender would be named `logs/error.log`. To extend/override the config in a Logback config
-create an appender with the name `logs/error.log`:
-
-:::xml
-<appender name="/logs/error.log" class="ch.qos.logback.core.FileAppender">
-<file>${sling.home}/logs/error.log</file>
-<encoder>
-<pattern>%d %-5level %X{sling.userId:-NA} [%thread] %logger{30} %marker- %msg %n</pattern>
-<immediateFlush>true</immediateFlush>
-</encoder>
-</appender>
-
-In this case the logging module creates an appender based on the Logback config instead of the OSGi config.
-This can be used to move the application from OSGi based configs to Logback based configs.
-
-## Using Slf4j API 1.7
-
-With Slf4j API 1.7 onwards its possible to use logger methods with varargs i.e. log n arguments without
-constructing an object array e.g. `log.info("This is a test {} , {}, {}, {}",1,2,3,4)`. Without var args
-you need to construct an object array `log.info("This is a test {} , {}, {}, {}",new Object[] {1,2,3,4})`.
-To make use of this API and still be able to use your bundle on Sling systems which package older version
-of the API jar, follow the below steps. (See [SLING-3243][SLING-3243]) for more details.
-
-1. Update the api version in the pom:
-
-:::xml
-<dependencies>
-<dependency>
-<groupId>org.slf4j</groupId>
-<artifactId>slf4j-api</artifactId>
-<version>1.7.5</version>
-<scope>provided</scope>
-</dependency>
-...
-</dependency>
-
-2. Add an `Import-Package` instruction with a custom version range:
-
-:::xml
-<build>
-<plugins>
-<plugin>
-<groupId>org.apache.felix</groupId>
-<artifactId>maven-bundle-plugin</artifactId>
-<extensions>true</extensions>
-<configuration>
-<instructions>
-...
-<Import-Package>
-org.slf4j;version="[1.5,2)",
-*
-</Import-Package>
-</instructions>
-</configuration>
-</plugin>
-...
-</plugins>
-</build>
-
-The Slf4j API bundle 1.7.x is binary compatible with 1.6.x.
-
-This setup allows your bundles to make use of the var args feature while making logging calls, but the bundles
-can still be deployed on older systems which provide only the 1.6.4 version of the slf4j api.
-
-## Log Tracer
-
-Log Tracer provides support for enabling the logs for specific category at specific
-level and only for specific request. It provides a very fine level of control via config provided
-as part of HTTP request around how the logging should be performed for given category.
-
-Refer to [Log Tracer Doc](/documentation/bundles/log-tracers.html) for more details
-
-## Slf4j MDC
-
-Sling MDC Inserting Filter exposes various request details as part of [MDC][11].
-
-Currently it exposes following variables:
-
-1. `req.remoteHost` - Request remote host
-2. `req.userAgent` - User Agent Header
-3. `req.requestURI` - Request URI
-4. `req.queryString` - Query String from request
-5. `req.requestURL` -
-6. `req.xForwardedFor` -
-7. `sling.userId` - UserID associated with the request. Obtained from ResourceResolver
-8. `jcr.sessionId` - Session ID of the JCR Session associated with current request.
-
-The filter also allow configuration to extract data from request cookie, header and parameters.
-Look for configuration with name 'Apache Sling Logging MDC Inserting Filter' for details on
-specifying header, cookie, param names.
-
-
-
-<a name="mdc-pattern">
-### Including MDC in Log Message
-
-To include the MDC value in log message you MUST use the [Logback pattern][15] based on Logback
-and not the old MessageFormat based pattern.
-
-%d{dd.MM.yyyy HH:mm:ss.SSS} *%p* [%X{req.remoteHost}] [%t] %c %msg%n
-
-### Installation
-
-Download the bundle from [here][12] or use following Maven dependency
-
-::xml
-<dependency>
-<groupId>org.apache.sling</groupId>
-<artifactId>org.apache.sling.extensions.slf4j.mdc</artifactId>
-<version>1.0.0</version>
-</dependency>
-
-## Logback Groovy Fragment
-
-This fragment is required to make use of Groovy based event evaluation support
-provided by Logback. This enables programatic filtering of the log messages and
-is useful to get desired logs without flooding the system. For example Oak
-logs the JCR operations being performed via a particular session. if this lo is
-enabled it would flood the log with messages from all the active session. However
-if you need logging only from session created in a particular thread then that
-can be done in following way
-
-::xml
-<?xml version="1.0" encoding="UTF-8"?>
-<configuration scan="true" scanPeriod="1 second">
-<jmxConfigurator/>
-<newRule pattern="*/configuration/osgi" actionClass="org.apache.sling.commons.log.logback.OsgiAction"/>
-<newRule pattern="*/configuration/appender-ref-osgi" actionClass="org.apache.sling.commons.log.logback.OsgiAppenderRefAction"/>
-<osgi/>
-
-<appender name="OAK" class="ch.qos.logback.core.FileAppender">
-<filter class="ch.qos.logback.core.filter.EvaluatorFilter">
-<evaluator class="ch.qos.logback.classic.boolex.GEventEvaluator">
-<expression><![CDATA[
-return e.getThreadName().contains("JobHandler");
-]]></expression>
-</evaluator>
-<OnMismatch>DENY</OnMismatch>
-<OnMatch>ACCEPT</OnMatch>
-</filter>
-<file>${sling.home}/logs/oak.log</file>
-<encoder>
-<pattern>%d %-5level [%thread] %marker- %msg %n</pattern>
-<immediateFlush>true</immediateFlush>
-</encoder>
-</appender>
-
-<logger name="org.apache.jackrabbit.oak.jcr.operations" level="DEBUG" additivity="false">
-<appender-ref ref="OAK"/>
-</logger>
-</configuration>
-
-Logback exposes a variable `e` which is of type [ILoggingEvent][13]. It provides access to current logging
-event. Above logback config would route all log messages from `org.apache.jackrabbit.oak.jcr.operations`
-category to `${sling.home}/logs/oak.log`. Further only those log messages would be logged
-where the `threadName` contains `JobHandler`. Depending on the requirement the expression can
-be customised.
-
-### Installation
-
-Currently the bundle is not released and has to be build from [here][14]
-
-::xml
-<dependency>
-<groupId>org.apache.sling</groupId>
-<artifactId>org.apache.sling.extensions.logback-groovy-fragment</artifactId>
-<version>1.0.0-SNAPSHOT</version>
-</dependency>
-
-## FAQ
-
-##### Q. Can Sling Commons Log bundle be used in non Sling environments
-
-This bundle does not depend on any other Sling bundle and can be easily used in any OSGi framework.
-To get complete log support working you need to deploy following bundles
-
-* Slf4j-Api - org.slf4j:slf4j-api
-* Jcl over Slf4j - org.slf4j:jcl-over-slf4j
-* Log4j over Slf4j - org.slf4j:log4j-over-slf4j
-* Sling Log Service - org.apache.sling:org.apache.sling.commons.logservice:1.0.2
-* Sling Commons Log - org.apache.sling:org.apache.sling.commons.log:4.0.0 or above
-* Sling Log WebConsole - org.apache.sling.commons.log.webconsole:1.0.0 or above
-
-##### Q. How to start Sling with an external logback.xml file
-
-You need to specify the location of logback.xml via `org.apache.sling.commons.log.configurationFile`
-
-java -jar org.apache.sling.launchpad-XXX-standalone.jar -Dorg.apache.sling.commons.log.configurationFile=/path/to/logback
-
-
-[1]: http://logback.qos.ch/manual/filters.html
-[2]: http://logback.qos.ch/manual/appenders.html
-[3]: http://logback.qos.ch/manual/filters.html#TurboFilter
-[4]: http://logback.qos.ch/manual/configuration.html#fileInclusion
-[8]: http://logback.qos.ch/manual/configuration.html#LevelChangePropagator
-[9]: http://www.slf4j.org/api/org/slf4j/bridge/SLF4JBridgeHandler.html
-[10]: http://logback.qos.ch/manual/appenders.html#TimeBasedRollingPolicy
-[SLING-3243]: https://issues.apache.org/jira/browse/SLING-3243
-[11]: http://www.slf4j.org/manual.html#mdc
-[12]: http://sling.apache.org/downloads.cgi
-[13]: http://logback.qos.ch/apidocs/ch/qos/logback/classic/spi/ILoggingEvent.html
-[14]: http://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/logback-groovy-fragment/
-[15]: http://logback.qos.ch/manual/layouts.html#conversionWord
-[SLING-6144]: https://issues.apache.org/jira/browse/SLING-6144
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/development/maven-archetypes.md
----------------------------------------------------------------------
diff --git a/content/documentation/development/maven-archetypes.md b/content/documentation/development/maven-archetypes.md
deleted file mode 100644
index 81346ad..0000000
--- a/content/documentation/development/maven-archetypes.md
+++ /dev/null
@@ -1,32 +0,0 @@
-title=Maven Archetypes
-type=page
-status=published
-~~~~~~
-translation_pending: true
-
-Sling includes four Maven archetypes to quick start development. See [http://maven.apache.org/archetype/maven-archetype-plugin/](http://maven.apache.org/archetype/maven-archetype-plugin/) for general information on using Maven archetypes. The Maven groupId for all Sling archetypes is `org.apache.sling`.
-
-### 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/sling.properties`).
-
-### 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/sling.properties`).
-
-### 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`).
-
-### 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.
-
-### 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.
-
-
-### 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.
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/development/maven-launchpad-plugin.md
----------------------------------------------------------------------
diff --git a/content/documentation/development/maven-launchpad-plugin.md b/content/documentation/development/maven-launchpad-plugin.md
deleted file mode 100644
index 59b09a6..0000000
--- a/content/documentation/development/maven-launchpad-plugin.md
+++ /dev/null
@@ -1,161 +0,0 @@
-title=Maven Launchpad Plugin
-type=page
-status=published
-~~~~~~
-translation_pending: true
-
-<div class="note">
-This page is out of sync with the latest maven-launchpad-plugin features and settings. For now,
-refer to the source code and the launchpad/builder and launchpad/testing modules for more information.
-</div>
-
-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:
-
-* [org.apache.sling.launchpad](http://svn.apache.org/repos/asf/sling/trunk/launchpad/builder) - produces an application descriptor.
-* [org.apache.sling.launchpad.testing](http://svn.apache.org/repos/asf/sling/trunk/launchpad/testing/) - uses the application descriptor from `org.apache.sling.launchpad` and adds two bundles.
-
-Maven Launchpad Plugin provides the following goals:
-
-| Goals | Description |
-|--|--|
-| launchpad:prepare-package | Create the file system structure required by Sling's Launchpad framework. |
-| launchpad:attach-bundle-list | Attach the bundle list descriptor to the current project as a Maven artifact. |
-| launchpad:create-karaf-descriptor | Create an Apache Karaf Feature descriptor. |
-| launchpad:create-bundle-jar | Create a JAR file containing the bundles in a Launchpad-structured JAR file. |
-| launchpad:check-bundle-list-for-snapshots | Validate that the bundle list does not contain any SNAPSHOT versions. |
-| launchpad:run | Run a Launchpad application. |
-| launchpad:start | Start a Launchpad application. |
-| launchpad:stop | Stop a Launchpad application. |
-| launchpad:output-bundle-list | Output the bundle list to the console as XML. (added in version 2.0.8) |
-
-### 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 `org.apache.sling.launchpad:org.apache.sling.launchpad:RELEASE:xml:bundlelist`, but can be overridden by setting the `defaultBundleList` plugin parameter.
-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.
-
-### Framework Configuration
-
-For the `run` and `start` goals, the plugin will look for a file named `src/test/config/sling.properties`. 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
-
-
-## 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>org.apache.sling</groupId>
-<artifactId>org.apache.sling.jcr.api</artifactId>
-<version>2.0.2-incubator</version>
-</bundle>
-</startLevel>
-</bundles>
-
-
-Within each `bundle` element, `type` and `classifier` are also supported.
-
-The Http Service support can not be configured using the bundle list, but only using the `jarWebSupport` parameter, since it is specific to whether the Sling Launchpad is built as a java application (in which case the Jetty-based Http Service is used) or a web application (in which case the Http Service bridge is used).
-
-## 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.
-
-## Integration Testing
-
-For integration testing examples, see `/samples/inplace-integration-test` and `launchpad/testing` in the Sling source tree.
-
-## Bundle List Rewriting
-
-The Maven Launchpad Plugin supports the use of rules to rewrite the bundle list. These rules are executed by the [Drools](http://www.jboss.org/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 `org.apache.maven.execution.MavenSession`.
-* `mavenProject` - an instance of `org.apache.maven.project.MavenProject`.
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/development/maven-usage.md
----------------------------------------------------------------------
diff --git a/content/documentation/development/maven-usage.md b/content/documentation/development/maven-usage.md
deleted file mode 100644
index 44757c7..0000000
--- a/content/documentation/development/maven-usage.md
+++ /dev/null
@@ -1,34 +0,0 @@
-title=Maven Usage
-type=page
-status=published
-~~~~~~
-
-Apache Sling uses Maven as a build tool. This page documents some of the choices that we made when using Maven.
-
-## Parent POM
-
-We separate the reactor POM from the parent POM. While the reactor POM functions as a simple aggregator, the parent POM, currently located at [parent/pom.xml](http://svn.apache.org/repos/asf/sling/trunk/parent/pom.xml), holds the common build configuration for all modules.
-
-The reference to the parent POM is usually set to a released version since we don't deploy it as a SNAPSHOT during the build process. That reference must also contain an empty parentPath element, otherwise recent version of Maven will try to find it in the local filesystem, disregarding the version if the groupId and artifactId match. An example of how to reference the parent POM is
-
-#!xml
-<parent>
-<groupId>org.apache.sling</groupId>
-<artifactId>sling</artifactId>
-<version>$VERSION</version>
-<relativePath/>
-</parent>
-
-Where `$VERSION` is replaced by the latest parent POM version.
-
-## Java version
-
-The version of Java targeted by a module can be declared by setting a property in the pom.xml named `sling.java.version`. Configuration inherited from the parent POM will ensure that all the plugins will be correctly configured, including
-
-* maven-compiler-plugin: source and target arguments to use when compiling code
-* animal-sniffer-maven-plugin: signatures to use when validating compliance with a given Java version
-* maven-bundle-plugin: value of the Bundle-RequiredExecutionEnvironment header
-
-## Dependency management
-
-See [Dependency Management](/documentation/development/dependency-management.html)
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/development/maventipsandtricks.md
----------------------------------------------------------------------
diff --git a/content/documentation/development/maventipsandtricks.md b/content/documentation/development/maventipsandtricks.md
deleted file mode 100644
index 53f4fc4..0000000
--- a/content/documentation/development/maventipsandtricks.md
+++ /dev/null
@@ -1,61 +0,0 @@
-title=MavenTipsAndTricks
-type=page
-status=published
-~~~~~~
-translation_pending: true
-
-Here's our collection of tips and tricks for building Sling with [Maven](http://maven.apache.org).
-
-# 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.
-
-# Maven settings
-
-## 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.
-
-<div class="note">
-Does anyone have a similar command-line option that works under Windows?
-</div>
-
-#
-# MAVEN_OPTS
-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.
-
-## 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.
-
-## 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 this).
-
-## 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.
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/development/monitoring-requests.md
----------------------------------------------------------------------
diff --git a/content/documentation/development/monitoring-requests.md b/content/documentation/development/monitoring-requests.md
deleted file mode 100644
index f2b1cbf..0000000
--- a/content/documentation/development/monitoring-requests.md
+++ /dev/null
@@ -1,14 +0,0 @@
-title=Monitoring Requests
-type=page
-status=published
-~~~~~~
-
-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.
-
-
http://git-wip-us.apache.org/repos/asf/sling-site/blob/7b703652/content/documentation/development/osgi-mock.md
----------------------------------------------------------------------
diff --git a/content/documentation/development/osgi-mock.md b/content/documentation/development/osgi-mock.md
deleted file mode 100644
index bf76a83..0000000
--- a/content/documentation/development/osgi-mock.md
+++ /dev/null
@@ -1,189 +0,0 @@
-title=OSGi Mocks
-type=page
-status=published
-~~~~~~
-
-Mock implementation of selected OSGi APIs for easier testing.
-
-[TOC]
-
-
-## Maven Dependency
-
-#!xml
-<dependency>
-<groupId>org.apache.sling</groupId>
-<artifactId>org.apache.sling.testing.osgi-mock</artifactId>
-</dependency>
-
-See latest version on the [downloads page](/downloads.cgi).
-
-There are two major version ranges available:
-
-* osgi-mock 1.x: compatible with OSGi R4 and above
-* osgi-mock 2.x: compatible with OSGi R6 and above
-
-
-## Implemented mock features
-
-The mock implementation supports:
-
-* Instantiating OSGi `Bundle`, `BundleContext` and `ComponentContext` objects and navigate between them.
-* Register OSGi SCR services and get references to service instances
-* Supports reading OSGi SCR metadata from `/OSGI-INF/<pid>.xml` and from `/OSGI-INF/serviceComponents.xml`
-* Apply service properties/component configuration provided in unit test and from SCR metadata
-* Inject SCR dependencies - static and dynamic
-* Call lifecycle methods for activating, deactivating or modifying SCR components
-* Service and bundle listener implementation
-* Mock implementation of `LogService` which logs to SLF4J in JUnit context
-* Mock implementation of `EventAdmin` which supports `EventHandler` services
-* Mock implementation of `ConfigAdmin`
-* Context Plugins
-
-Since osgi-mock 2.0.0:
-
-* Support OSGi R6 and Declarative Services 1.3: Field-based reference bindings and component property types
-
-
-## Usage
-
-### OSGi Context JUnit Rule
-
-The OSGi mock context can be injected into a JUnit test using a custom JUnit rule named `OsgiContext`.
-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 OsgiContext context = new OsgiContext();
-
-@Test
-public void testSomething() {
-
-// register and activate service with configuration
-MyService service1 = context.registerInjectActivateService(new MyService(),
-"prop1", "value1");
-
-// get service instance
-OtherService service2 = context.getService(OtherService.class);
-
-}
-
-}
-
-It is possible to combine such a unit test with a `@RunWith` annotation e.g. for
-[Mockito JUnit Runner][mockito-testrunner].
-
-The `OsgiContext` object provides access to mock implementations of:
-
-* OSGi Component Context
-* OSGi Bundle Context
-
-Additionally it supports:
-
-* Registering and activating OSGi services and inject dependencies
-
-
-### Getting OSGi mock objects
-
-The factory class `MockOsgi` allows to instantiate the different mock implementations.
-
-Example:
-
-#!java
-// get bundle context
-BundleContext bundleContext = MockOsgi.newBundleContext();
-
-// get component context with configuration
-BundleContext bundleContext = MockOsgi.newComponentContext(properties,
-"prop1", "value1");
-
-It is possible to simulate registering of OSGi services (backed by a simple hash map internally):
-
-#!java
-// register service
-bundleContext.registerService(MyClass.class, myService, properties);
-
-// get service instance
-ServiceReference ref = bundleContext.getServiceReference(MyClass.class.getName());
-MyClass service = bundleContext.getService(ref);
-
-
-### Activation and Dependency Injection
-
-It is possible to simulate OSGi service activation, deactivation and dependency injection and the mock implementation
-tries to to its best to execute all as expected for an OSGi environment.
-
-Example:
-
-#!java
-// get bundle context
-BundleContext bundleContext = MockOsgi.newBundleContext();
-
-// create service instance manually
-MyService service = new MyService();
-
-// inject dependencies
-MockOsgi.injectServices(service, bundleContext);
-
-// activate service
-MockOsgi.activate(service, props);
-
-// operate with service...
-
-// deactivate service
-MockOsgi.deactivate(service);
-
-Please note:
-
-* You should ensure that you register you services in the correct order of their dependency chain.
-Only dynamic references will be handled automatically independent of registration order.
-* The injectServices, activate and deactivate Methods can only work properly when the SCR XML metadata files
-are preset in the classpath at `/OSGI-INF`. They are generated automatically by the Maven SCR plugin, but might be
-missing if your clean and build the project within your IDE (e.g. Eclipse). In this case you have to compile the
-project again with maven and can run the tests - or use a Maven IDE Integration like m2eclipse.
-
-
-### Provide your own configuration via ConfigAdmin
-
-If you want to provide your own configuration to an OSGi service that you do not register and activate itself in the mock context you can provide your own custom OSGi configuration via the mock implementation of the `ConfigAdmin` service.
-
-Example:
-
-#!java
-
-ConfigurationAdmin configAdmin = context.getService(ConfigurationAdmin.class);
-Configuration myServiceConfig = configAdmin.getConfiguration(MY_SERVICE_PID);
-Dictionary<String, Object> props = new Hashtable<String, Object>();
-props.put("prop1", "value1");
-myServiceConfig.update(props);
-
-
-### Context Plugins
-
-OSGi 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<OsgiContextImpl>` interface. For convenience it is recommended to extend the abstract class `org.apache.sling.testing.mock.osgi.context.AbstractContextPlugin<OsgiContextImpl>`. These plugins can be used with OSGi Mock context, but also with context instances deriving from it like Sling Mocks and 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 `OsgiContextBuilder` class instead of directly instantiating the `OsgiContext`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 OsgiContext context = new OsgiContextBuilder().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]
-
-
-
-[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/release-management.md
----------------------------------------------------------------------
diff --git a/content/documentation/development/release-management.md b/content/documentation/development/release-management.md
deleted file mode 100644
index 29c2b65..0000000
--- a/content/documentation/development/release-management.md
+++ /dev/null
@@ -1,461 +0,0 @@
-title=Release Management
-type=page
-status=published
-~~~~~~
-
-Sling releases (and SNAPSHOTS) are deployed to the [Nexus repository](http://repository.apache.org) instead of the traditional deployment via the Maven 2 mirrors source on `people.apache.org`. This makes the release process much leaner and simpler. In addtion we can benefit from the Apache Parent POM 6, which has most of the release profile setup built-in.
-
-Most of the hard work of preparing and deploying the release is done by Maven.
-
-[TOC]
-
-
-
-## Prerequisites
-
-* To prepare or perform a release you *MUST BE* at least be an Apache Sling Committer.
-* Each and every release must be signed; therefore the public key should be cross signed by other Apache committers (not required but suggested) and this public key should be added to [https://people.apache.org/keys/group/sling.asc](https://people.apache.org/keys/group/sling.asc) and either on pool.sks-keyservers.net or pgp.mit.edu (See Appendix A)
-* Make sure you have all [Apache servers](http://maven.apache.org/developers/committer-settings.html) defined in your `settings.xml`
-* See Appendix B for Maven and SCM credentials
-
-*Note*: Listing the Apache servers in the `settings.xml` file also requires adding the password to that file. Starting with Maven 2.1 this password may be encrypted and needs not be give in plaintext. Please refer to [Password Encryption](http://maven.apache.org/guides/mini/guide-encryption.html) for more information.
-
-In the past we staged release candidates on our local machines using a semi-manual process. Now that we inherit from the Apache parent POM version 6, a repository manager will automatically handle staging for you. This means you now only need to specify your GPG passphrase in the release profile of your `${user.home}/.m2/settings.xml`:
-
-
-<settings>
-...
-<profiles>
-<profile>
-<id>apache-release</id>
-<properties>
-<gpg.passphrase> <!-- YOUR KEY PASSPHRASE --> </gpg.passphrase>
-</properties>
-</profile>
-</profiles>
-...
-</settings>
-
-
-Everything else has been configured in the latest Sling Parent POM:
-
-
-<parent>
-<groupId>org.apache.sling</groupId>
-<artifactId>sling</artifactId>
-<version>6</version>
-</parent>
-
-
-
-
-## Staging the Release Candidates
-
-First prepare your POMs for release:
-
-1. Make sure there are no snapshots in the POMs to be released. In case you rely on a release version which is not yet promoted, you have to temporarily switch that dependency version to the release version. This might break the Jenkins CI build though, as the staged version is not yet visible to Jenkins, so revert this change after you have staged the release candidate.
-1. Check that your POMs will not lose content when they are rewritten during the release process
-
-$ mvn release:prepare -DdryRun=true
-
-Compare the original `pom.xml` with the one called `pom.xml.tag` to see if the license or any other info has been removed. This has been known to happen if the starting `<project>` tag is not on a single line. The only things that should be different between these files are the `<version>` and `<scm>` elements. If there are any other changes, you must fix the original `pom.xml` file and commit before proceeding with the release.
-
-1. Publish a snapshot
-
-$ mvn deploy
-...
-[INFO] [deploy:deploy]
-[INFO] Retrieving previous build number from apache.snapshots.https
-...
-
-* If you experience an error during deployment like a HTTP 401 check your settings for the required server entries as outlined in the *Prerequisites*
-* Make sure the generated artifacts respect the Apache release [rules](http://www.apache.org/dev/release.html): NOTICE and LICENSE files should be present in the META-INF directory within the jar. For -sources artifacts, be sure that your POM does not use the maven-source-plugin:2.0.3 which is broken. The recommended version at this time is 2.0.4
-* You should verify the deployment under the [snapshot](https://repository.apache.org/content/groups/snapshots/org/apache/sling) repository on Apache
-
-1. Prepare the release
-
-$ mvn release:clean
-$ mvn release:prepare
-
-* Preparing the release will create the new tag in SVN, automatically checking in on your behalf
-* If you get a build failure because of an SVN commit problem (namely *The specified baseline is not the latest baseline, so it may not be checked out.*), just repeat the `mvn release:prepare` command until SVN is happy. This is based on a known timing issue when using the European SVN mirror.
-
-1. Stage the release for a vote
-
-$ mvn release:perform
-
-* The release will automatically be inserted into a temporary staging repository for you, see the Nexus [staging documentation](http://www.sonatype.com/books/nexus-book/reference/staging.html) for full details
-* You can continue to use `mvn release:prepare` and `mvn release:perform` on other sub-projects as necessary on the same machine and they will be combined in the same staging repository - this is useful when making a release of multiple Sling modules.
-
-1. Close the staging repository:
-* Login to [https://repository.apache.org](https://repository.apache.org) using your Apache SVN credentials. Click on *Staging* on the left. Then click on *org.apache.sling* in the list of repositories. In the panel below you should see an open repository that is linked to your username and IP. Right click on this repository and select *Close*. This will close the repository from future deployments and make it available for others to view. If you are staging multiple releases together, skip this step until you have staged everything
-
-1. Verify the staged artifacts
-* If you click on your repository, a tree view will appear below. You can then browse the contents to ensure the artifacts are as you expect them. Pay particular attention to the existence of *.asc (signature) files. If you don't like the content of the repository, right click your repository and choose *Drop*. You can then rollback your release (see *Canceling the Release*) and repeat the process
-* Note the staging repository URL, especially the number at the end of the URL. You will need this in your vote email
-
-## Starting the Vote
-
-Propose a vote on the dev list with the closed issues, the issues left, and the staging repository - for example:
-
-
-To: "Sling Developers List" <de...@sling.apache.org>
-Subject: [VOTE] Release Apache Sling ABC version X.Y.Z
-
-Hi,
-
-We solved N issues in this release:
-https://issues.apache.org/jira/browse/SLING/fixforversion/...
-
-There are still some outstanding issues:
-https://issues.apache.org/jira/browse/SLING/component/...
-
-Staging repository:
-https://repository.apache.org/content/repositories/orgapachesling-[YOUR REPOSITORY ID]/
-
-You can use this UNIX script to download the release and verify the signatures:
-http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
-
-Usage:
-sh check_staged_release.sh [YOUR REPOSITORY ID] /tmp/sling-staging
-
-Please vote to approve this release:
-
-[ ] +1 Approve the release
-[ ] 0 Don't care
-[ ] -1 Don't release, because ...
-
-This majority vote is open for at least 72 hours.
-
-## Wait for the Results
-
-From [Votes on Package Releases](http://www.apache.org/foundation/voting.html):
-
-> Votes on whether a package is ready to be released follow a format similar to majority
-> approval -- except that the decision is officially determined solely by whether at least
-> three +1 votes were registered. Releases may not be vetoed. Generally the community
-> will table the vote to release if anyone identifies serious problems, but in most cases
-> the ultimate decision, once three or more positive votes have been garnered, lies with
-> the individual serving as release manager. The specifics of the process may vary from
-> project to project, but the 'minimum of three +1 votes' rule is universal.
-
-The list of binding voters is available on the [Project Team](/project-information/project-team.html) page.
-
-
-If the vote is successful, post the result to the dev list - for example:
-
-
-
-To: "Sling Developers List" <de...@sling.apache.org>
-Subject: [RESULT] [VOTE] Release Apache Sling ABC version X.Y.Z
-
-Hi,
-
-The vote has passed with the following result :
-
-+1 (binding): <<list of names>>
-+1 (non binding): <<list of names>>
-
-I will copy this release to the Sling dist directory and
-promote the artifacts to the central Maven repository.
-
-
-Be sure to include all votes in the list and indicate which votes were binding. Consider -1 votes very carefully. While there is technically no veto on release votes, there may be reasons for people to vote -1. So sometimes it may be better to cancel a release when someone, especially a member of the PMC, votes -1.
-
-If the vote is unsuccessful, you need to fix the issues and restart the process - see *Canceling the Release*. Note that any changes to the artifacts under vote require a restart of the process, no matter how trivial. When restarting a vote version numbers must not be reused, since binaries might have already been copied around.
-
-If the vote is successful, you need to promote and distribute the release - see *Promoting the Release*.
-
-
-
-## Canceling the Release
-
-If the vote fails, or you decide to redo the release:
-
-1. Remove the release tag from Subversion (`svn del ...`)
-1. Login to [https://repository.apache.org](https://repository.apache.org) using your Apache SVN credentials. Click on *Staging* on the left. Then click on *org.apache.sling* in the list of repositories. In the panel below you should see a closed repository that is linked to your username and IP (if it's not yet closed you need to right click and select *Close*). Right click on this repository and select *Drop*.
-1. Remove the old version from Jira
-1. Create a new version in Jira with a version number following the one of the cancelled release
-1. Move all issues with the fix version set to the cancelled release to the next version
-1. Delete the old version from Jira
-1. Commit any fixes you need to make and start a vote for a new release.
-
-## Promoting the Release
-
-If the vote passes:
-
-
-1. Push the release to [https://dist.apache.org/repos/dist/release/sling/](https://dist.apache.org/repos/dist/release/sling/). This is only possible for PMC members (for a reasoning look at [http://www.apache.org/dev/release.html#upload-ci](http://www.apache.org/dev/release.html#upload-ci)). If you are not a PMC member, please ask one to do the upload for you.
-1. Commit the released artifacts to [https://dist.apache.org/repos/dist/release/sling/](https://dist.apache.org/repos/dist/release/sling/) which is replicated to [http://www.apache.org/dist/sling/](http://www.apache.org/dist/sling/) quickly via svnpubsub. Hint: use svn import to avoid having to checkout the whole folder first. The easiest to do this is to get the released artifact using the check script (check_staged_release.sh) and then simply copy the artifacts from the downloaded folder to your local checkout folder. Make sure to not add the checksum files for the signature file *.asc.*).
-* Make sure to *not* change the end-of-line encoding of the .pom when uploaded via svn import! Eg when a windows style eol encoded file is uploaded with the setting '*.pom = svn:eol-style=native' this would later fail the signature checks!
-1. Delete the old release artifacts from that same dist.apache.org svn folder (the dist directory is archived)
-1. Push the release to Maven Central
-1. Login to [https://repository.apache.org](https://repository.apache.org) with your Apache SVN credentials. Click on *Staging*. Find your closed staging repository and select it by checking the select box. Select the *Releases* repository from the drop-down list and click *Release* from the menu above.
-1. Once the release is promoted click on *Repositories*, select the *Releases* repository and validate that your artifacts are all there.
-1. Update the news section on the website at [news](/news.html).
-1. Update the download page on the website at [downloads](/downloads.cgi) to point to the new release.
-
-For the last two tasks, it's better to give the mirrors some time to distribute the uploaded artifacts (one day should be fine). This ensures that once the website (news and download page) is updated, people can actually download the artifacts.
-
-## Update JIRA
-
-Go to [Manage Versions](https://issues.apache.org/jira/plugins/servlet/project-config/SLING/versions) section on the SLING JIRA and mark the X.Y.Z version as released setting the release date to the date the vote has been closed.
-
-Also create a new version X.Y.Z+2, if that hasn't already been done.
-
-And keep the versions sorted, so when adding a new version moved it down to just above the previous versions.
-
-Close all issues associated with the released version.
-
-
-## Create an Announcement
-
-We usually do such announcements only for "important" releases, as opposed to small individual module
-releases which are just announced on our [news](/news.html) page.
-
-To: "Sling Developers List" <de...@sling.apache.org>, "Apache Announcements" <an...@apache.org>
-Subject: [ANN] Apache Sling ABC version X.Y.Z Released
-
-The Apache Sling team is pleased to announce the release of Apache Sling ABC version X.Y.Z
-
-Apache Sling is a web framework that uses a Java Content Repository, such as Apache Jackrabbit, to store and manage content. Sling applications use either scripts or Java servlets, selected based on simple name conventions, to process HTTP requests in a RESTful way.
-
-<<insert short description of the sub-project>>
-
-http://sling.apache.org/site/apache-sling-ABC.html
-
-This release is available from http://sling.apache.org/site/downloads.cgi
-
-Building from verified sources is recommended, but convenience binaries are
-also available via Maven:
-
-<dependency>
-<groupId>org.apache.sling</groupId>
-<artifactId>org.apache.sling.ABC</artifactId>
-<version>X.Y.Z</version>
-</dependency>
-
-Release Notes:
-
-<<insert release notes in text format from JIRA>>
-
-Enjoy!
-
--The Sling team
-
-*Important*: Add the release to the Software section of the next board report below [Reports](https://cwiki.apache.org/confluence/display/SLING/Reports).
-
-## Related Links
-
-1. [http://www.apache.org/dev/release-signing.html](http://www.apache.org/dev/release-signing.html)
-1. [http://wiki.apache.org/incubator/SigningReleases](http://wiki.apache.org/incubator/SigningReleases)
-
-## Releasing the Sling IDE Tooling
-
-While the Sling IDE tooling is built using Maven, the toolchain that it is based around does not cooperate well with the maven-release-plugin. As such, the release preparation and execution are slightly different. The whole process is outlined below, assuming that we start with a development version of 1.0.1-SNAPSHOT.
-
-1. set the fix version as released: `mvn tycho-versions:set-version -DnewVersion=1.0.2`
-1. update the version of the source-bundle project to 1.0.2
-1. commit the change to svn
-1. manually tag in svn using `svn copy https://svn.apache.org/repos/asf/sling/trunk/tooling/ide https://svn.apache.org/repos/asf/sling/tags/sling-ide-tooling-1.0.2`
-1. update to next version: `mvn tycho-versions:set-version -DnewVersion=1.0.3-SNAPSHOT` and also update the version of the source-bundle project
-1. commit the change to svn
-1. Checkout the version from the tag and proceed with the build from there `https://svn.apache.org/repos/asf/sling/tags/sling-ide-tooling-1.0.2`
-1. build the project with p2/gpg signing enabled: `mvn clean package -Psign`
-1. build the source bundle from the source-bundle directory: `mvn clean package`
-1. copy the following artifacts to https://dist.apache.org/repos/dist/dev/sling/ide-tooling-1.0.2
-1. source bundle ( org.apache.sling.ide.source-bundle-1.0.2.zip )
-1. zipped p2 repository ( org.apache.sling.ide.p2update-1.0.2.zip )
-1. ensure the artifacts are checksummed and gpg-signed by using the `tooling/ide/sign.sh` script
-1. call the vote
-
-The format of the release vote should be
-
-To: "Sling Developers List" <de...@sling.apache.org>
-Subject: [VOTE] Release Apache Sling IDE Tooling version X.Y.Z
-
-Hi,
-
-We solved N issues in this release:
-https://issues.apache.org/jira/browse/SLING/fixforversion/
-
-There are still some outstanding issues:
-https://issues.apache.org/jira/browse/SLING/component/12320908
-
-The release candidate has been uploaded at
-https://dist.apache.org/repos/dist/dev/sling, The release artifact is
-the source bundle - org.apache.sling.ide.source-bundle-X.Y.Z.zip -
-which can be used to build the project using
-
-mvn clean package
-
-The resulting binaries can be installed into an Eclipse instance from
-the update site which is found at p2update/target/repository after
-building the project.
-
-You can use this UNIX script to download the release and verify the signatures:
-http://svn.apache.org/repos/asf/sling/trunk/tooling/ide/check_staged_release.sh
-
-Usage:
-sh check_staged_release.sh X.Y.Z /tmp/sling-staging
-
-Please vote to approve this release:
-
-[ ] +1 Approve the release
-[ ] 0 Don't care
-[ ] -1 Don't release, because ...
-
-This majority vote is open for at least 72 hours
-
-
-Once the release has passed, the following must be done:
-
-1. announce the result of the vote, see [Wait for the results](#wait-for-the-results)
-1. update versions in jira, see [Update JIRA](#update-jira)
-1. upload p2update.zip* to https://dist.apache.org/repos/dist/release/sling/
-1. upload unzipped update site to https://dist.apache.org/repos/dist/release/sling/eclipse/1.0.2
-1. upload the source bundle to https://dist.apache.org/repos/dist/release/sling/eclipse/1.0.2
-1. create GPG signatures and checksums for all uploaded jars using the `tooling/ide/sign.sh` script
-1. update https://dist.apache.org/repos/dist/release/sling/eclipse/composite{Content,Artifacts}.xml to point version 1.0.2
-1. archive the old artifact versions but leave pointers to archive.apache.org, using compositeArtifacts.xml/compositeContent.xml , with a single child entry pointing to https://archive.apache.org/dist/sling/eclipse/1.0.0/
-1. remove the staged artifacts from https://dist.apache.org/repos/dist/dev/sling/ide-tooling-1.0.2
-1. update the news page and the download pages
-1. update the Eclipse Marketplace listing
-
-## Appendix A: Create and Add your key to [https://people.apache.org/keys/group/sling.asc](https://people.apache.org/keys/group/sling.asc)
-
-Considering that you are using a *nix system with a working OpenSSH, GnuPG, and bash you can create and add your own key with the following commands:
-
-1. Create a public/private pair key:
-
-$ gpg --gen-key
-
-When gpg asks for e-mail linked the key you *MUST USE* the <committer>@apache.org one. When gpg asks for comment linked the key you *SHOULD USE* "CODE SIGNING KEY"
-
-1. Add the key to [https://people.apache.org/keys/group/sling.asc](https://people.apache.org/keys/group/sling.asc)
-
-1. Type the following command replacing the word `<e-mail>` with your Apache's one (<committer>@apache.org) to get the key signature
-
-$ gpg --fingerprint <e-mail>
-
-The key signature is in the output following the `Key fingerprint = ` part.
-
-1. Add the key signature into the field 'OpenPGP Public Key Primary Fingerprint' in your profile at [https://id.apache.org](https://id.apache.org).
-
-1. You are *DONE*, but to see the changes on [https://people.apache.org/keys/group/sling.asc](https://people.apache.org/keys/group/sling.asc) you may need to wait a few hours;
-
-1. You also have to add your public key either on `pool.sks-keyservers.net` or `pgp.mit.edu` (for the staging repository). To do so you can follow these steps:
-1. Extract the key id from all the secret keys stored in the system:
-
-$ gpg --list-secret-keys.
-
-The output is something like this
-
-gpg --list-secret-keys
-/Users/konradwindszus/.gnupg/secring.gpg
-----------------------------------------
-
-sec 2048R/455ECC7C 2016-01-21
-uid Konrad Windszus <kw...@apache.org>
-ssb 2048R/226BCE00 2016-01-21
-
-The key id in this case is `455ECC7C`.
-
-1. Send the key towards e.g. `pool.sks-keyservers.net` via
-
-$ gpg --keyserver pool.sks-keyservers.net --send-key <key-id>
-
-
-
-## Appendix B: Maven and SCM credentials
-
-For running the `mvn release:prepare` command without giving credentials on command line add `svn.apache.org` to your `settings.xml`:
-
-<server>
-<id>svn.apache.org</id>
-<username>USERNAME</username>
-<password>ENCRYPTED_PASSWORD</password>
-</server>
-
-## Appendix C: Deploy bundles on the Sling OBR (obsolete)
-
-*Update November 2016: We do now longer maintain the Sling OBR for new releases.*
-
-We are mainting an OSGi Bundle Repository providing all release of the Sling Bundles. This repository is maintained as part of the Apache Sling site and is available at [http://sling.apache.org/obr/sling.xml](http://sling.apache.org/obr/sling.xml). The source for this page is maintained in the SVN repository below the _site_, that is at [http://svn.apache.org/repos/asf/sling/site/](http://svn.apache.org/repos/asf/sling/site/). To update the Sling OBR repository you must be an Apache Sling Committer since this requires SVN write access.
-
-To update the OBR you may use the Apache Felix Maven Bundle Plugin which prepares the bundle descriptor to be added to the OBR file. Follow these steps to update the OBR:
-
-1. Checkout or update the Site Source
-
-$ svn checkout https://svn.apache.org/repos/asf/sling/site
-
-Note, that you have to checkout the site using the `https` URL, otherwise you will not be able to commit the changes later.
-
-2. Deploy the Descriptor
-
-To deploy the project descriptor, checkout the tag of the bundle to deploy and run maven
-
-$ svn checkout http://svn.apache.org/repos/asf/sling/tags/the_module_tag
-$ cd the_module_tag
-$ mvn clean install org.apache.felix:maven-bundle-plugin:deploy -DprefixUrl=http://repo1.maven.org/maven2 -DremoteOBR=sling.xml -DaltDeploymentRepository=apache.releases::default::file:///path_to_site_checkout/trunk/content/obr
-
-This generates the bundle descriptor and adds it to the sling.xml file of your site checkout.
-As it also installs a fresh compiled version of the artifacts, it's better to remove that version from your local repository again (A new binary has new checksums etc.).
-
-2. Variant: Refer to Maven Repository
-
-Instead of checking out and building the project locally, you may also use the `deploy-file` goal of the Maven Bundle Plugin:
-
-$ wget http://repo1.maven.org/maven2/org/apache/sling/the_module/version/the_module-version.jar
-$ wget http://repo1.maven.org/maven2/org/apache/sling/the_moduleversion/the_module-version.pom
-$ mvn org.apache.felix:maven-bundle-plugin:deploy-file -Dfile=the_module-version.jar -DpomFile=the_module-version.pom -DbundleUrl=http://repo1.maven.org/maven2/org/apache/sling/the_module/version/the_module-version.jar -Durl=file:///path_to_site_checkout/obr -DprefixUrl=http://repo1.maven.org/maven2 -DremoteOBR=sling.xml
-$ rm the_module-version.jar the_module-version.pom
-
-3. Commit the Site Changes
-
-In the Site checkout folder commit the changes to the `trunk/content/obr/sling.xml` files (you may also review the changes using the `svn diff` command).
-
-$ svn commit -m"Add Bundle ABC Version X.Y.Z" trunk/content/obr/sling.xml
-
-4. Update the Site
-
-Wait for the buildbot to update the staging area with your site update (see dev list for an email).
-Then go to the CMS at [https://cms.apache.org/redirect?uri=http://sling.apache.org/obr](https://cms.apache.org/redirect?uri=http://sling.apache.org/obr) ,
-update your checkout and then publish the site.
-
-
-## Appendix D: Deploy Maven plugin documentation (if applicable)
-
-When releasing a Maven plugin, the Maven-generated documentation published under [http://sling.apache.org/components/](http://sling.apache.org/components/) needs
-to be updated.
-
-This is currently supported for:
-
-* `maven-sling-plugin`
-* `htl-maven-plugin`
-* `slingstart-maven-plugin`
-* `jspc-maven-plugin`
-
-To publish the plugin documentation execute the following steps after the release:
-
-1. Checkout the release tag of the released plugin (or reset your workspace)
-
-2. Build and stage the maven site of the plugin. Note that this *commits* the generated content to the components folder mentioned below.
-
-$ mvn clean site:site site:stage scm-publish:publish-scm
-
-3. Checkout the 'components' subtree of the Sling website
-
-$ svn checkout https://svn.apache.org/repos/asf/sling/site/trunk/content/components
-
-4. SVN-rename the generated documenation that the site plugin commited to `<plugin-name>-archives/<plugin-name>-LATEST` to `<plugin-name>-archives/<plugin-name>-<version>`
-
-5. SVN-remove the existing folder `<plugin-name>` and SVN-copy the folder `<plugin-name>-archives/<plugin-name>-<version>` to `<plugin-name>`
-
-6. Commit the changes.
-
-7. Publish the Sling site to production
-
-8. Check the results at [http://sling.apache.org/components/](http://sling.apache.org/components/)
-
-For background information about this process see the [Maven components reference documentation](http://maven.apache.org/developers/website/deploy-component-reference-documentation.html).