You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@sling.apache.org by bu...@apache.org on 2012/05/22 10:25:36 UTC
svn commit: r818658 [23/23] - in /websites/staging/sling/trunk/content: ./
tutorials-how-tos/
Modified: websites/staging/sling/trunk/content/version-policy.html
==============================================================================
--- websites/staging/sling/trunk/content/version-policy.html (original)
+++ websites/staging/sling/trunk/content/version-policy.html Tue May 22 08:25:32 2012
@@ -82,30 +82,37 @@
<a href="/">Home</a>
</div>
<h1>Version Policy</h1>
- <p><a name="VersionPolicy-DRAFTVersionPolicy"></a></p>
-<h1 id="draft-version-policy">DRAFT Version Policy</h1>
-<p>{excerpt}This page is about how we assign versions to exported packages and
-bundles and defines when to increase which part of the version
-number.{excerpt}</p>
+ <h1 id="draft-version-policy">DRAFT Version Policy</h1>
+<p>This page is about how we assign versions to exported packages and bundles and defines when to increase which part of the version number.</p>
<p>{info}
-Please note that this page is currently in draft stage and still being
-discussed.
+Please note that this page is currently in draft stage and still being discussed.
{info}</p>
-<p>{toc:minLevel=2|maxLevel=2}</p>
-<p><a name="VersionPolicy-Introduction"></a></p>
+<div class="toc">
+<ul>
+<li><a href="#draft-version-policy">DRAFT Version Policy</a><ul>
+<li><a href="#introduction">Introduction</a></li>
+<li><a href="#version-number-syntax">Version Number Syntax</a></li>
+<li><a href="#evolution-of-exported-package-versions">Evolution of Exported Package Versions</a></li>
+<li><a href="#evolution-of-bundle-versions">Evolution of Bundle Versions</a></li>
+<li><a href="#examples">Examples</a><ul>
+<li><a href="#pure-api-bundle">Pure API Bundle</a></li>
+<li><a href="#implementation-bundle-providing-api">Implementation Bundle providing API</a></li>
+<li><a href="#pure-implementation-bundle">Pure Implementation Bundle</a></li>
+</ul>
+</li>
+<li><a href="#importing-packages">Importing Packages</a></li>
+<li><a href="#references">References</a></li>
+</ul>
+</li>
+</ul>
+</div>
<h2 id="introduction">Introduction</h2>
<p>In comments to SLING-1176 Ian Boston wrote:</p>
<p>{quote}
-The exports in bundle/api/pom.xml look like they might become problematic from a support point of view, although we probably can't avoid this. [...](....html)
- [The problem is the] manual maintenance of the version numbers. (not a
-big problem but needs to be done)
+The exports in bundle/api/pom.xml look like they might become problematic from a support point of view, although we probably can't avoid this. [...]() [The problem is the] manual maintenance of the version numbers. (not a big problem but needs to be done)
{quote}</p>
<p>I agree, that this is a problem. So let me reasonate on this a bit ;-)</p>
-<p>As a reference you might want to read <a href="http://blog.meschberger.ch/2009/10/on-version-numbers.html">my blog post on version numbers</a>
- and also what the [Eclipse guys have to say|http://wiki.eclipse.org/index.php/Version_Numbering]
- (great read, btw). The OSGi Alliance has come up with a good definition
-for [Semantic Versioning|http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf]
- to which the definitions described below perfectly match.</p>
+<p>As a reference you might want to read <a href="">my blog post on version numbers</a> and also what the [Eclipse guys have to say|http://wiki.eclipse.org/index.php/Version_Numbering] (great read, btw). The OSGi Alliance has come up with a good definition for [Semantic Versioning|http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf] to which the definitions described below perfectly match.</p>
<p>For Sling we have three kinds of version numbers:</p>
<ol>
<li>Big Sling Releases</li>
@@ -113,74 +120,33 @@ for [Semantic Versioning|http://www.osgi
<li>Package Exports</li>
</ol>
<p><em>Big Sling Releases</em></p>
-<p>For <em>Big Sling releases</em> we already have an ample solution in that we just
-use a single number increased from release to release. Just remember that a
-<em>Big Sling release</em> is a convenience release of existing released Sling
-bundles.</p>
+<p>For <em>Big Sling releases</em> we already have an ample solution in that we just use a single number increased from release to release. Just remember that a <em>Big Sling release</em> is a convenience release of existing released Sling bundles.</p>
<p><em>Sling Bundles</em></p>
-<p>For <em>Sling Bundles</em> version numbers are just defined as the <em><version></em>
-element of the bundle's POM. The only restriction here is, that we decided
-to use even numbers for releases and odd numbers for SNAPSHOTs. Whether and
-when which version part is increased is not explicitly defined yet.</p>
+<p>For <em>Sling Bundles</em> version numbers are just defined as the <code><version></code> element of the bundle's POM. The only restriction here is, that we decided to use even numbers for releases and odd numbers for SNAPSHOTs. Whether and when which version part is increased is not explicitly defined yet.</p>
<p><em>Package Exports</em></p>
-<p>For <em>Package Exports</em> the situation is more problematic since there are a
-number of places to set exported package version number:</p>
+<p>For <em>Package Exports</em> the situation is more problematic since there are a number of places to set exported package version number:</p>
<ul>
-<li>In a <em>packageinfo</em> file inside the package (picked up by the Maven
-Bundle Plugin to set the export version)</li>
-<li>Explicitly in the <em><Export-Package></em> element of the Maven Bundle
-Plugin configuration</li>
-<li>By reference to the bundle version number using the <em>${pom.version</em>}
-variable.</li>
+<li>In a <code>packageinfo</code> file inside the package (picked up by the Maven Bundle Plugin to set the export version)</li>
+<li>Explicitly in the <code><Export-Package></code> element of the Maven Bundle Plugin configuration</li>
+<li>By reference to the bundle version number using the <code>$\{pom.version</code>} variable.</li>
</ul>
-<p>Upto now, we mostly used the <em>${pom.version</em> notation linking the
-exported package version to the bundle version. Over time this mechanism
-leads to a number of problems:</p>
+<p>Upto now, we mostly used the <code>$\{pom.version</code> notation linking the exported package version to the bundle version. Over time this mechanism leads to a number of problems:</p>
<ul>
-<li>For bundles with more than one package exported, the exported packages
-will evolve independently. As a consequence their versionin should also
-evolve independently. An example of such a bundle is the Sling API bundle
-of course.</li>
-<li>Linking the package export version number to the bundle version number
-confuses the actual semantics of both version numbers. The package export
-version number only indicates the version of the actual package while the
-bundle version number indicates a development state of the overall bundle.
-This will generally not be the same.</li>
-<li>The version of the exported package is increased on each bundle
-release, even though nothing may have changed on the export. In such a
-situation the version of the export should stay the same.</li>
+<li>For bundles with more than one package exported, the exported packages will evolve independently. As a consequence their versionin should also evolve independently. An example of such a bundle is the Sling API bundle of course.</li>
+<li>Linking the package export version number to the bundle version number confuses the actual semantics of both version numbers. The package export version number only indicates the version of the actual package while the bundle version number indicates a development state of the overall bundle. This will generally not be the same.</li>
+<li>The version of the exported package is increased on each bundle release, even though nothing may have changed on the export. In such a situation the version of the export should stay the same.</li>
</ul>
-<p>That said, the reuse of the bundle version as the package export version
-still is probably the correct thing to do for legacy library wrappers.</p>
-<p>Consider for example the Sling API bundle, which exports 9 packages. Each
-of which may evolve independently. Now the <em>resource</em> package is extended
-causing a minor version increase. Should the version numbers of the other
-exports also be increased ? Thus acting as if there was some API change ?</p>
-<p>I would say, no. Particularly if some API implementation bundle is
-restricting the import version of the API implemented. Such an
-implementation would immediately stop working because the version has been
-increased. But since there has been no change, the implementation would
-still be correct.</p>
-<p>So, I think, we should evolve the exported package versions independently
-from each other and even independently from the bundle version.</p>
-<p>This places more burden on the developer when deciding on the exported
-package version - in fact this requires such a decision as compared to have
-Maven take the decision by just setting the bundle version.</p>
-<p>The only problem is: Where shall this be noted ? In the POM or in the
-<em>packageinfo</em> file ? If we would place the <em>packageinfo</em> file just
-beneath the class source files, I would say, in the <em>packageinfo</em> file.</p>
-<p>But this would require defining the class source locations as resource
-location in the POM (at least for <em>packageinfo</em>) files.</p>
+<p>That said, the reuse of the bundle version as the package export version still is probably the correct thing to do for legacy library wrappers.</p>
+<p>Consider for example the Sling API bundle, which exports 9 packages. Each of which may evolve independently. Now the <code>resource</code> package is extended causing a minor version increase. Should the version numbers of the other exports also be increased ? Thus acting as if there was some API change ?</p>
+<p>I would say, no. Particularly if some API implementation bundle is restricting the import version of the API implemented. Such an implementation would immediately stop working because the version has been increased. But since there has been no change, the implementation would still be correct.</p>
+<p>So, I think, we should evolve the exported package versions independently from each other and even independently from the bundle version.</p>
+<p>This places more burden on the developer when deciding on the exported package version - in fact this requires such a decision as compared to have Maven take the decision by just setting the bundle version.</p>
+<p>The only problem is: Where shall this be noted ? In the POM or in the <code>packageinfo</code> file ? If we would place the <code>packageinfo</code> file just beneath the class source files, I would say, in the <code>packageinfo</code> file.</p>
+<p>But this would require defining the class source locations as resource location in the POM (at least for <code>packageinfo</code>) files.</p>
<p>I am not sure ....</p>
-<p>This has not been discussed at large, but I would assume, that the POM is
-still the correct place to take note of the version of the exported
-packages.</p>
+<p>This has not been discussed at large, but I would assume, that the POM is still the correct place to take note of the version of the exported packages.</p>
<p><em>Future</em></p>
-<p>The newest versions of the BND library also support an <em>@Export</em>
-annotation in the <em>package-info.java</em> pseudo class file. This pseudo
-class is supported starting with Java 5 to take package level annotations
-(like the <em>@Export</em> annotation) and as a replacement of the
-<em>package-info.html</em> file.</p>
+<p>The newest versions of the BND library also support an <code>@Export</code> annotation in the <code>package-info.java</code> pseudo class file. This pseudo class is supported starting with Java 5 to take package level annotations (like the <code>@Export</code> annotation) and as a replacement of the <code>package-info.html</code> file.</p>
<p>Using this syntax something like the following would be easily possible:</p>
<div class="codehilite"><pre><span class="o">/**</span>
<span class="o">*</span> <span class="n">This</span> <span class="n">is</span> <span class="n">the</span> <span class="n">Package</span> <span class="n">Level</span> <span class="n">JavaDoc</span>
@@ -191,182 +157,90 @@ class is supported starting with Java 5
</pre></div>
-<p>See <a href="http://www.aqute.biz/Code/XBnd">Bnd Experimental</a>
- for details. Unfortunately the current Maven Bundle Plugin version does
-not support updating to the most recent BND library versions due to
-incompatibilities.</p>
-<p><a name="VersionPolicy-VersionNumberSyntax"></a></p>
+<p>See <a href="">Bnd Experimental</a> for details. Unfortunately the current Maven Bundle Plugin version does not support updating to the most recent BND library versions due to incompatibilities.</p>
<h2 id="version-number-syntax">Version Number Syntax</h2>
-<p>As a small reminder, this is how a version number is constructed: In OSGi
-version numbers are composed of four (4) segments: 3 integers and a string
-named major.minor.micro.qualifier.</p>
+<p>As a small reminder, this is how a version number is constructed: In OSGi version numbers are composed of four (4) segments: 3 integers and a string named major.minor.micro.qualifier.</p>
<p>Each segment captures a different intent:</p>
<div class="codehilite"><pre><span class="o">*</span> <span class="n">the</span> <span class="n">major</span> <span class="n">segment</span> <span class="n">indicates</span> <span class="n">breakage</span> <span class="n">in</span> <span class="n">the</span> <span class="n">API</span>
-<span class="o">*</span> <span class="n">the</span> <span class="n">minor</span> <span class="n">segment</span> <span class="n">indicates</span> <span class="n">_externally</span> <span class="n">visible_</span> <span class="n">changes</span>
+<span class="o">*</span> <span class="n">the</span> <span class="n">minor</span> <span class="n">segment</span> <span class="n">indicates</span> <span class="o">*</span><span class="n">externally</span> <span class="n">visible</span><span class="o">*</span> <span class="n">changes</span>
<span class="o">*</span> <span class="n">the</span> <span class="n">micro</span> <span class="n">segment</span> <span class="n">indicates</span> <span class="n">bug</span> <span class="n">fixes</span>
-<span class="o">*</span> <span class="n">the</span> <span class="n">qualifier</span> <span class="n">segment</span> <span class="n">is</span> <span class="ow">not</span> <span class="n">generally</span> <span class="n">used</span> <span class="n">but</span> <span class="n">may</span> <span class="n">be</span> <span class="n">used</span> <span class="n">to</span> <span class="n">convey</span>
+<span class="o">*</span> <span class="n">the</span> <span class="n">qualifier</span> <span class="n">segment</span> <span class="n">is</span> <span class="ow">not</span> <span class="n">generally</span> <span class="n">used</span> <span class="n">but</span> <span class="n">may</span> <span class="n">be</span> <span class="n">used</span> <span class="n">to</span> <span class="n">convey</span> <span class="n">more</span> <span class="n">information</span> <span class="n">about</span> <span class="n">a</span> <span class="n">particular</span> <span class="n">build</span><span class="p">,</span> <span class="n">such</span> <span class="n">as</span> <span class="n">a</span> <span class="n">build</span> <span class="nb">time</span> <span class="ow">or</span> <span class="n">an</span> <span class="n">SVN</span> <span class="n">revision</span> <span class="n">number</span><span class="o">.</span>
</pre></div>
-<p>more information about a particular build, such as a build time or an SVN
-revision number.</p>
-<p><a name="VersionPolicy-EvolutionofExportedPackageVersions"></a></p>
<h2 id="evolution-of-exported-package-versions">Evolution of Exported Package Versions</h2>
-<p>Version numbers of exported packages evolve independently from each other.
-Depending on the changes applied, the micro, minor, or major segement is
-increased. Whenever the major segment is increased, the minor and micro
-segments are reset to zero. Whenever the minor segment is increased, the
-micro segment is reset to zero.</p>
+<p>Version numbers of exported packages evolve independently from each other. Depending on the changes applied, the micro, minor, or major segement is increased. Whenever the major segment is increased, the minor and micro segments are reset to zero. Whenever the minor segment is increased, the micro segment is reset to zero.</p>
<p>Segments are increased according to the above listing.</p>
-<p>This requires committers to think well about changes they apply to exported
-packages:</p>
+<p>This requires committers to think well about changes they apply to exported packages:</p>
<ul>
-<li>Removing interfaces, methods or constants is likely an API breakage and
-thus requires a major version increase. In Sling we try to prevent this
-from happening.</li>
-<li>Adding new methods to interfaces is likely just an <em>externally visible</em>
-change and thus requires a minor version increase</li>
-<li>Fixing a bug in an exported class just requires a minor version
-increase.</li>
+<li>Removing interfaces, methods or constants is likely an API breakage and thus requires a major version increase. In Sling we try to prevent this from happening.</li>
+<li>Adding new methods to interfaces is likely just an <em>externally visible</em> change and thus requires a minor version increase</li>
+<li>Fixing a bug in an exported class just requires a minor version increase.</li>
</ul>
-<p>JavaDoc updates generally do not constitute a reason to evolve the version
-number. The exception is that if the JavaDoc update is caused by a API
-limitation, it might be conceivable to increase the version number of the
-exported package. A decision on this will have to be taken on a
-case-by-case basis.</p>
-<p><a name="VersionPolicy-EvolutionofBundleVersions"></a></p>
+<p>JavaDoc updates generally do not constitute a reason to evolve the version number. The exception is that if the JavaDoc update is caused by a API limitation, it might be conceivable to increase the version number of the exported package. A decision on this will have to be taken on a case-by-case basis.</p>
<h2 id="evolution-of-bundle-versions">Evolution of Bundle Versions</h2>
-<p>Version numbers of bundles evolve depending on the evolution of the
-exported packages but also depending on the evolution of the private code,
-which is not exported.</p>
-<p>As a rule of thumb, the following reasons apply for increasing the segments
-of bundle version numbers:</p>
+<p>Version numbers of bundles evolve depending on the evolution of the exported packages but also depending on the evolution of the private code, which is not exported.</p>
+<p>As a rule of thumb, the following reasons apply for increasing the segments of bundle version numbers:</p>
<ul>
-<li>Increasing the major version number of any of the exported packages or
-restructuring the bundle such that major parts are removed from the bundle
-(and either completely removed or moved to other bundle(s)).</li>
-<li>Increasing the minor version number of any of the exported packages or
-refactoring the internal code or implementing a package exported by another
-bundle whose minor (or even major) version number has increased. Also
-functional extensions of the internal bundle classes consitutes a reason to
-increase the minor version number.</li>
-<li>Increasing the micro version number of any of the exported packages or
-bug fixes.</li>
+<li>Increasing the major version number of any of the exported packages or restructuring the bundle such that major parts are removed from the bundle (and either completely removed or moved to other bundle(s)).</li>
+<li>Increasing the minor version number of any of the exported packages or refactoring the internal code or implementing a package exported by another bundle whose minor (or even major) version number has increased. Also functional extensions of the internal bundle classes consitutes a reason to increase the minor version number.</li>
+<li>Increasing the micro version number of any of the exported packages or bug fixes.</li>
</ul>
-<p>Note, that this definition does not require the bundle and epxorted package
-version numbers to be synchronized in any way. While doing so might help in
-a first or second step, over time it will become close to impossible to
-keep the versions in sync. So rather than trying to keep the versions in
-sync, we should make sure, we increase the versions correctly.</p>
-<p><a name="VersionPolicy-Examples"></a></p>
+<p>Note, that this definition does not require the bundle and epxorted package version numbers to be synchronized in any way. While doing so might help in a first or second step, over time it will become close to impossible to keep the versions in sync. So rather than trying to keep the versions in sync, we should make sure, we increase the versions correctly.</p>
<h2 id="examples">Examples</h2>
-<p><a name="VersionPolicy-PureAPIBundle"></a></p>
<h3 id="pure-api-bundle">Pure API Bundle</h3>
-<p>An example of an almost <em>Pure API Bundle</em> is the Sling API bundle. This
-bundle exports 9 packages. Some are really stable -- e.g. the
-<em>org.apache.sling.api</em> package or the <em>org.apache.sling.wrappers</em>
-package -- and some are being worked on at the moment -- e.g. the
-<em>org.apache.sling.resource</em> package.</p>
-<p>To not break existing users of the unmodified packages, the exported
-versions of these packages must not be increased.</p>
-<p>To signal to users of evolving packages, that there might be new and
-interesting functionality, the version number must be increased according
-to above definition. This also conveys to the implementor(s) of the API,
-that they have to take some action.</p>
-<p>A hypothetical evolution of version numbers shown on two packages and the
-bundle version might be as follows</p>
-<table>
-<tr><td> Description </td><td> *api* package </td><td> *resource* package </td><td> bundle </td></tr>
-<tr><td> Initial Release </td><td> 1.0.0 </td><td> 1.0.0 </td><td> 1.0.0 </td></tr>
-<tr><td> Bug fix in a *resource* class </td><td> 1.0.0 </td><td> 1.0.2 </td><td> 1.0.2 </td></tr>
-<tr><td> New API in the *resource* package </td><td> 1.0.0 </td><td> 1.1.0 </td><td> 1.1.0 </td></tr>
-<tr><td> New API in the *api* package </td><td> 1.1.0 </td><td> 1.1.0 </td><td> 1.2.0 </td></tr>
-<tr><td> API breakage in the *api* package </td><td> 2.0.0 </td><td> 1.1.0 </td><td> 2.0.0 </td></tr>
-</table>
-
-<p><a name="VersionPolicy-ImplementationBundleprovidingAPI"></a></p>
+<p>An example of an almost <em>Pure API Bundle</em> is the Sling API bundle. This bundle exports 9 packages. Some are really stable -- e.g. the <code>org.apache.sling.api</code> package or the <code>org.apache.sling.wrappers</code> package -- and some are being worked on at the moment -- e.g. the <code>org.apache.sling.resource</code> package.</p>
+<p>To not break existing users of the unmodified packages, the exported versions of these packages must not be increased.</p>
+<p>To signal to users of evolving packages, that there might be new and interesting functionality, the version number must be increased according to above definition. This also conveys to the implementor(s) of the API, that they have to take some action.</p>
+<p>A hypothetical evolution of version numbers shown on two packages and the bundle version might be as follows</p>
+<p>| Description | <code>api</code> package | <code>resource</code> package | bundle |
+| Initial Release | 1.0.0 | 1.0.0 | 1.0.0 |
+| Bug fix in a <code>resource</code> class | 1.0.0 | 1.0.2 | 1.0.2 |
+| New API in the <code>resource</code> package | 1.0.0 | 1.1.0 | 1.1.0 |
+| New API in the <code>api</code> package | 1.1.0 | 1.1.0 | 1.2.0 |
+| API breakage in the <code>api</code> package | 2.0.0 | 1.1.0 | 2.0.0 |</p>
<h3 id="implementation-bundle-providing-api">Implementation Bundle providing API</h3>
-<p>An example of such a hybrid bundle is the Sling Engine bundle. This bundle
-exports two packages themselves defining API and contains a number of
-internal packages which actually implement parts of the Sling API.</p>
-<p>A hypothetical evolution of version numbers shown on one exported package
-and the bundle version might be as follows</p>
-<table>
-<tr><td> Description </td><td> *engine* package </td><td> bundle </td></tr>
-<tr><td> Initial Release </td><td> 1.0.0 </td><td> 1.0.0 </td></tr>
-<tr><td> Bug fix in a *engine* class </td><td> 1.0.2 </td><td> 1.0.2 </td></tr>
-<tr><td> Bug fix in an internal calss </td><td> 1.0.2 </td><td> 1.0.4 </td></tr>
-<tr><td> New API in the *engine* package </td><td> 1.1.0 </td><td> 1.1.0 </td></tr>
-<tr><td> Implement new API from *api* 1.1.0 </td><td> 1.1.0 </td><td> 1.2.0 </td></tr>
-<tr><td> Refactor internal classes </td><td> 1.1.0 </td><td> 1.3.0 </td></tr>
-<tr><td> Implement API from *api* 2.0.0 </td><td> 1.1.0 </td><td> 2.0.0 </td></tr>
-</table>
-
-<p><a name="VersionPolicy-PureImplementationBundle"></a></p>
+<p>An example of such a hybrid bundle is the Sling Engine bundle. This bundle exports two packages themselves defining API and contains a number of internal packages which actually implement parts of the Sling API.</p>
+<p>A hypothetical evolution of version numbers shown on one exported package and the bundle version might be as follows</p>
+<p>| Description | <code>engine</code> package | bundle |
+| Initial Release | 1.0.0 | 1.0.0 |
+| Bug fix in a <code>engine</code> class | 1.0.2 | 1.0.2 |
+| Bug fix in an internal calss | 1.0.2 | 1.0.4 |
+| New API in the <code>engine</code> package | 1.1.0 | 1.1.0 |
+| Implement new API from <code>api</code> 1.1.0 | 1.1.0 | 1.2.0 |
+| Refactor internal classes | 1.1.0 | 1.3.0 |
+| Implement API from <code>api</code> 2.0.0 | 1.1.0 | 2.0.0 |</p>
<h3 id="pure-implementation-bundle">Pure Implementation Bundle</h3>
-<p>For Pure Implementation Bundles only the bundle version numbers are
-maintained because there is no exported package whose version number needs
-to be managed. This makes the decision process of version number evolution
-very simple.</p>
-<p><a name="VersionPolicy-ImportingPackages"></a></p>
+<p>For Pure Implementation Bundles only the bundle version numbers are maintained because there is no exported package whose version number needs to be managed. This makes the decision process of version number evolution very simple.</p>
<h2 id="importing-packages">Importing Packages</h2>
-<p>When importing packages a version number will automatically be generated by
-the Maven Bundle Plugin as follows:</p>
+<p>When importing packages a version number will automatically be generated by the Maven Bundle Plugin as follows:</p>
<ul>
-<li>If the providing package exports a package with an explicit version
-number, that exact version number will be used as the lower bound</li>
-<li>If such a lower bound exists, the upper bound is exclusive the next
-major version number.</li>
+<li>If the providing package exports a package with an explicit version number, that exact version number will be used as the lower bound</li>
+<li>If such a lower bound exists, the upper bound is exclusive the next major version number.</li>
</ul>
-<p>For example if importing the <em>api</em> package exported at version 1.2.3, the
-<em>Import-Package</em> statement is generated as</p>
+<p>For example if importing the <code>api</code> package exported at version 1.2.3, the <code>Import-Package</code> statement is generated as</p>
<div class="codehilite"><pre><span class="n">Import</span><span class="o">-</span><span class="n">Package:</span> <span class="n">api</span><span class="p">;</span><span class="n">version</span><span class="o">=</span><span class="p">[</span><span class="mf">1.2.3</span><span class="p">,</span><span class="mf">2.0.0</span><span class="p">)</span>
</pre></div>
-<p>This default works well for consumers of the API, since according to above
-definitions an API is guaranteed to not contain breakages if the major
-version number is not increased.</p>
-<p>For bundles implementing the API, this default does not work well, since
-from their point of view an <em>externally visible</em> change in fact constitutes
-a breakage, because the implementation is not complete. So if a bundle
-implements a package a manually crafted import version should be defined
-which includes the export version of the defining bundle but excludes the
-next minor version.</p>
-<p>For example implementing the <em>api</em> package exported at version 1.2.3,
-would require the following manually created <em>Import-Package</em> statement:</p>
+<p>This default works well for consumers of the API, since according to above definitions an API is guaranteed to not contain breakages if the major version number is not increased.</p>
+<p>For bundles implementing the API, this default does not work well, since from their point of view an <em>externally visible</em> change in fact constitutes a breakage, because the implementation is not complete. So if a bundle implements a package a manually crafted import version should be defined which includes the export version of the defining bundle but excludes the next minor version.</p>
+<p>For example implementing the <code>api</code> package exported at version 1.2.3, would require the following manually created <code>Import-Package</code> statement:</p>
<div class="codehilite"><pre><span class="n">Import</span><span class="o">-</span><span class="n">Package:</span> <span class="n">api</span><span class="p">;</span><span class="n">version</span><span class="o">=</span><span class="p">[</span><span class="mf">1.2.3</span><span class="p">,</span><span class="mf">1.3.0</span><span class="p">)</span>
</pre></div>
-<p>This allows for the implementation to work correctly with bug fixed package
-exports but as soon as there are any <em>externally visible</em> changes, the
-implementation bundle has to be adapted -- even if this just means
-increasing the upper version bound in the <em>Import-Package</em> statement thus
-guaranteeing compliance (again).</p>
+<p>This allows for the implementation to work correctly with bug fixed package exports but as soon as there are any <em>externally visible</em> changes, the implementation bundle has to be adapted -- even if this just means increasing the upper version bound in the <code>Import-Package</code> statement thus guaranteeing compliance (again).</p>
<p><em>Future</em></p>
-<p>Recent versions of the BND library support automatic differntiation between
-use and implementation of API and to set the import version ranges
-accordingly. See <a href="http://www.aqute.biz/Code/XBnd">Bnd Experimental</a>
- for details. Unfortunately the current Maven Bundle Plugin version does
-not support updating to the most recent BND library versions due to
-incompatibilities.</p>
-<p><a name="VersionPolicy-References"></a></p>
+<p>Recent versions of the BND library support automatic differntiation between use and implementation of API and to set the import version ranges accordingly. See <a href="">Bnd Experimental</a> for details. Unfortunately the current Maven Bundle Plugin version does not support updating to the most recent BND library versions due to incompatibilities.</p>
<h2 id="references">References</h2>
-<p><a href="http://markmail.org/thread/zshobgjwtqrncajt">Version Numbers</a>
- -- The mail thread discussing version numbering
-<a href="http://blog.meschberger.ch/2009/10/on-version-numbers.html">On Version Numbers</a>
- -- Blog about version numbers
-<a href="http://wiki.eclipse.org/index.php/Version_Numbering">Version Numbering</a>
- -- An Eclipse paper on assigning version numbers. Very good read.
-<a href="http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf">Semantic Versioning</a>
- -- An OSGi Alliance paper on semantic versioning.
-<a href="http://www.aqute.biz/Code/XBnd">Bnd Experimental</a>
- -- Experimental extensions to the BND library; unfortunately these
-extensions are not yet usable with Maven Bundle Plugin 2.1.0 due to API
-changes in the BND library not supported by the plugin.</p>
+<p><a href="">Version Numbers</a> -- The mail thread discussing version numbering
+<a href="">On Version Numbers</a> -- Blog about version numbers
+<a href="">Version Numbering</a> -- An Eclipse paper on assigning version numbers. Very good read.
+<a href="">Semantic Versioning</a> -- An OSGi Alliance paper on semantic versioning.
+<a href="">Bnd Experimental</a> -- Experimental extensions to the BND library; unfortunately these extensions are not yet usable with Maven Bundle Plugin 2.1.0 due to API changes in the BND library not supported by the plugin.</p>
<div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
- Rev. 1328899 by fmeschbe on Sun, 22 Apr 2012 16:52:13 +0000
+ Rev. 1341347 by fmeschbe on Tue, 22 May 2012 08:25:18 +0000
</div>
<div class="trademarkFooter">
Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project
Modified: websites/staging/sling/trunk/content/web-console-extensions.html
==============================================================================
--- websites/staging/sling/trunk/content/web-console-extensions.html (original)
+++ websites/staging/sling/trunk/content/web-console-extensions.html Tue May 22 08:25:32 2012
@@ -82,59 +82,57 @@
<a href="/">Home</a>
</div>
<h1>Web Console Extensions</h1>
- <p><a name="WebConsoleExtensions-WebConsoleExtensions"></a></p>
-<h1 id="web-console-extensions">Web Console Extensions</h1>
-<p>The Apache Sling project provides two extensions to the <a href="http://felix.apache.org/site/apache-felix-web-console.html">Apache Felix Web Console</a>
- (in addition to a number of plugins, of course):</p>
-<p>{toc:minLevel=2|maxLevel=2}</p>
-<p><a name="WebConsoleExtensions-Branding(org.apache.sling.extensions.webconsolebranding)"></a></p>
+ <h1 id="web-console-extensions">Web Console Extensions</h1>
+<p>The Apache Sling project provides two extensions to the <a href="">Apache Felix Web Console</a> (in addition to a number of plugins, of course):</p>
+<div class="toc">
+<ul>
+<li><a href="#web-console-extensions">Web Console Extensions</a><ul>
+<li><a href="#branding-orgapacheslingextensionswebconsolebranding">Branding (org.apache.sling.extensions.webconsolebranding)</a></li>
+<li><a href="#security-provider-orgapacheslingextensionswebconsolesecurityprovider">Security Provider (org.apache.sling.extensions.webconsolesecurityprovider)</a><ul>
+<li><a href="#configuration">Configuration</a></li>
+</ul>
+</li>
+</ul>
+</li>
+</ul>
+</div>
<h2 id="branding-orgapacheslingextensionswebconsolebranding">Branding (org.apache.sling.extensions.webconsolebranding)</h2>
-<p>The Apache Sling Web Console Branding provided by Apache Sling is currently
-just for the product logo displayed in the upper right corner of the Web
-Console and some titles and strings.</p>
-<p>This bundle will attach as a fragment bundle to the Apache Felix Web
-Console bundle. To enable it after installation into a running system, you
-might have to refresh the package imports of the Apache Felix Web Console
-bundle. If you install using the Apache Felix Web Console bundle
-installation functionality, this will be taken care of by the Web Console.</p>
-<p>h2. Security Provider
-(org.apache.sling.extensions.webconsolesecurityprovider)</p>
-<p>The Apache Sling Web Console Security Provider implements the Apache Felix
-Web Console <em>WebConsoleSecurityProvider</em> interface authenticating Web
-Console users against the JCR repository. Each username and password
-presented is used to login to the JCR repository and to check the
-respective session.</p>
+<p>The Apache Sling Web Console Branding provided by Apache Sling is currently just for the product logo displayed in the upper right corner of the Web Console and some titles and strings.</p>
+<p>This bundle will attach as a fragment bundle to the Apache Felix Web Console bundle. To enable it after installation into a running system, you might have to refresh the package imports of the Apache Felix Web Console bundle. If you install using the Apache Felix Web Console bundle installation functionality, this will be taken care of by the Web Console.</p>
+<h2 id="security-provider-orgapacheslingextensionswebconsolesecurityprovider">Security Provider (org.apache.sling.extensions.webconsolesecurityprovider)</h2>
+<p>The Apache Sling Web Console Security Provider implements the Apache Felix Web Console <code>WebConsoleSecurityProvider</code> interface authenticating Web Console users against the JCR repository. Each username and password presented is used to login to the JCR repository and to check the respective session.</p>
<ol>
-<li>Ensure the username and password can be used to login to the default
-workspace. If not, access is denied</li>
-<li>If the username presented is one of the user names configured with the
-<em>users</em> configuration property, access is granted.</li>
-<li>Otherwise if the user is a (direct or indirect) member of one of the
-groups configured with the <em>groups</em> configuration property, access is
-granted.</li>
+<li>Ensure the username and password can be used to login to the default workspace. If not, access is denied</li>
+<li>If the username presented is one of the user names configured with the <code>users</code> configuration property, access is granted.</li>
+<li>Otherwise if the user is a (direct or indirect) member of one of the groups configured with the <code>groups</code> configuration property, access is granted.</li>
</ol>
-<p>Access is denied if the username and password cannot be used to login to
-the default workspace or if the user is neither one of the configured
-allowed users nor in any of the configured groups.</p>
-<p><a name="WebConsoleExtensions-Configuration"></a></p>
+<p>Access is denied if the username and password cannot be used to login to the default workspace or if the user is neither one of the configured allowed users nor in any of the configured groups.</p>
<h3 id="configuration">Configuration</h3>
-<p>The Security Provider is configured with configuration with PID
-<em>org.apache.sling.extensions.webconsolesecurityprovider.internal.SlingWebConsoleSecurityProvider</em>
-supporting the following properties:</p>
+<p>The Security Provider is configured with configuration with PID <code>org.apache.sling.extensions.webconsolesecurityprovider.internal.SlingWebConsoleSecurityProvider</code> supporting the following properties:</p>
<table>
-<tr><th> Property </th><th> Type </th><th> Default Value </th><th> Description
+<thead>
+<tr>
+<th>Property</th>
+<th>Type</th>
+<th>Default Value</th>
</tr>
-<tr><td> *users* </td><td> *String*, or *Vector<String>* </td><td> admin </td><td> The list of users granted access to the
-Web Console </td></tr>
-<tr><td> *groups*</td><td> *String*, or *Vector<String>* </td><td> --- </td><td> The list of groups whose (direct or
-indirect) members are granted access to the Web Console </td></tr>
+</thead>
+<tbody>
+<tr>
+<td><code>users</code></td>
+<td><code>String</code>, <code>String[]()</code> or <code>Vector<String></code></td>
+<td>admin</td>
+</tr>
+<tr>
+<td><code>groups</code></td>
+<td><code>String</code>, <code>String[]()</code> or <code>Vector<String></code></td>
+<td>---</td>
+</tr>
+</tbody>
</table>
-
-<p>Note, that while the default value explicitly grants the <em>admin</em> user to
-access the Web Console it is suggested that system administrators define a
-special group and assign users with Web Console access to this group.</p>
+<p>Note, that while the default value explicitly grants the <em>admin</em> user to access the Web Console it is suggested that system administrators define a special group and assign users with Web Console access to this group.</p>
<div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
- Rev. 1328899 by fmeschbe on Sun, 22 Apr 2012 16:52:13 +0000
+ Rev. 1341347 by fmeschbe on Tue, 22 May 2012 08:25:18 +0000
</div>
<div class="trademarkFooter">
Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project
Modified: websites/staging/sling/trunk/content/wiki.html
==============================================================================
--- websites/staging/sling/trunk/content/wiki.html (original)
+++ websites/staging/sling/trunk/content/wiki.html Tue May 22 08:25:32 2012
@@ -82,33 +82,24 @@
<a href="/">Home</a>
</div>
<h1>wiki</h1>
- <p><a name="wiki-ApacheSlingWebsite"></a></p>
-<h1 id="apache-sling-website">Apache Sling Website</h1>
+ <h1 id="apache-sling-website">Apache Sling Website</h1>
<p>{tip:title=Use Generated Pages}
-The Apache Sling project uses a Confluence space for documentation purposes
-and to generate the static Sling web site. You are currently looking at the
-source wiki. End users should generally use the static, generated pages, at
-http://incubator.apache.org/sling since the wiki is typically only
-necessary for editing content. Below you'll find an overview of the main
-menu, all pages in this wiki as well as a list of recently modified pages.
+The Apache Sling project uses a Confluence space for documentation purposes and to generate the static Sling web site. You are currently looking at the source wiki. End users should generally use the static, generated pages, at http://incubator.apache.org/sling since the wiki is typically only necessary for editing content. Below you'll find an overview of the main menu, all pages in this wiki as well as a list of recently modified pages.
{tip}</p>
<p>{section}
-{column:width=50%}
-<a name="wiki-Menu"></a></p>
+{column:width=50%}</p>
<h1 id="menu">Menu</h1>
-<p>{include:navigation}
-<a name="wiki-Recentlyupdatedpages"></a></p>
+<p>{include:navigation}</p>
<h1 id="recently-updated-pages">Recently updated pages</h1>
<p>{recently-updated:spaces=SLINGxSITE}
{column}</p>
-<p>{column:width=50%}
-<a name="wiki-Sitemap"></a></p>
+<p>{column:width=50%}</p>
<h1 id="site-map">Site map</h1>
<p>{children:page=SLINGxSITE:|all=true}
{column}
{section} </p>
<div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
- Rev. 1328899 by fmeschbe on Sun, 22 Apr 2012 16:52:13 +0000
+ Rev. 1341347 by fmeschbe on Tue, 22 May 2012 08:25:18 +0000
</div>
<div class="trademarkFooter">
Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project
Modified: websites/staging/sling/trunk/content/wrap-or-decorate-resources.html
==============================================================================
--- websites/staging/sling/trunk/content/wrap-or-decorate-resources.html (original)
+++ websites/staging/sling/trunk/content/wrap-or-decorate-resources.html Tue May 22 08:25:32 2012
@@ -82,19 +82,13 @@
<a href="/">Home</a>
</div>
<h1>Wrap or Decorate Resources</h1>
- <p><a name="WraporDecorateResources-Servicetowrapresources"></a></p>
-<h1 id="service-to-wrap-resources">Service to wrap resources</h1>
-<p><a name="WraporDecorateResources-Introduction"></a></p>
+ <h1 id="service-to-wrap-resources">Service to wrap resources</h1>
<h2 id="introduction">Introduction</h2>
-<p>The Sling API provides an easy way to wrap or decorate a resource before
-returning. Use cases for this could for example be
-<em> overwrite resource type/resource super type (for example based on the
-resource path)
+<p>The Sling API provides an easy way to wrap or decorate a resource before returning. Use cases for this could for example be
+<em> overwrite resource type/resource super type (for example based on the resource path)
</em> add metadata</p>
-<p><a name="WraporDecorateResources-"></a></p>
<h2></h2>
-<p>To add a resource decorator just register one or more services which
-implement the interface <em>ResourceDecorator</em></p>
+<p>To add a resource decorator just register one or more services which implement the interface <code>ResourceDecorator</code></p>
<div class="codehilite"><pre><span class="n">interface</span> <span class="n">ResourceDecorator</span> <span class="p">{</span>
<span class="n">Resource</span> <span class="n">decorate</span><span class="p">(</span><span class="n">Resource</span><span class="p">)</span>
@@ -104,26 +98,18 @@ implement the interface <em>ResourceDeco
</pre></div>
-<p>The registered decorators will be called from the resource resolver for
-each resource returned.
-If the service decorates the resource it should return the new resource. If
-the service does not want to decorate the resource, it should return the
-original resource or null. </p>
-<p>The two-argument <em>{decorate</em>} method will not be invoked, starting with
-version 2.1.0 of the JCR Resource bundle. Implementors of this interface
-targeting both newer and older versions of this bundle are advised to
-implement this method with:</p>
-<div class="codehilite"><pre> <span class="n">public</span> <span class="n">Resource</span> <span class="n">decorate</span><span class="p">(</span><span class="n">Resource</span> <span class="n">resource</span><span class="p">,</span> <span class="n">HttpServletRequest</span> <span class="n">request</span><span class="p">)</span>
+<p>The registered decorators will be called from the resource resolver for each resource returned.
+If the service decorates the resource it should return the new resource. If the service does not want to decorate the resource, it should return the original resource or null. </p>
+<p>The two-argument <code>{decorate</code>} method will not be invoked, starting with version 2.1.0 of the JCR Resource bundle. Implementors of this interface targeting both newer and older versions of this bundle are advised to implement this method with:</p>
+<div class="codehilite"><pre> <span class="n">public</span> <span class="n">Resource</span> <span class="n">decorate</span><span class="p">(</span><span class="n">Resource</span> <span class="n">resource</span><span class="p">,</span> <span class="n">HttpServletRequest</span> <span class="n">request</span><span class="p">)</span> <span class="p">{</span>
+ <span class="k">return</span> <span class="n">this</span><span class="o">.</span><span class="n">decorate</span><span class="p">(</span><span class="n">resource</span><span class="p">);</span>
+ <span class="p">}</span>
</pre></div>
-<p>{
- return this.decorate(resource);
- }</p>
-<p>And use some other method (e.g. a <em>{ThreadLocal</em>}) to obtain the current
-request if necessary.</p>
+<p>And use some other method (e.g. a <code>{ThreadLocal</code>}) to obtain the current request if necessary.</p>
<div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
- Rev. 1328899 by fmeschbe on Sun, 22 Apr 2012 16:52:13 +0000
+ Rev. 1341347 by fmeschbe on Tue, 22 May 2012 08:25:18 +0000
</div>
<div class="trademarkFooter">
Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project
Modified: websites/staging/sling/trunk/content/xslt-processing-pipeline.html
==============================================================================
--- websites/staging/sling/trunk/content/xslt-processing-pipeline.html (original)
+++ websites/staging/sling/trunk/content/xslt-processing-pipeline.html Tue May 22 08:25:32 2012
@@ -84,7 +84,7 @@
<h1>XSLT Processing Pipeline</h1>
<div class="timestamp" style="margin-top: 30px; font-size: 80%; text-align: right;">
- Rev. 1328899 by fmeschbe on Sun, 22 Apr 2012 16:52:13 +0000
+ Rev. 1341347 by fmeschbe on Tue, 22 May 2012 08:25:18 +0000
</div>
<div class="trademarkFooter">
Apache Sling, Sling, Apache, the Apache feather logo, and the Apache Sling project