Author: fchrist
Date: Wed Jun 6 12:38:53 2012
New Revision: 1346852
URL: http://svn.apache.org/viewvc?rev=1346852&view=rev
Log:
STANBOL-657 Linked website docs. Refactored structure of development docs
Added:
incubator/stanbol/site/trunk/content/stanbol/development/coding.mdtext
incubator/stanbol/site/trunk/content/stanbol/development/dependency-management.mdtext
incubator/stanbol/site/trunk/content/stanbol/development/release-management.mdtext
Modified:
incubator/stanbol/site/trunk/content/stanbol/development/index.mdtext
incubator/stanbol/site/trunk/content/stanbol/development/website.mdtext
Added: incubator/stanbol/site/trunk/content/stanbol/development/coding.mdtext
URL:
http://svn.apache.org/viewvc/incubator/stanbol/site/trunk/content/stanbol/development/coding.mdtext?rev=1346852&view=auto
==============================================================================
--- incubator/stanbol/site/trunk/content/stanbol/development/coding.mdtext
(added)
+++ incubator/stanbol/site/trunk/content/stanbol/development/coding.mdtext Wed
Jun 6 12:38:53 2012
@@ -0,0 +1,40 @@
+Title: Coding
+
+### Code Conventions
+
+Most developers of Apache Stanbol use the Eclipse IDE for development. The
+code conventions for this IDE can be imported from the
+'/conventions/stanbol-eclipse-codeformatter.xml' file
+[in SVN](http://svn.apache.org/repos/asf/incubator/stanbol/trunk/conventions/).
+
+### SVN Structure
+
+The Apache Stanbol [SVN](http://svn.apache.org/repos/asf/incubator/stanbol/)
+is divided into the classical trio of
+
+ * trunk: where the main development takes place
+ * branches: used for release branching and to implement prove of concepts
+ that are not yet ready to be part of the trunk
+ * tags: used for tagging releases, i.e. stable version of Apache Stanbol
+
+Additionally, there is the 'site' directory in the SVN. This holds the
+sources of the website you are currently reading. Apache Stanbol uses the
+[ASF CMS](https://blogs.apache.org/infra/entry/the_asf_cms) to create
+and maintain its website.
+
+### Legal Issues
+
+The Apache Stanbol software is released under the Apache Software License
+(AL). Therefore, we have to ensure that our software is developed according
+to this license. Here is a short list of the most important rules every
+developer has to keep in mind when writing this software.
+
+ * Ideally, each file in SVN should have the Apache license header. This is
+ especially important for each source (*.java) file. This rule is checked
+ automatically before doing a release using the Apache RAT tool.
+ * The licenses of all dependencies that are used by Apache Stanbol must
+ be compatible with the AL.
+ * All dependencies used by Apache Stanbol should be available from the
+ Maven central repository. If this is not the case, the Apache Stanbol
+ module depending on a libraray that is not available from Maven
+ central can not be released that easy, i.e. a separate -deps package would
be required.
Added:
incubator/stanbol/site/trunk/content/stanbol/development/dependency-management.mdtext
URL:
http://svn.apache.org/viewvc/incubator/stanbol/site/trunk/content/stanbol/development/dependency-management.mdtext?rev=1346852&view=auto
==============================================================================
---
incubator/stanbol/site/trunk/content/stanbol/development/dependency-management.mdtext
(added)
+++
incubator/stanbol/site/trunk/content/stanbol/development/dependency-management.mdtext
Wed Jun 6 12:38:53 2012
@@ -0,0 +1,99 @@
+Title: Dependency Management
+
+Apache Stanbol is a modular software stack. Technically, this modularization
+is implemented by the underlying OSGi component infrastructure. Each Apache
+Stanbol component is implemented as an OSGi bundle that can be deployed in
+an OSGi environment. Apache Stanbol uses the OSGi implementation from
+[Apache Felix](http://felix.apache.org/site/index.html) for this.
+
+Apache Stanbol's dependency management is organized at three levels:
+
+ 1. [Build Dependency Management](#build-dependency-management)
+ 2. [Runtime (OSGi) Dependency Management](#runtime-dependency-management)
+ 3. [Launcher Configuration Management](#launcher-configuration-management)
+
+<a name="build-dependency-management"></a>
+### Build Dependency Management
+
+Build dependencies are configured in the Apache Maven pom.xml (POM) files.
+We distinguish between internal and external dependencies.
+
+ * Internal dependencies are dependencies to other org.apache.stanbol.*
+ components.
+ * External dependencies are dependencies to third party components from
+ outside the Apache Stanbol project.
+
+Internal dependencies are managed separatly for each component. So each
+component defines in its own POM which other Apache Stanbol components in
+which versions it requires. This makes it possible that different components
+could rely on different versions of another Apache Stanbol component.
+This is a requirement to be able to release single Apache Stanbol
+components independently.
+
+External dependencies to third party components are managed at a central
+place to ensure that all Apache Stanbol components rely on the very same
+version of a third party component. The central configuration for this can
+be found in the dependency management section of the Apache Stanbol
+[parent
POM](http://svn.apache.org/repos/asf/incubator/stanbol/trunk/parent/pom.xml).
+As all Apache Stanbol components define this central POM as their parent,
+it is ensured that all components use the same version of an
+external dependency. Changing the version of an external dependency in the
+parent POM affects all Apache Stanbol components that rely on this
+dependency.
+
+In consequence it is not allowed that Apache Stanbol components define their
+own version of an external dependency in their POM. External dependencies
+are configured in the parent POM only! If there is any Apache Stanbol
+component that does not apply to this rule, it should
+be considered as a bug or a good reason for this should be documented.
+Relying on the same version of external dependencies is essential to ensure
+a working Apache Stanbol stack.
+
+<a name="runtime-dependency-management"></a>
+### Runtime (OSGi) Dependency Management
+
+Apache Stanbol components are OSGi bundles. Therefore, the runtime
+dependencies between such bundles are managed by the exported and imported
+packages of those bundles. What a bundle requires to import and what it
+exports is configured by using the Maven Bundle plugin of the Apache Felix
+project. Its configuration is done inside the POM. The Maven Bundle plugin
+ensures that the OSGi specific meta-information are generated correctly
+for the resulting JAR.
+
+Configuring the OSGi imports and exports is in most cases analogue to
+configure the build dependencies in the POM. We can not go into the details
+of OSGi here and refer to the
+[OSGi Alliance](http://www.osgi.org/) and the
+[Apache Felix](http://felix.apache.org/site/index.html) project
+for further information.
+
+<a name="launcher-configuration-management"></a>
+### Launcher Configuration Management
+
+Launchers represent the binary distribution of Apache Stanbol. An Apache
+Stanbol launcher is a packaged OSGi runtime environment. It includes a set
+of Apache Stanbol components and required third party components to build up
+the runtime stack. Additionally, a launcher instantiates an Apache Stanbol
+HTTP endpoint to provide the RESTful interface and documentation.
+
+Basically, a launcher packages everything together in a single executable
+JAR that is needed to run Apache Stanbol. To configure which bundles are
+part of this launcher and to ensure that all required third party components
+are in place, the launchers are composed of so called 'partial bundlelists'.
+
+A partial bundlelist is defined by each Apache Stanbol component and it lists
+all required internal and external dependencies that have to be included in a
+launcher in order to make this component work. The dependencies are
+configured in a 'src/main/bundles/list.xml' file of each partial bundlelist
+artifact. The dependencies listed in such a file of a partial bundlelist
+are more or less the same as the ones defined for the build dependencies in
+the POM. But remember that the partial bundlelists define the dependencies
+needed at runtime and there may be other/more dependencies needed at runtime
+than at build time.
+
+Apache Stanbol pre-configures a set of launchers in the
+[/launchers](http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/)
directory.
+The most important one is the 'full' launcher which includes all available
+Apache Stanbol components. This launcher is also used when executing the
+integration tests. In a launcher's POM you just have to declare dependencies
+to all required partial bundlelists that the launcher should include.
Modified: incubator/stanbol/site/trunk/content/stanbol/development/index.mdtext
URL:
http://svn.apache.org/viewvc/incubator/stanbol/site/trunk/content/stanbol/development/index.mdtext?rev=1346852&r1=1346851&r2=1346852&view=diff
==============================================================================
--- incubator/stanbol/site/trunk/content/stanbol/development/index.mdtext
(original)
+++ incubator/stanbol/site/trunk/content/stanbol/development/index.mdtext Wed
Jun 6 12:38:53 2012
@@ -3,249 +3,18 @@ Title: Development
This site documents development related issues when working with the
Apache Stanbol source code and contributing to it.
- * [Dependency Management](#dependency-management)
- * [Coding](#coding)
- * [Release Management](#release-management)
-
-<a name="dependency-management"></a>
-## Dependency Management
-
-Apache Stanbol is a modular software stack. Technically, this modularization
-is implemented by the underlying OSGi component infrastructure. Each Apache
-Stanbol component is implemented as an OSGi bundle that can be deployed in
-an OSGi environment. Apache Stanbol uses the OSGi implementation from
-[Apache Felix](http://felix.apache.org/site/index.html) for this.
-
-Apache Stanbol's dependency management is organized at three levels:
-
- 1. [Build Dependency Management](#build-dependency-management)
- 2. [Runtime (OSGi) Dependency Management](#runtime-dependency-management)
- 3. [Launcher Configuration Management](#launcher-configuration-management)
-
-<a name="build-dependency-management"></a>
-### Build Dependency Management
-
-Build dependencies are configured in the Apache Maven pom.xml (POM) files.
-We distinguish between internal and external dependencies.
-
- * Internal dependencies are dependencies to other org.apache.stanbol.*
- components.
- * External dependencies are dependencies to third party components from
- outside the Apache Stanbol project.
-
-Internal dependencies are managed separatly for each component. So each
-component defines in its own POM which other Apache Stanbol components in
-which versions it requires. This makes it possible that different components
-could rely on different versions of another Apache Stanbol component.
-This is a requirement to be able to release single Apache Stanbol
-components independently.
-
-External dependencies to third party components are managed at a central
-place to ensure that all Apache Stanbol components rely on the very same
-version of a third party component. The central configuration for this can
-be found in the dependency management section of the Apache Stanbol
-[parent
POM](http://svn.apache.org/repos/asf/incubator/stanbol/trunk/parent/pom.xml).
-As all Apache Stanbol components define this central POM as their parent,
-it is ensured that all components use the same version of an
-external dependency. Changing the version of an external dependency in the
-parent POM affects all Apache Stanbol components that rely on this
-dependency.
-
-In consequence it is not allowed that Apache Stanbol components define their
-own version of an external dependency in their POM. External dependencies
-are configured in the parent POM only! If there is any Apache Stanbol
-component that does not apply to this rule, it should
-be considered as a bug or a good reason for this should be documented.
-Relying on the same version of external dependencies is essential to ensure
-a working Apache Stanbol stack.
-
-<a name="runtime-dependency-management"></a>
-### Runtime (OSGi) Dependency Management
-
-Apache Stanbol components are OSGi bundles. Therefore, the runtime
-dependencies between such bundles are managed by the exported and imported
-packages of those bundles. What a bundle requires to import and what it
-exports is configured by using the Maven Bundle plugin of the Apache Felix
-project. Its configuration is done inside the POM. The Maven Bundle plugin
-ensures that the OSGi specific meta-information are generated correctly
-for the resulting JAR.
-
-Configuring the OSGi imports and exports is in most cases analogue to
-configure the build dependencies in the POM. We can not go into the details
-of OSGi here and refer to the
-[OSGi Alliance](http://www.osgi.org/) and the
-[Apache Felix](http://felix.apache.org/site/index.html) project
-for further information.
-
-<a name="launcher-configuration-management"></a>
-### Launcher Configuration Management
-
-Launchers represent the binary distribution of Apache Stanbol. An Apache
-Stanbol launcher is a packaged OSGi runtime environment. It includes a set
-of Apache Stanbol components and required third party components to build up
-the runtime stack. Additionally, a launcher instantiates an Apache Stanbol
-HTTP endpoint to provide the RESTful interface and documentation.
-
-Basically, a launcher packages everything together in a single executable
-JAR that is needed to run Apache Stanbol. To configure which bundles are
-part of this launcher and to ensure that all required third party components
-are in place, the launchers are composed of so called 'partial bundlelists'.
-
-A partial bundlelist is defined by each Apache Stanbol component and it lists
-all required internal and external dependencies that have to be included in a
-launcher in order to make this component work. The dependencies are
-configured in a 'src/main/bundles/list.xml' file of each partial bundlelist
-artifact. The dependencies listed in such a file of a partial bundlelist
-are more or less the same as the ones defined for the build dependencies in
-the POM. But remember that the partial bundlelists define the dependencies
-needed at runtime and there may be other/more dependencies needed at runtime
-than at build time.
-
-Apache Stanbol pre-configures a set of launchers in the
-[/launchers](http://svn.apache.org/repos/asf/incubator/stanbol/trunk/launchers/)
directory.
-The most important one is the 'full' launcher which includes all available
-Apache Stanbol components. This launcher is also used when executing the
-integration tests. In a launcher's POM you just have to declare dependencies
-to all required partial bundlelists that the launcher should include.
-
-<a name="coding"></a>
-## Coding
-
-### Code Conventions
-
-Most developers of Apache Stanbol use the Eclipse IDE for development. The
-code conventions for this IDE can be imported from the
-'/conventions/stanbol-eclipse-codeformatter.xml' file
-[in SVN](http://svn.apache.org/repos/asf/incubator/stanbol/trunk/conventions/).
-
-### SVN Structure
-
-The Apache Stanbol [SVN](http://svn.apache.org/repos/asf/incubator/stanbol/)
-is divided into the classical trio of
-
- * trunk: where the main development takes place
- * branches: used for release branching and to implement prove of concepts
- that are not yet ready to be part of the trunk
- * tags: used for tagging releases, i.e. stable version of Apache Stanbol
-
-Additionally, there is the 'site' directory in the SVN. This holds the
-sources of the website you are currently reading. Apache Stanbol uses the
-[ASF CMS](https://blogs.apache.org/infra/entry/the_asf_cms) to create
-and maintain its website.
-
-### Legal Issues
-
-The Apache Stanbol software is released under the Apache Software License
-(AL). Therefore, we have to ensure that our software is developed according
-to this license. Here is a short list of the most important rules every
-developer has to keep in mind when writing this software.
-
- * Ideally, each file in SVN should have the Apache license header. This is
- especially important for each source (*.java) file. This rule is checked
- automatically before doing a release using the Apache RAT tool.
- * The licenses of all dependencies that are used by Apache Stanbol must
- be compatible with the AL.
- * All dependencies used by Apache Stanbol should be available from the
- Maven central repository. If this is not the case, the Apache Stanbol
- module depending on a libraray that is not available from Maven
- central can not be released that easy, i.e. a separate -deps package would
be required.
-
-
-<a name="release-management"></a>
-## Release Process
-
-Before you do any release related action, you should definitely read the
-[release sections](http://www.apache.org/dev/#releases) on the Apache
-website and the
-[incubator release management
pages](http://incubator.apache.org/guides/releasemanagement.html).
-
-The Apache Stanbol release management process is very similar to the one
-followed by the [Apache Sling](http://sling.apache.org/) project. Their
-[release management
documentation](http://sling.apache.org/site/release-management.html)
-is a must read for Apache Stanbol committers.
-
-Apache Stanbol is a modular software stack and therefore all of its modules
-basically have different release cycles. So each component of Apache Stanbol
-may be released independently of others. The only requirement is, that a
-released Apache Stanbol component may not have any SNAPSHOT dependencies to
-any other component it depends on.
-
-To release a single component, Apache Stanbol makes use the
-[Maven Release plugin](http://maven.apache.org/plugins/maven-release-plugin/).
-This plugin takes care of checking that there are no SNAPSHOT
-dependencies left. Additionally, there are some checks for legal issues
-automatically performed using the
-[Apache RAT](http://incubator.apache.org/rat/) Maven plugin.
-
-To do a release test build, you have to activate the 'apache-release'
-profile, like it is done in this command:
-
- $ mvn install -Papache-release
-
-The 'apache-release' profile will be automatically activated when the Maven
Release plugin is used. For staging an official release with signing the
-released artifact, making SVN tags, and uploading the artifact to the
-staging repository, you start with
-
- $ mvn release:prepare -DpreparationGoals=clean install
-DscmCommentPrefix=STANBOL-XXX:
-
-Please, replace the XXX with the corresponding Jira issue number. After the
release was prepared and tags created, the release has to be staged. This is
done by executing the following command.
-
- $ mvn release:perform -DreleaseProfiles=apache-release
-DscmCommentPrefix=STANBOL-XXX:
-
-For further information we refer to the
-[Apache Sling](http://sling.apache.org)
-website and their very good
-[documentation](http://sling.apache.org/site/release-management.html)
-of doing a release.
-
-## Tips & Tricks
-
-Here are some tips and tricks of commands that are useful, e.g. when examing
the
-code base before a release.
-
-### Determine SNAPSHOT dependencies
-
-If you want to release a component, e.g. the Entity Hub, you have to know all
-used SNAPSHOT dependencies. We are especially interested in internal
dependencies
-to other Apache Stanbol components. On a Unix system something like this could
-be used:
-
- $ mvn dependency:tree | grep \\-SNAPSHOT | sed s/.*org/org/ | sort -u
-
-### Update version of parent POM
-
-The parent POM got released and now we have to update to the new version in
-all artifacts. The
-[Versions Maven
Plugin](http://www.java.net/external?url=http://mojo.codehaus.org/versions-maven-plugin/)
-can help here. Is has a separate goal to
-[update the
parent](http://mojo.codehaus.org/versions-maven-plugin/update-parent-mojo.html)
-POM. The plugin searches in the local Maven repository for the latest
available version of the
-parent POM and updates all POMs to this version. When executing this goal the
parent POM itself
-must not be part of the build. So maybe you have to edit the top level reactor
POM first. The
-used command looks as follows.
-
- $ mvn versions:update-parent -DgenerateBackupPoms=false
-DallowSnapshots=true
-
-If you want to update to the latest non-SNAPSHOT version, you have to set
'allowSnapshots'
-to 'false' (default). A backup of the changed POMs is not needed when files
are under
-SVN control. To revert any local changes, you could use
-
- $ svn revert -R *
-
-### Exclude files from check for modifcations
-
-When you use
-
- $ mvn release:prepare
-
-it will check for local modifications. If you want to exclude some files from
this check,
-e.g. a RAT report file named "rat.txt", you can do it like this
+## Software Development
- $ mvn release:prepare -DcheckModificationExcludeList=rat.txt
+The following documents describe the software development practices that are
+followed by the Apache Stanbol project.
-### Change the comment when creating commiting changes
+ * [Dependency Management](dependency-management.html)
+ * [Coding](coding.html)
+ * [Release Management](release-management.html)
-The default commit comment starts with "[maven-release-plugin]" when using the
Maven Release Plugin.
-You can change this and e.g. set it to a Stanbol Jira issue number.
+## Documentation
- $ mvn release:prepare -DscmCommentPrefix=STANBOL-XXX:
+A good documentation is nearly as important as the software itself. Here you
+can find information how to contribute to it.
+
+ * [Website](website.html)
Added:
incubator/stanbol/site/trunk/content/stanbol/development/release-management.mdtext
URL:
http://svn.apache.org/viewvc/incubator/stanbol/site/trunk/content/stanbol/development/release-management.mdtext?rev=1346852&view=auto
==============================================================================
---
incubator/stanbol/site/trunk/content/stanbol/development/release-management.mdtext
(added)
+++
incubator/stanbol/site/trunk/content/stanbol/development/release-management.mdtext
Wed Jun 6 12:38:53 2012
@@ -0,0 +1,97 @@
+Title: Release Management
+
+Before you do any release related action, you should definitely read the
+[release sections](http://www.apache.org/dev/#releases) on the Apache
+website and the
+[incubator release management
pages](http://incubator.apache.org/guides/releasemanagement.html).
+
+The Apache Stanbol release management process is very similar to the one
+followed by the [Apache Sling](http://sling.apache.org/) project. Their
+[release management
documentation](http://sling.apache.org/site/release-management.html)
+is a must read for Apache Stanbol committers.
+
+Apache Stanbol is a modular software stack and therefore all of its modules
+basically have different release cycles. So each component of Apache Stanbol
+may be released independently of others. The only requirement is, that a
+released Apache Stanbol component may not have any SNAPSHOT dependencies to
+any other component it depends on.
+
+To release a single component, Apache Stanbol makes use the
+[Maven Release plugin](http://maven.apache.org/plugins/maven-release-plugin/).
+This plugin takes care of checking that there are no SNAPSHOT
+dependencies left. Additionally, there are some checks for legal issues
+automatically performed using the
+[Apache RAT](http://incubator.apache.org/rat/) Maven plugin.
+
+To do a release test build, you have to activate the 'apache-release'
+profile, like it is done in this command:
+
+ $ mvn install -Papache-release
+
+The 'apache-release' profile will be automatically activated when the Maven
Release plugin is used. For staging an official release with signing the
+released artifact, making SVN tags, and uploading the artifact to the
+staging repository, you start with
+
+ $ mvn release:prepare -DpreparationGoals=clean install
-DscmCommentPrefix=STANBOL-XXX:
+
+Please, replace the XXX with the corresponding Jira issue number. After the
release was prepared and tags created, the release has to be staged. This is
done by executing the following command.
+
+ $ mvn release:perform -DreleaseProfiles=apache-release
-DscmCommentPrefix=STANBOL-XXX:
+
+For further information we refer to the
+[Apache Sling](http://sling.apache.org)
+website and their very good
+[documentation](http://sling.apache.org/site/release-management.html)
+of doing a release.
+
+## Tips & Tricks
+
+Here are some tips and tricks of commands that are useful, e.g. when examing
the
+code base before a release.
+
+### Determine SNAPSHOT dependencies
+
+If you want to release a component, e.g. the Entity Hub, you have to know all
+used SNAPSHOT dependencies. We are especially interested in internal
dependencies
+to other Apache Stanbol components. On a Unix system something like this could
+be used:
+
+ $ mvn dependency:tree | grep \\-SNAPSHOT | sed s/.*org/org/ | sort -u
+
+### Update version of parent POM
+
+The parent POM got released and now we have to update to the new version in
+all artifacts. The
+[Versions Maven
Plugin](http://www.java.net/external?url=http://mojo.codehaus.org/versions-maven-plugin/)
+can help here. Is has a separate goal to
+[update the
parent](http://mojo.codehaus.org/versions-maven-plugin/update-parent-mojo.html)
+POM. The plugin searches in the local Maven repository for the latest
available version of the
+parent POM and updates all POMs to this version. When executing this goal the
parent POM itself
+must not be part of the build. So maybe you have to edit the top level reactor
POM first. The
+used command looks as follows.
+
+ $ mvn versions:update-parent -DgenerateBackupPoms=false
-DallowSnapshots=true
+
+If you want to update to the latest non-SNAPSHOT version, you have to set
'allowSnapshots'
+to 'false' (default). A backup of the changed POMs is not needed when files
are under
+SVN control. To revert any local changes, you could use
+
+ $ svn revert -R *
+
+### Exclude files from check for modifcations
+
+When you use
+
+ $ mvn release:prepare
+
+it will check for local modifications. If you want to exclude some files from
this check,
+e.g. a RAT report file named "rat.txt", you can do it like this
+
+ $ mvn release:prepare -DcheckModificationExcludeList=rat.txt
+
+### Change the comment when creating commiting changes
+
+The default commit comment starts with "[maven-release-plugin]" when using the
Maven Release Plugin.
+You can change this and e.g. set it to a Stanbol Jira issue number.
+
+ $ mvn release:prepare -DscmCommentPrefix=STANBOL-XXX:
Modified:
incubator/stanbol/site/trunk/content/stanbol/development/website.mdtext
URL:
http://svn.apache.org/viewvc/incubator/stanbol/site/trunk/content/stanbol/development/website.mdtext?rev=1346852&r1=1346851&r2=1346852&view=diff
==============================================================================
--- incubator/stanbol/site/trunk/content/stanbol/development/website.mdtext
(original)
+++ incubator/stanbol/site/trunk/content/stanbol/development/website.mdtext Wed
Jun 6 12:38:53 2012
@@ -1,6 +1,8 @@
Title: Website Development
-Apache Stanbol uses the [ASF CMS]() to manage its website. With this approach
+Apache Stanbol uses the
+[ASF CMS](http://www.apache.org/dev/cms.html)
+to manage its website. With this approach
the website sources are hosted in SVN along the software sources. The website
source can be checked out from:
@@ -14,21 +16,21 @@ write HTML.
## How to contribute to the website
We are always trying to improve the available documentation and sources of
-information about Apache Stanbol. To contribute to the website is just as
-easy as to contribute a patch to the software sources.
+information about Apache Stanbol. To contribute to the website is just as easy
+as to contribute a patch to the software sources.
-For your contribution you should first open a new
-[Jira issue](https://issues.apache.org/jira/browse/STANBOL) describing
-your desired changes.
+For your contribution you should first open a new [Jira
+issue](https://issues.apache.org/jira/browse/STANBOL) describing your desired
+changes.
-Then you checkout the current version of the website sources from the SVN
-and make your changes. See the existing content for how to add images and
+Then you checkout the current version of the website sources from the SVN and
+make your changes. See the existing content for how to add images and
additional files.
-When you have finished, you create a patch from your
-changes. Zip your patch and upload it to the issue created prior. A
-committer will catch it up and commit your changes after a short review
-to the SVN. This will trigger the publishing process.
+When you have finished, you create a patch from your changes. Zip your patch
+and upload it to the issue created prior. A committer will catch it up and
+commit your changes after a short review to the SVN. This will trigger the
+publishing process.
## Publishing process
