incubator-sling-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From conflue...@apache.org
Subject [CONF] Apache Sling Website > OSGi Installer
Date Tue, 11 Oct 2011 08:48:00 GMT
<html>
<head>
    <base href="https://cwiki.apache.org/confluence">
            <link rel="stylesheet" href="/confluence/s/2042/9/1/_/styles/combined.css?spaceKey=SLINGxSITE&amp;forWysiwyg=true"
type="text/css">
    </head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
    <h2><a href="https://cwiki.apache.org/confluence/display/SLINGxSITE/OSGi+Installer">OSGi
Installer</a></h2>
    <h4>Page <b>edited</b> by             <a href="https://cwiki.apache.org/confluence/display/~cziegeler@apache.org">Carsten
Ziegeler</a>
    </h4>
        <br/>
                         <h4>Changes (2)</h4>
                                 
    
<div id="page-diffs">
                    <table class="diff" cellpadding="0" cellspacing="0">
    
            <tr><td class="diff-added-lines" style="background-color: #dfd;">h1.
Overview <br> <br></td></tr>
            <tr><td class="diff-unchanged" >The OSGi installer is a central service
for handling installs, updates and uninstall of &quot;artifacts&quot;. By default,
the installer supports bundles and has an extension for handling configurations for the OSGi
configuration admin. <br> <br>!Slide14.jpg|border=1! <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">
<br>The OSGi installer itself is &quot;just&quot; the central service managing
the tasks and states of the artifacts. The artifacts can be provided through various providers,
e.g. through a file system provider reading artifacts from configured directories or the jcr
provider reading artifacts from a JCR repository. <br> <br>A provider is just
scanning for artifacts and their removal. It informs the OSGi installer about new artifacts
and removed artifacts. The provider itself has usually no knowledge about the contents of
an artifact. It does not know about bundles, configurations etc. <br> <br>As the
OSGi installer itself is not performing the actual install, update or removal of an artifact,
its possible to install transformers and installer factories. A transformer inspects the artifacts
and tries to detect its type. By default, detecting of bundles and configurations is supported.
The final service is an installer factory creating the actual task, like install this bundle,
update that bundle etc. <br> <br>It&#39;s possible to add own providers, transformers
and installer factories to support custom scenarios. <br> <br>h2. Artifact Handling
<br> <br>Once an artifact is detected by a transformer, it gets a unique id. By
default a bundle gets the symbolic name and version as the unique identifier and a configuration
the PID. <br></td></tr>
    
            </table>
    </div>                            <h4>Full Content</h4>
                    <div class="notificationGreySide">
        <h1><a name="OSGiInstaller-Overview"></a>Overview</h1>

<p>The OSGi installer is a central service for handling installs, updates and uninstall
of "artifacts". By default, the installer supports bundles and has an extension for handling
configurations for the OSGi configuration admin.</p>

<p><span class="image-wrap" style=""><img src="/confluence/download/attachments/27828602/Slide14.jpg?version=1&amp;modificationDate=1318322150593"
style="border: 1px solid black" /></span></p>

<p>The OSGi installer itself is "just" the central service managing the tasks and states
of the artifacts. The artifacts can be provided through various providers, e.g. through a
file system provider reading artifacts from configured directories or the jcr provider reading
artifacts from a JCR repository.</p>

<p>A provider is just scanning for artifacts and their removal. It informs the OSGi
installer about new artifacts and removed artifacts. The provider itself has usually no knowledge
about the contents of an artifact. It does not know about bundles, configurations etc.</p>

<p>As the OSGi installer itself is not performing the actual install, update or removal
of an artifact, its possible to install transformers and installer factories. A transformer
inspects the artifacts and tries to detect its type. By default, detecting of bundles and
configurations is supported. The final service is an installer factory creating the actual
task, like install this bundle, update that bundle etc.</p>

<p>It's possible to add own providers, transformers and installer factories to support
custom scenarios.</p>

<h2><a name="OSGiInstaller-ArtifactHandling"></a>Artifact Handling</h2>

<p>Once an artifact is detected by a transformer, it gets a unique id. By default a
bundle gets the symbolic name and version as the unique identifier and a configuration the
PID.</p>
    </div>
        <div id="commentsSection" class="wiki-content pageSection">
        <div style="float: right;">
            <a href="https://cwiki.apache.org/confluence/users/viewnotifications.action"
class="grey">Change Notification Preferences</a>
        </div>
        <a href="https://cwiki.apache.org/confluence/display/SLINGxSITE/OSGi+Installer">View
Online</a>
        |
        <a href="https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=27828602&revisedVersion=3&originalVersion=2">View
Changes</a>
                |
        <a href="https://cwiki.apache.org/confluence/display/SLINGxSITE/OSGi+Installer?showComments=true&amp;showCommentArea=true#addcomment">Add
Comment</a>
            </div>
</div>
</div>
</div>
</div>
</body>
</html>

Mime
View raw message