; Wed, 12 Dec 2012 09:17:31 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r841833 [6/28] - in /websites/staging/sling/trunk/content: ./ site/ site/46-line-blog.data/ site/authentication.data/ site/documentation.data/ site/first-steps.data/ site/getting-and-building-sling.data/ site/how-to-manage-events-in-sling.d... Date: Wed, 12 Dec 2012 09:17:17 -0000 To: commits@sling.apache.org From: buildbot@apache.org X-Mailer: svnmailer-1.0.8-patched Message-Id: <20121212091731.4F53A2388C02@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org Added: websites/staging/sling/trunk/content/site/content-loading-jcrcontentloader.html ============================================================================== --- websites/staging/sling/trunk/content/site/content-loading-jcrcontentloader.html (added) +++ websites/staging/sling/trunk/content/site/content-loading-jcrcontentloader.html Wed Dec 12 09:16:44 2012 @@ -0,0 +1,394 @@ + + + + + Apache Sling - Content Loading (jcr.contentloader) + + + + + +

+ +

+Apache Sling Website > Apache Sling > Documentation > Bundles > Content Loading (jcr.contentloader) +

Content Loading and Nodetype Support

+ +

Apache Sling provides support for initial content loading into a repository and for registering node types. The sling-jcr-contentloader bundle provides loading of content from a bundle into the repository and the sling-jcr-base bundle provides node type registration.

+ +

Initial Content Loading

+ +

Bundles can provide initial content, which is loaded into the repository when the bundle has entered the started state. Such content is expected to be contained in the bundles accessible through the Bundle entry API methods. Content to be loaded is declared in the Sling-Initial-Content bundle manifest header. This header takes a comma-separated list of bundle entry paths. Each entry and all its child entries are accessed and entered into starting with the child entries of the listed entries.

+ +

Adding this content preserves the paths of the entries as show in this table, which assumes a Sling-Initial-Content header entry of SLING-INF/content:

+ + + + + + + + + + + + + +

Entry	Repository Path
`SLING-INF/content/home`	`/home`
`SLING-INF/content/content/playground/en/home`	`/content/playground/en/home`

+ +

Bundle entries are installed as follows:

+ + + + + + + + + + + + + +

Entry Type Installation method

Directory Created as a node of type nt:folder unless a content definition file of the same name exists in the same directory as the directory to be installed. Example: A directory SLING-INF/content/dir is installed as node /dir of type nt:folder unless a SLING-INF/content/dir.xml or SLING-INF/content/dir.json file exists which defines the content for the /dir node.

File Unless the file is a content definition file (see below) an nt:file node is created for the file and an nt:resource node is created as its jcr:content child node to take the contents of the bundle file. The properties of the nt:resource node are set from file information as available. If the file is a content definition file, the content is created as defined in the file. See below for the content definition file specification.

Entry Type	Installation method
Directory	Created as a node of type `nt:folder` unless a content definition file of the same name exists in the same directory as the directory to be installed. Example: A directory `SLING-INF/content/dir` is installed as node `/dir` of type `nt:folder` unless a `SLING-INF/content/dir.xml` or `SLING-INF/content/dir.json` file exists which defines the content for the `/dir` node.
File	Unless the file is a content definition file (see below) an `nt:file` node is created for the file and an `nt:resource` node is created as its `jcr:content` child node to take the contents of the bundle file. The properties of the `nt:resource` node are set from file information as available. If the file is a content definition file, the content is created as defined in the file. See below for the content definition file specification.

+ +

It is possible to modify the intial content loading default behaviour by using certain optional directives. Directives should be specified separated by semicolon. They are defined as follows:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Directive	Definition	Default value	Description
`overwrite`	`overwrite:=(true\|false)`	`false`	The overwrite directive specifies if content nodes should be overwritten or just initially added. If this is true, existing nodes are deleted and a new node is created in the same place.
`overwriteProperties`	`overwriteProperties:=(true\|false)`	`false`	The overwriteProperties directive specifying if content properties should be overwritten or just initially added.
`uninstall`	`uninstall:=(true\|false)`	`overwrite`	The uninstall directive specifies if content should be uninstalled when bundle is unregistered. This value defaults to the value of the `overwrite` directive.
`path`	`path:=/target/location`	`/`	The path directive specifies the target node where initial content will be loaded. If the path does not exist yet in the repository, it is created by the content loader. The intermediate nodes are of type `nt:folder`.
`checkin`	`checkin:=(true\|false)`	`false`	The checkin directive specifies whether versionable nodes should be checked in.
`ignoreImportProviders`	`ignoreImportProviders:=list of extensions`	`empty`	This directive can be used to not run one of the configured extractors (see below).

+ +

Examples of these directives uses could be (assumes a Sling-Initial-Content header entry of SLING-INF/content):

+ + + + + + + + + + + + + + + + + + + + + +

Entry	Behaviour
`SLING-INF/content/home;overwrite:=true;uninstall:=true`	Overwrites already existing content in /home and uninstalls the content when the bundle is unregistered.
`SLING-INF/content/home;overwriteProperties:=true`	Overwrites properties of existing content in /home.
`SLING-INF/content/home;path:=/sites/sling_website`	if /sites/sling_website exists it loads the content into it. Otherwise, it loads the content into root node /.
`SLING-INF/content/home;checkin:=true`	After content loading, versionable nodes are checked in.

+ + +

Loading initial content from bundles

+ +

Repository items to be loaded into the repository, when the bundle is first installed, may be defined in four ways:

Directories
Files
XML descriptor files
JSON descriptor files

+ + +

Depending on the bundle entry found in the location indicated by the Sling-Initial-Content bundle manifest header, nodes are created (and/or updated) as follows:

+ +

Directories

+ +

Unless a node with the name of the directory already exists or has been defined in an XML or JSON descriptor file (see below) a directory is created as a node with the primary node type "nt:folder" in the repository.

+ +

Files

+ +

Unless a node with the name of the file already exists or has been defined in an XML or JSON descriptor file (see below) a file is created as two nodes in the repository. The node bearing the name of the file itself is created with the
+primary node type "nt:file". Underneath this file node, a resource node with the primary node type "nt:resource" is created, which is set to the contents of the file.

+ +

The MIME type is derived from the file name extension by first trying to resolve it from the Bundle entry URL. If this does not resolve to a MIME type, the Sling MIME type resolution service is used to try to find a mime type. If all fals, the MIME type is defaulted to "application/octet-stream".

+ +

XML Descriptor Files

+ +

Nodes, Properties and in fact complete subtrees may be described in XML files using either the JCR SystemView format, or the format described below. In either case, the file must have the .xml extension.

+<node>
+		<!--
+			optional on top level, defaults to XML file name without .xml extension
+	       	required for child nodes
+		-->
+		<name>xyz</name>
+
+		<!--
+	   		optional, defaults to nt:unstructured
+		-->
+		<primaryNodeType>nt:file</primaryNodeType>
+
+		<!--
+		    optional mixin node type
+		    may be repeated for multiple mixin node types
+		-->
+		<mixinNodeType>mix:versionable</mixinNodeType>
+		<mixinNodeType>mix:lockable</mixinNodeType>
+
+		<!--
+			Optional properties for the node. Each <property> element defines
+			a single property of the node. The element may be repeated.
+		-->
+		<property>
+			<!--
+				required property name
+			-->
+			<name>prop</name>
+
+			<!--
+				value of the property.
+				For multi-value properties, the values are defined by multiple
+				<value> elements nested inside a <values> element instead of a
+				single <value> element
+			-->
+			<value>property value as string</value>
+
+			<!--
+				Optional type of the property value, defaults to String.
+				This must be one of the property type strings defined in the
+				JCR PropertyType interface.
+			<type>String</type>
+		</property>
+
+		<!--
+			Additional child nodes. May be further nested.
+		-->
+		<node>
+		....
+		</node>
+	</node>
+

+ +

Using a custom XML format

By writing an XSLT stylesheet file, you can use whatever XML format you prefer. The XML file references an XSLT stylesheet by using the xml-stylesheet processing instruction:

+<?xml version="1.0" encoding="UTF-8"?>
+<?xml-stylesheet href="my-transform.xsl" type="text/xsl"?> <!-- The path to my-transform.xsl is relative to this file -->
+
+<your_custom_root_node>
+   <your_custom_element>
+   ...
+   </your_custom_element>
+...
+</your_custom_root_node>
+

+ +

The my-transform.xsl file is then responsible for translating your format into one of the supported XML formats:

+ +

+
+<xsl:stylesheet version="1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:mix="http://www.jcp.org/jcr/mix/1.0" 
+  xmlns:sv="http://www.jcp.org/jcr/sv/1.0" xmlns:sling="http://sling.apache.org/jcr/sling/1.0"
+  xmlns:rep="internal" xmlns:nt="http://www.jcp.org/jcr/nt/1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
+
+  <xsl:template match="your_custom_element">
+    <node>
+      ...
+    </node>
+  </xsl:template>
+  ...
+</xsl:stylesheet>
+
+

+ +

JSON Descriptor Files

+ +

Nodes, Properties and in fact complete subtrees may be described in JSON files using the following skeleton structure (see http://www.json.org or information on the syntax of JSON) :

+{
+		// optional node name on top level, default is file name without .json ext.
+		"name": "nodename",
+
+		// optional primary node type, default "nt:unstructured"
+		"primaryNodeType": "sling:ScriptedComponent",
+
+		// optional mixin node types as array
+		"mixinNodeTypes": [ ],
+
+	    // the "properties" property is an object indexed by property name whose
+	    // value is either the string property value, array for multi-values or
+	    // an object whose value[s] property denotes the property value(s) and
+	    // whose type property denotes the property type
+	    "properties": {
+	    	"sling:contentClass": "com.day.sling.jcr.test.Test",
+	    	"sampleMulti": [ "v1", "v2" ],
+	    	"sampleStruct": {
+	    		"value": 1,
+	    		"type": "Long"
+	    	}
+	    	"sampleStructMulti": {
+	    		"value": [ 1, 2, 3 ],
+	    		"type": "Long"
+	    	}
+	    },
+
+	    // the "nodes" property is an array of objects denoting child nodes. Nodes
+	    // may be further nested.
+		"nodes": [
+			{
+				// the name property is required on (nested) child nodes
+	            "name": "sling:scripts",
+
+				"primaryNodeType": "sling:ScriptList",
+
+				"nodes": [
+					{
+						"primaryNodeType": "sling:Script",
+						"properties": {
+							"sling:name": "/test/content/jsp/start.jsp",
+							"sling:type": "jsp",
+							"sling:glob": "*"
+						}
+					}
+				]
+			}
+		]
+	}
+

+ +

Extractors

+ +

By default, the sling-jcr-contentloader bundle tries to extract certain file types during content loading. These include json, xml, zip, and jar files. Therefore all available extractors are used for content processing. However if some files should be put into the repository unextracted, the ignoreImportProviders directive can be used with a comma separated list of extensions that should not be extracted, like ignoreImportProviders:="jar,zip". Please note that the value needs to be put into quotation marks if more than one value is used like in the example.

+ +

Workspace Targetting

+ +

By default, initial content will be loaded into the default workspace. To override this, add a Sling-Initial-Content-Workspace bundle manifest header to specify the manifest. Note that all content from a bundle will be loaded into the same workspace.

+ +

Declared Node Type Registration

+ +

The sling-jcr-base bundle provides low-level repository operations which are at the heart of the functionality of Sling:

Node Type Definitions - The class org.apache.sling.content.jcr.base.NodeTypeLoader provides methods to register custom node types with a repository given a repository session and a node type definition file in CND format. This class is also used by this bundle to register node types on behalf of other bundles.

+ + +

Bundles may list node type definition files in CND format in the Sling-Nodetypes bundle header. This header is a comma-separated list of resources in the respective bundle. Each resource is taken and fed to the NodeTypeLoader to define the node types.

+ +

After a bundle has entered the resolved state, the node types listed in the Sling-Nodetypes bundle header are registered with the repository.

+ +

Node types installed by this mechanism will never be removed again by the sling-jcr-base bundle.

+ +

Starting with revision 911430, re-registration of existing node types is enabled by default. To disable this, add ;rereigster:=false to the resource names for which re-registration should be disabled.

+ +

Support for re-registration of node types is relatively limited. In Jackrabbit, for example, only "trivial" changes are allowed.

+ +

Automated tests

+ +

The initial content found in the sling-test folder of the launchpad initial content is verified by the InitialContentTest when running the launchpad/testing integration tests.

+ +

Those tests can be used as verified examples of initial content loading. Contributions are welcome to improve the coverage of those tests.

+Last modified by edn on 2010-08-06 18:34:46.0 +

+Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners. +

+ + + Added: websites/staging/sling/trunk/content/site/content-loading.html ============================================================================== --- websites/staging/sling/trunk/content/site/content-loading.html (added) +++ websites/staging/sling/trunk/content/site/content-loading.html Wed Dec 12 09:16:44 2012 @@ -0,0 +1,192 @@ + + + + + Apache Sling - Content Loading + + + + + +

+ +

+Apache Sling Website > Apache Sling > Advanced Topics > Content Loading +

Content Loading and Nodetype Support

+ +

+ + +

Declared Node Type Registration

+ +

The sling-jcr-base bundle provides low-level repository operations which are at the heart of the functionality of Sling:

Node Type Definitions - The class org.apache.sling.content.jcr.base.NodeTypeLoader provides methods to register custom node types with a repository given a repository session and a node type definition file in CND format. This class is also used by this bundle to register node types on behalf of other bundles.

+ + +

+ +

After a bundle has entered the resolved state, the node types listed in the Sling-Nodetypes bundle header are registered with the repository.

+ +

Node types installed by this mechanism will never be removed again by the sling-jcr-base bundle. Likewise, registered node types cannot currently be modified using this feature. The NodeTypeLoader will try to load nodes defined and fail with a log message if a node type has already been defined. To update existing node type definitions, native repository functionality has to be used.

+ +

Nodetype management is currently a problematic issue, as the only API available is contained in the Jackrabbit Core library, which is generally not available to client applications - unless running in the same VM and class loader hierarchy as the Repository. Version 2 of the JCR Specification currently being developped as JSR-283 should fix this issue by providing an official node type management API. Until then, this approach is about the only solution we have.

+ +

Initial Content Loading

+ +

Adding this content preserves the paths of the entries as show in this table, which assumes a Sling-Initial-Content header entry of SLING-INF/content:

+ + + + + + + + + + + + + +

Entry	Repository Path
`SLING-INF/content/home`	`/home`
`SLING-INF/content/content/playground/en/home`	`/content/playground/en/home`

Bundle entries are installed as follows:

+ + + + + + + + + + + + + +

Entry Type Installation method

Entry Type	Installation method
Directory	Created as a node of type `nt:folder` unless a content definition file of the same name exists in the same directory as the directory to be installed. Example: A directory `SLING-INF/content/dir` is installed as node `/dir` of type `nt:folder` unless a `SLING-INF/content/dir.xml` or `SLING-INF/content/dir.json` file exists which defines the content for the `/dir` node.
File	Unless the file is a content definition file (see below) an `nt:file` node is created for the file and an `nt:resource` node is created as its `jcr:content` child node to take the contents of the bundle file. The properties of the `nt:resource` node are set from file information as available. If the file is a content definition file, the content is created as defined in the file. See below for the content definition file specification.

It is possible to modify the intial content loading default behaviour by using certain optional directives. Directives should be specified separated by semicolon. They are defined as follows:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Directive	Definition	Default value	Description
`overwrite`	`overwrite:=(true\|false)`	`false`	The overwrite directive specifies if content should be overwritten or just initially added.
`uninstall`	`uninstall:=(true\|false)`	`overwrite`	The uninstall directive specifies if content should be uninstalled when bundle is unregistered. This value defaults to the value of the `overwrite` directive.
`path`	`path:=/target/location`	`/`	The path directive specifies the target node where initial content will be loaded. If the path does not exist yet in the repository, it is created by the content loader. The intermediate nodes are of type `nt:folder`.
`checkin`	`checkin:=(true\|false)`	`false`	The checkin directive specifies whether versionable nodes should be checked in.
`ignoreImportProviders`	`ignoreImportProviders:=list of extensions`	`empty`	This directive can be used to not run one of the configured extractors (see below).

Examples of these directives uses could be (assumes a Sling-Initial-Content header entry of SLING-INF/content):

+ + + + + + + + + + + + + + + + + +

Entry	Behaviour
`SLING-INF/content/home;overwrite:=true;uninstall:=true`	Overwrites already existing content in /home and uninstalls the content when the bundle is unregistered.
`SLING-INF/content/home;path:=/sites/sling_website`	if /sites/sling_website exists it loads the content into it. Otherwise, it loads the content into root node /.
`SLING-INF/content/home;checkin:=true`	After content loading, versionable nodes are checked in.

+ +

Extractors

+ +

Content Definition File Specification

+ +

Structured content may be specified in content specification file in JSON or XML format which define subtrees of content. A content definition file contains the definition of a single node with optional properties and child nodes. Each child node may again have its properties and child nodes. The definition of a node is as follows:

+ +

JSON

... *TODO* ...
+

XML

... *TODO* ...
+

+ +

Automated tests

The initial content found in the sling-test folder of the launchpad initial content is verified by the InitialContentTest when running the launchpad/testing integration tests.

+ +

Those tests can be used as verified examples of initial content loading. Contributions are welcome to improve the coverage of those tests.

+Last modified by bdelacretaz on Fri May 15 22:41:03 PDT 2009 +

+ + + Added: websites/staging/sling/trunk/content/site/contributing.html ============================================================================== --- websites/staging/sling/trunk/content/site/contributing.html (added) +++ websites/staging/sling/trunk/content/site/contributing.html Wed Dec 12 09:16:44 2012 @@ -0,0 +1,91 @@ + + + + + Apache Sling - Contributing + + + + + +

+ +

+Apache Sling Website > Apache Sling > Contributing +

Contributing

+ +

See Project Information for details about the tools mentioned below.

+ +

Apache Sling is a volunteer effort, so there is always plenty of work that needs to be accomplished. If you want to help support Sling, this page is intended as a starting point for specific contribution ideas. To further understand how the Sling community operates, refer to the Community Roles and Processes document and/or join the mailing lists.

+ +

The Sling project organizes its "to do" list using the JIRA issue tracking system. Specific items from Sling's JIRA issue tracking system are highlighted on this page, but are not limited to it. The purpose of the list here is to highlight issues that are either more important or serve as good entry points for new contributors.

+ +

It is important to point out that you do not need to be a programmer to contribute to Sling. As such, we will break out the list of issues below for non-programmers and programmers.

+ +

Non-Programmers

+ +

Improve web site or documentation (e.g., create/propose FAQ entries). There is no specific JIRA issue for this task, but any contributions could be posted as new JIRA issues for the Documentation component.

+ + +

Programmers

+ +

Implement support for various rendering technologies in Sling. Examples coming to mind are JSF and Wicket.

+ +

+Last modified by bdelacretaz on 2010-04-30 03:10:58.0 +

+ + + Added: websites/staging/sling/trunk/content/site/default-mapping-and-rendering.html ============================================================================== --- websites/staging/sling/trunk/content/site/default-mapping-and-rendering.html (added) +++ websites/staging/sling/trunk/content/site/default-mapping-and-rendering.html Wed Dec 12 09:16:44 2012 @@ -0,0 +1,69 @@ + + + + + Apache Sling - Default Mapping and Rendering + + + + + +

+ +

+Apache Sling Website > Apache Sling > Documentation > The Sling Engine > Default Mapping and Rendering +

This page contained obsolete content, moved it to http://cwiki.apache.org/confluence/display/SLING/Default+Mapping+and+Rendering+%28OBSOLETE%29 in case it is useful to someone.

+Last modified by bdelacretaz on 2010-02-04 10:52:37.0 +

+ + + Added: websites/staging/sling/trunk/content/site/dependency-management.html ============================================================================== --- websites/staging/sling/trunk/content/site/dependency-management.html (added) +++ websites/staging/sling/trunk/content/site/dependency-management.html Wed Dec 12 09:16:44 2012 @@ -0,0 +1,187 @@ + + + + + Apache Sling - Dependency Management + + + + + +

+ +

+Apache Sling Website > Apache Sling > Documentation > Development > Dependency Management +

Dependency Management

+ +

This page is about how we do and don't do dependency management in the Sling project.

+ +

Introduction
Dependency Management
References

+ +

Introduction

+ +

Maven provides projects with a nice feature called dependency management. In Sling we currently use this feature to declare the non-Sling dependencies of modules in the parent POM.

+ +

After working with this some time and trying to upgrade various dependencies we came to the conclusion, that using Maven dependency management is not going to work out in the Sling scenario.

+ +

Why ? Maven's dependency management is aimed at traditional applicaitons, which are glued together statically during the build process. For this environment, dependency management is a great thing, since it guarantees a consistent application setup.

+ +

In a dynamic application setup as provided by an OSGi framework the static dependency management of Maven does not help. Actually it even causes problematic results with respect to backwards compatibility when using the Maven Bundle plugin.

+ +

Why's that ? The Maven Bundle plugin is constructs the bundle manifest and will generally automatically create the Import-Package header. If the providing library (from maven's dependency list) has Export-Package headers with version numbers, the Maven Bundle plugin will insert the respective version numbers for the Import-Package header. This makes perfect sense, because it is expected, that the artifact required at least the given package version.

+ +

When using Maven dependency management, upgrading any dependencies in the parent POM may automatically increse the version numbers in the Import-Package headers and hence may cause any such bundle to fail resolution if deployed - even though the bundle did not change and does not really require a new version of the dependency.

+ +

So, in the case of OSGi deployment, Maven's dependency management actually interferes with the OSGi framework dependency management.

+ +

As a consequence, I suggest we drop dependency management in the parent pom (almost) completely and state the followin.

+ + +

Dependency Management

+ + +

The parent pom only does dependency management for build time dependencies and a very limited number of API dependencies used Sling wide. These dependencies are:

+ +

All plugin dependencies. That is PluginManagement is still used. Maven plugins are actualy build time dependencies and therefore have no influence on the actual deployment.
Dependencies on commonly used testing environment helpers. Test helper classes are also build time dependencies used to run the unit and integration tests. As such, they may well be managed.
Sling makes a small number of assumptions about the environment, which we codify in the dependency management: The minimum version number of the OSGi specificaiton used, the servlet API version and the JCR API version.

+ + +

The <DependencyManagement> element currently contains the following managed dependencies:

+ +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Group ID	Artifact ID	Version	Scope
org.apache.felix	org.osgi.core	1.2.0	provided
org.apache.felix	org.osgi.compendium	1.2.0	provided
javax.servlet	servlet-api	2.4	provided
javax.jcr	jcr	1.0	provided
org.slf4j	slf4j-api	1.5.2	provided
junit	junit	4.3	test
org.jmock	jmock-junit4	2.2.0	test
org.slf4j	slf4j-simple	1.5.2	test

+ + + +

All dependencies per module are fully described in terms of version, scope, and classifier by the respective project.

+ +

The version of the module dependency should be selected according to the following rule: The lowest version providing the functionality required by the module (or bundle). By required functionality we bascially mean provided API.

+ +

Generally there is a constant flow of releases of dependent libraries. In general this should not cause the dependency version number of a using module to be increased. There is one exception though: If the fixed library version contains a bug fix, which has an influence on the operation of the module, an increase in the version number is indicated and should also be applied.

+ + +

References

+ +

Dependency ManagementLink to this message – Discussion thread about reducing Maven 2 DependencyManagement
SLING-811 – The actual issue governing the changes to the project descriptors

+ +

+Last modified by fmeschbe on 2009-04-07 07:01:55.0 +

+ + + Added: websites/staging/sling/trunk/content/site/development.html ============================================================================== --- websites/staging/sling/trunk/content/site/development.html (added) +++ websites/staging/sling/trunk/content/site/development.html Wed Dec 12 09:16:44 2012 @@ -0,0 +1,114 @@ + + + + + Apache Sling - Development + + + + + +

+ +

+Apache Sling Website > Apache Sling > Documentation > Development +

Development

+ +

Welcome to the wonderful world of extending Sling. Refer to these pages to find out how we envision the extension of Sling and how to do it.

+ + +

Using Sling as your Development Framework

+ +

Look here for more information on developper support when your are using Sling to build your own applications.

+ +

+ + + +

Maven 2 stuff

+ +

Sling is using Apache Maven as it build system. Over time we have created a number of Maven 2 Plugins and gathered a whole range of knowledge about using Maven.

+ +

+ + + +

Sling Development

+ +

Last but not least, here is some more information on how we ourselves are working on Sling

+ +

+Last modified by fmeschbe on 2011-09-04 04:46:52.0 +

+ + +