This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/sling-site.git
The following commit(s) were added to refs/heads/asf-site by this push:
new e25ef3c Automatic website deployment
e25ef3c is described below
commit e25ef3c959c0f7210e746ca5795504881a1145dd
Author: jenkins <[email protected]>
AuthorDate: Wed Mar 18 14:25:12 2020 +0000
Automatic website deployment
---
documentation/bundles/osgi-installer.html | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/documentation/bundles/osgi-installer.html
b/documentation/bundles/osgi-installer.html
index 29cacd1..8ee6c7f 100644
--- a/documentation/bundles/osgi-installer.html
+++ b/documentation/bundles/osgi-installer.html
@@ -131,15 +131,17 @@
<p>In general, the OSGi installer always tries to install the highest version
of a bundle if several bundles with the same symbolic name are provided. In
this case higher version wins over priority. If an installed bundle is removed
by a provider, for example deleted in the repository, the OSGi installer
uninstall the bundle. If a bundle is removed from a provider which is currently
not installed, this has no effect at all. If an installed bundle is removed and
another version of this bu [...]
<p>If a failure occurs during bundle installation or update, the OSGi
installer will retry this as soon as another bundle has been installed. The
common use case is an application installation with several bundles where one
bundle depends on another. As they are installed in arbitrary order, this
mechanism ensures that in the end all bundles are properly wired and
installed.</p>
<p>When all artifacts have been processed (either install, update or delete),
a package refresh is automatically called.</p>
-<h3><a href="#multiversion-support" name="multiversion-support">Multiversion
Support</a></h3>
-<p>Starting with Installer Core 3.11.0 the install behavior of bundles may be
altered for an instance through setting the System or Framework Property
<code>sling.installer.multiversion=true</code>. If this property is set the
entity ID of each installable bundle also contains the version making multiple
versions of the same bundle agnostic of each other. </p>
-<p>With this flag being set changes to the install candidates only affect the
very same version of this bundle. This leads to the following behavior</p>
+<h3><a href="#multi-version-support"
name="multi-version-support">Multi-Version Support</a></h3>
+<p>For now this feature is considered <strong>experimental</strong>, see <a
href="https://issues.apache.org/jira/browse/SLING-9172";>SLING-9172</a> and
related tickets for details.</p>
+<p>Starting with version 3.11.0 of the
<code>org.apache.sling.installer.core</code> bundle, setting the System or
Framework Property <code>sling.installer.multiversion=true</code> activates
multi-version support.</p>
+<p>When this option is active, the entity ID of each installable bundle also
contains the version, enabling multiple versions of the same bundle to be
installed.</p>
+<p>In this case, changes to the installable candidates only affect the very
same version of this bundle, leading to the following behavior:</p>
<ul>
- <li>additional bundles in different versions will be installed side-by-side
in the osgi framework (no update of existing bundles with same symbolic name
but different version)</li>
- <li>removal of install candidates only will trigger uninstallation of the
linked bundle</li>
- <li>existing bundles will only be updated in case of an update of a SNAPSHOT
artifact</li>
+ <li>Different versions of the same bundle are installed side-by-side in the
OSGi framework, instead of installing only the highest version of each
bundle.</li>
+ <li>Removing an installable candidate only triggers uninstallation of the
corresponding bundle version.</li>
+ <li>Installed bundles are only updated if have SNAPSHOT versions.</li>
</ul>
-<p>This feature when used may make cases more prominent and relevant to deal
with concurrent bundles providing the same java packages which was possible
through bundles with different bundlesymbolic names or by other installation
mechanisms already granting the option to install concurrent versions of a
bundle.</p>
+<p>This feature allows for providing multiple versions of the same Java
packages, which was previously only possible by creating bundles with different
symbolic names but providing the same packages, or by using other installation
mechanisms.</p>
<h3><a href="#versions-and-snapshots" name="versions-and-snapshots">Versions
and Snapshots</a></h3>
<p>The OSGi installer asumes that a symbolic name and version (not a snapshot
version) uniquely identifies a bundle. Obviously this is a common development
requirement that a released version of an artifact never changes over time.
Therefore, once a bundle with a specific version is installed, it will not be
reinstalled if the corresponding artifact changes. For example, if bundle A
with version 1.0 is put into the JCR repository, it gets installed. If now this
jar in the repository is o [...]
<p>During development, SNAPSHOT versions should be used, like 1.0.0-SNAPSHOT
(using the Maven convention). If a bundle with a snapshot version is changed,
it gets updated by the OSGI installer.</p>
@@ -182,7 +184,7 @@
</div><footer class="footer">
<div class="content has-text-centered is-small">
<div class="revisionInfo">
- Last modified by <span class="author">Dominik
Suess</span> on <span class="comment">Wed Mar 18 11:34:04 2020 +0100</span>
+ Last modified by <span class="author">Bertrand
Delacretaz</span> on <span class="comment">Wed Mar 18 15:23:37 2020 +0100</span>
</div> <p>
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.
</p><p>
