| <!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
| <html><head> |
| |
| |
| |
| <title>Apache Felix - Apache Felix OSGi Bundle Repository</title> |
| <link rel="stylesheet" href="apache-felix-osgi-bundle-repository_files/site.css" type="text/css" media="all"> |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> |
| </head><body> |
| <div class="title"><div class="logo"><a href="http://felix.apache.org/site/index.html"><img alt="Apache Felix" src="apache-felix-osgi-bundle-repository_files/logo.png" border="0"></a></div><div class="header"><a href="http://www.apache.org/"><img alt="Apache" src="apache-felix-osgi-bundle-repository_files/apache.png" border="0"></a></div></div> |
| <div class="menu"> |
| <ul> |
| <li><a href="http://cwiki.apache.org/FELIX/news.html" title="news">news</a></li> |
| <li><a href="http://cwiki.apache.org/FELIX/license.html" title="license">license</a></li> |
| <li><a href="http://felix.apache.org/site/downloads.cgi" rel="nofollow">downloads</a></li> |
| <li><a href="http://cwiki.apache.org/FELIX/documentation.html" title="documentation">documentation</a></li> |
| <li><a href="http://cwiki.apache.org/FELIX/mailinglists.html" title="mailinglists">mailing lists</a></li> |
| <li><a href="http://cwiki.apache.org/FELIX/contributing.html" title="Contributing">contributing</a></li> |
| <li><a href="http://www.apache.org/" rel="nofollow">asf</a></li> |
| <li><a href="http://www.apache.org/foundation/sponsorship.html" rel="nofollow">sponsorship</a></li> |
| <li><a href="http://www.apache.org/foundation/thanks.html" rel="nofollow">sponsors</a> |
| <!-- ApacheCon Ad --> |
| <iframe src="apache-felix-osgi-bundle-repository_files/button.html" style="border-width: 0pt; float: left;" frameborder="0" height="135" scrolling="no" width="135"></iframe> |
| <p style="height: 100px;"> |
| <!-- ApacheCon Ad --> |
| </p></li></ul> </div> |
| <div class="main"> |
| <h1><a name="ApacheFelixOSGiBundleRepository-ApacheFelixOSGiBundleRepository(OBR)"></a>Apache Felix OSGi Bundle Repository (OBR)</h1> |
| |
| <div> |
| <ul> |
| <li><a href="#ApacheFelixOSGiBundleRepository-Motivation">Motivation</a></li> |
| <li><a href="#ApacheFelixOSGiBundleRepository-Overview">Overview</a></li> |
| <li><a href="#ApacheFelixOSGiBundleRepository-OBRRepositoryFile">OBR Repository File</a></li> |
| <li><a href="#ApacheFelixOSGiBundleRepository-OBRServiceAPI">OBR Service API</a></li> |
| <li><a href="#ApacheFelixOSGiBundleRepository-OBRShellCommand">OBR Shell Command</a></li> |
| <ul> |
| <li><a href="#ApacheFelixOSGiBundleRepository-obrhelp">obr help</a></li> |
| <li><a href="#ApacheFelixOSGiBundleRepository-obrlisturl">obr list-url</a></li> |
| <li><a href="#ApacheFelixOSGiBundleRepository-obraddurl">obr add-url</a></li> |
| <li><a href="#ApacheFelixOSGiBundleRepository-obrremoveurl">obr remove-url</a></li> |
| <li><a href="#ApacheFelixOSGiBundleRepository-obrlist">obr list</a></li> |
| <li><a href="#ApacheFelixOSGiBundleRepository-obrinfo">obr info</a></li> |
| <li><a href="#ApacheFelixOSGiBundleRepository-obrdeploy">obr deploy</a></li> |
| <li><a href="#ApacheFelixOSGiBundleRepository-obrstart">obr start</a></li> |
| <li><a href="#ApacheFelixOSGiBundleRepository-obrsource">obr source</a></li> |
| <li><a href="#ApacheFelixOSGiBundleRepository-obrjavadoc">obr javadoc</a></li> |
| </ul> |
| <li><a href="#ApacheFelixOSGiBundleRepository-UsingOBRwithaProxy">Using OBR with a Proxy</a></li> |
| <li><a href="#ApacheFelixOSGiBundleRepository-BundleSourcePackaging">Bundle Source Packaging</a></li> |
| <li><a href="#ApacheFelixOSGiBundleRepository-NoteonOSGiR3Bundles">Note on OSGi R3 Bundles</a></li> |
| <li><a href="#ApacheFelixOSGiBundleRepository-Feedback">Feedback</a></li> |
| </ul></div> |
| |
| <p><a name="ApacheFelixOSGiBundleRepository-motivation"></a></p> |
| |
| <h2><a name="ApacheFelixOSGiBundleRepository-Motivation"></a>Motivation</h2> |
| |
| <p>The goal of the Apache Felix OSGi Bundle Repository (OBR) is two-fold:</p> |
| |
| <ol> |
| <li>To simplify deploying and using available bundles with Felix.</li> |
| <li>To encourage independent bundle development so that communities of interest can grow.</li> |
| </ol> |
| |
| |
| <p>OBR achieves the first goal by providing a service that can |
| automatically install a bundle, with its deployment dependencies, from |
| a bundle repository. This makes it easier for people to experiment with |
| existing bundles. The second goal is achieved by raising the visibility |
| of the available bundles and providing access to both the executable |
| bundle and its source code. Hopefully, by making OBR and the bundles |
| themselves more visible, community members will be encouraged to |
| provide or improve service implementations.</p> |
| |
| <p>Note: OBR provides access to the Felix' default bundle repository, |
| but you can also use it to deploy your own bundles by creating a bundle |
| repository meta-data file for your local bundles; see the <tt>obr list-url</tt>, <tt>obr add-url</tt>, and <tt>obr remove-url</tt> commands for more details.</p> |
| |
| <p><a name="ApacheFelixOSGiBundleRepository-overview"></a></p> |
| |
| <h2><a name="ApacheFelixOSGiBundleRepository-Overview"></a>Overview</h2> |
| |
| <p>For the most part, OBR is quite simple. An OBR "repository server" |
| is not necessary, since all functionality may reside on the client |
| side. OBR is able to provide its functionality by reading an XML-based |
| meta-data file that describes the bundles available to it. The |
| meta-data file essentially contains an XML encoding of the bundles' |
| manifest information. From the meta-data, OBR is able to construct |
| dependency information for deploying (i.e., installing and updating) |
| bundles.</p> |
| |
| <p>OBR defines the following entities:</p> |
| |
| <ul> |
| <li><em><b>Repository Admin</b></em> - a service to access a federation of repositories.</li> |
| <li><em><b>Repository</b></em> - provides access to a set of resources.</li> |
| <li><em><b>Resource</b></em> - a description of an artifact to be installed on a device.</li> |
| <li><em><b>Capability</b></em> - a named set of properties.</li> |
| <li><em><b>Requirement</b></em> - an assertion on a capability.</li> |
| <li><em><b>Resolver</b></em> - an object to resolve resource dependencies and to deploy them.</li> |
| <li><em><b>Repository file</b></em> - XML file containing resource meta-data.</li> |
| </ul> |
| |
| |
| <p>The following diagram illustrates the relationships among these entities:</p> |
| |
| <p><img src="apache-felix-osgi-bundle-repository_files/obr-entities.png" align="absmiddle" border="0"></p> |
| |
| <p>The client has access to a federated set of repositories via the Repository Admin service; such as depicted in this view:</p> |
| |
| <p><img src="apache-felix-osgi-bundle-repository_files/obr-high-level.png" align="absmiddle" border="0"></p> |
| |
| <p><a name="ApacheFelixOSGiBundleRepository-repositoryfile"></a></p> |
| |
| <h2><a name="ApacheFelixOSGiBundleRepository-OBRRepositoryFile"></a>OBR Repository File</h2> |
| |
| <p>The OBR repository file is an XML-based representation of bundle |
| meta-data. The goal is provide a generic model for describing |
| dependencies among resources; as such, the term <em><b>resource</b></em> is used instead of <em><b>bundle</b></em> in the OBR repository syntax; a detailed description of the OBR meta-data format is available in the <a href="http://www2.osgi.org/download/rfc-0112_BundleRepository.pdf" rel="nofollow">OSGi RFC 112</a> |
| document; this document is not completely in sync with the |
| implementation, but the concepts are still correct. The following XML |
| snippet depicts the overall structure of a repository file:</p> |
| |
| <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> |
| <pre><repository presentationname="..." symbolicname="..." ... > |
| <resource> |
| <description>...</description> |
| <size>...</size> |
| <documentation>...</documentation> |
| <source>...</source> |
| <category id="..."/> |
| <capability>...</capability> |
| ... |
| <requirement>...</requirement> |
| ... |
| </resource> |
| ... |
| </repository> |
| </pre> |
| </div></div> |
| |
| <p>The above repository defines a set of available resources, each |
| described by a set of meta-data. Some resource meta-data is purely |
| intended for human consumption; the most important aspects relate to |
| the generic capability/requirement model.</p> |
| |
| <p>A resource can provide any number of capabilities. A capability is a |
| typed set of properties. For example, the following is an exported |
| package capability:</p> |
| |
| <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> |
| <pre><capability name='package'> |
| <p n='package' v='org.foo.bar'/> |
| <p n='version' t='version' v='1.0.0'/> |
| </capability> |
| </pre> |
| </div></div> |
| |
| <p>This capability is of type 'package' and exports 'org.foo.bar' at |
| version '1.0.0'. Conversely, a requirement is a typed LDAP query over a |
| set of capability properties. For example, the following is an imported |
| package requirement:</p> |
| |
| <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> |
| <pre><require name='package' extend='false' |
| multiple='false' optional='false' |
| filter='(&amp;(package=org.foo.bar)(version&gt;=1.0.0))'> |
| Import package org.foo.bar |
| </require> |
| </pre> |
| </div></div> |
| |
| <p>This requirement is of type 'package' and imports 'org.foo.bar' at |
| versions greater than '1.0.0'. Although this syntax looks rather |
| complicated with the '\&' and '\>=' syntax, it is simply the |
| standard OSGi LDAP query syntax in XML form (additionally, Peter Kriens |
| has created a tool called <tt>bindex</tt> to generate this meta-data from a bundle's manifest).</p> |
| |
| <p>With this generic dependency model, OBR is able to provide mappings |
| for the various OSGi bundle dependencies; e.g., import/export package, |
| provide/require bundle, host/fragment, import/export service, execution |
| environment, and native code. In addition, it is possible for bundles |
| to introduce arbitrary dependencies for custom purposes.</p> |
| |
| <p>Two other important pieces of meta-data are <tt>Bundle-SymbolicName</tt> and <tt>Bundle-Version</tt>; |
| these are standard OSGi bundle manifest attributes that OBR uses to |
| uniquely identify a bundle. For example, if you want to use OBR to |
| update a locally installed bundle, OBR gets its symbolic name and |
| version and searches the repository metadata for a matching symbolic |
| name. If the matching symbolic name is found, then OBR checks if there |
| is a newer version than the local copy using the bundle version number. |
| Thus, the symbolic name plus bundle version forms a unique key to match |
| locally installed bundles to remotely available bundles.</p> |
| |
| <p><a name="ApacheFelixOSGiBundleRepository-serviceapi"></a></p> |
| |
| <h2><a name="ApacheFelixOSGiBundleRepository-OBRServiceAPI"></a>OBR Service API</h2> |
| |
| <p>Typically, OBR service clients only need to interact with the |
| Repository Admin service, which provides the mechanisms necessary to |
| discover available resources. The Repository Admin interface is defined |
| as follows:</p> |
| |
| <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> |
| <pre class="code-java"><span class="code-keyword">public</span> <span class="code-keyword">interface</span> RepositoryAdmin |
| { |
| <span class="code-keyword">public</span> Resource[] discoverResources(<span class="code-object">String</span> filterExpr); |
| <span class="code-keyword">public</span> Resolver resolver(); |
| <span class="code-keyword">public</span> Repository addRepository(URL repository)? |
| <span class="code-keyword">throws</span> Exception; |
| <span class="code-keyword">public</span> <span class="code-object">boolean</span> removeRepository(URL repository); |
| <span class="code-keyword">public</span> Repository[] listRepositories(); |
| <span class="code-keyword">public</span> Resource getResource(<span class="code-object">String</span> respositoryId); |
| } |
| </pre> |
| </div></div> |
| |
| <p>In order to resolve and deploy available resources, the Repository |
| Admin provides Resolver instances, which are defined as follows:</p> |
| |
| <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> |
| <pre class="code-java"><span class="code-keyword">public</span> <span class="code-keyword">interface</span> Resolver |
| { |
| <span class="code-keyword">public</span> void add(Resource resource); |
| <span class="code-keyword">public</span> Requirement[] getUnsatisfiedRequirements(); |
| <span class="code-keyword">public</span> Resource[] getOptionalResources(); |
| <span class="code-keyword">public</span> Requirement[] getReason(Resource resource); |
| <span class="code-keyword">public</span> Resource[] getResources(Requirement requirement); |
| <span class="code-keyword">public</span> Resource[] getRequiredResources(); |
| <span class="code-keyword">public</span> Resource[] getAddedResources(); |
| <span class="code-keyword">public</span> <span class="code-object">boolean</span> resolve(); |
| <span class="code-keyword">public</span> void deploy(<span class="code-object">boolean</span> start); |
| } |
| </pre> |
| </div></div> |
| |
| <p>When desired resources are discovered via the query mechanisms of |
| the Repository Admin, they are added to a Resolver instance which will |
| can be used to resolve all transitive dependencies and to reflect on |
| any resolution result. The following code snippet depicts a typical |
| usage scenario:</p> |
| |
| <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> |
| <pre class="code-java">RepositoryAdmin repoAdmin = ... <span class="code-comment">// Get repo admin service |
| </span>Resolver resolver = repoAdmin.resolver(); |
| Resource resource = repoAdmin.discoverResources(filterStr); |
| resolver.add(resource); |
| <span class="code-keyword">if</span> (resolver.resolve()) |
| { |
| resolver.deploy(<span class="code-keyword">true</span>); |
| } |
| <span class="code-keyword">else</span> |
| { |
| Requirement[] reqs = resolver.getUnsatisfiedRequirements(); |
| <span class="code-keyword">for</span> (<span class="code-object">int</span> i = 0; i < reqs.length; i++) |
| { |
| <span class="code-object">System</span>.out.println(<span class="code-quote">"Unable to resolve: "</span> + reqs[i]); |
| } |
| } |
| </pre> |
| </div></div> |
| |
| <p>This code gets the Repository Admin service and then gets a Resolver |
| instance from it. It then discovers an available resource and adds it |
| to the resolver. Then it tries to resolve the resources dependencies. |
| If successful it deploys the resource to the local framework instance; |
| if not successful it prints the unsatisfied requirements.</p> |
| |
| <p>OBR's deployment algorithm appears simple at first glance, but it is |
| actually somewhat complex due to the nature of deploying independently |
| developed bundles. For example, in an ideal world, if an update for a |
| bundle is made available, then updates for all of the bundles |
| satisfying its dependencies are also made available. Unfortunately, |
| this may not be the case, thus the deployment algorithm might have to |
| install new bundles during an update to satisfy either new dependencies |
| or updated dependencies that can no longer be satisfied by existing |
| local bundles. In response to this type of scenario, the OBR deployment |
| algorithm tries to favor updating existing bundles, if possible, as |
| opposed to installing new bundles to satisfy dependencies.</p> |
| |
| <p>In the general case, OBR user's will not use the OBR API directly, |
| but will use its functionality indirectly from another tool or user |
| interface. For example, interactive access to OBR is available via a |
| command for Felix' <a href="http://cwiki.apache.org/confluence/display/FELIX/Apache%20Felix%20Shell%20Service" title="Apache Felix Shell Service">shell service</a>. The OBR shell command is discussed in the next section.</p> |
| |
| <p><a name="ApacheFelixOSGiBundleRepository-shellcommand"></a></p> |
| |
| <h2><a name="ApacheFelixOSGiBundleRepository-OBRShellCommand"></a>OBR Shell Command</h2> |
| |
| <p>Besides providing a service API, OBR implements a Felix shell |
| command for accessing its functionality. For the end user, the OBR |
| shell command is accessed using the text-based or GUI-based user |
| interfaces for Felix' shell service. This section describes the syntax |
| for the OBR shell command.</p> |
| |
| <p><a name="ApacheFelixOSGiBundleRepository-obrhelp"></a></p> |
| |
| <h3><a name="ApacheFelixOSGiBundleRepository-obrhelp"></a>obr help</h3> |
| |
| <p>Syntax:</p> |
| <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> |
| <pre>obr help [add-url | remove-url | list-url | list | info | deploy | start | source | javadoc] |
| </pre> |
| </div></div> |
| <p>This command is used to display additional information about the other OBR commands.</p> |
| |
| <p><a name="ApacheFelixOSGiBundleRepository-obrlisturl"></a></p> |
| |
| <h3><a name="ApacheFelixOSGiBundleRepository-obrlisturl"></a>obr list-url</h3> |
| |
| <p>Syntax:</p> |
| <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> |
| <pre>obr list-url |
| </pre> |
| </div></div> |
| <p>This command gets the URLs to the repository files used by the Repository Admin.</p> |
| |
| <p><a name="ApacheFelixOSGiBundleRepository-obraddurl"></a></p> |
| |
| <h3><a name="ApacheFelixOSGiBundleRepository-obraddurl"></a>obr add-url</h3> |
| |
| <p>Syntax:</p> |
| <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> |
| <pre>obr add-url [<repository-file-url> ...] |
| </pre> |
| </div></div> |
| <p>This command adds a repository file to the set of repository files |
| for which the Repository Admin service provides access. The repository |
| file is represented as a URL. If the repository file URL is already in |
| the Repository Admin's set of repository files, the request is treated |
| like a reload operation.</p> |
| |
| <p><a name="ApacheFelixOSGiBundleRepository-obrremoveurl"></a></p> |
| |
| <h3><a name="ApacheFelixOSGiBundleRepository-obrremoveurl"></a>obr remove-url</h3> |
| |
| <p>Syntax:</p> |
| <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> |
| <pre>obr remove-url [<repository-file-url> ...] |
| </pre> |
| </div></div> |
| <p>This command removes a repository file to the set of repository |
| files for which the Repository Admin service provides access. The |
| repository file is represented as a URL.</p> |
| |
| <p><a name="ApacheFelixOSGiBundleRepository-obrlist"></a></p> |
| |
| <h3><a name="ApacheFelixOSGiBundleRepository-obrlist"></a>obr list</h3> |
| |
| <p>Syntax:</p> |
| <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> |
| <pre>obr list [<string> ...] |
| </pre> |
| </div></div> |
| <p>This command lists bundles available in the bundle repository. If no |
| arguments are specified, then all available bundles are listed, |
| otherwise any arguments are concatenated with spaces and used as a |
| substring filter on the bundle names.</p> |
| |
| <p><a name="ApacheFelixOSGiBundleRepository-obrinfo"></a></p> |
| |
| <h3><a name="ApacheFelixOSGiBundleRepository-obrinfo"></a>obr info</h3> |
| |
| <p>Syntax:</p> |
| <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> |
| <pre>obr info <bundle-name>[;<version>] ... |
| </pre> |
| </div></div> |
| <p>This command displays the meta-data for the specified bundles. If a |
| bundle's name contains spaces, then it must be surrounded by quotes. It |
| is also possible to specify a precise version if more than one version |
| exists, such as:</p> |
| <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> |
| <pre>obr info "Bundle Repository";1.0.0 |
| </pre> |
| </div></div> |
| <p>The above example retrieves the meta-data for version "1.0.0" of the bundle named "Bundle Repository".</p> |
| |
| <p><a name="ApacheFelixOSGiBundleRepository-obrdeploy"></a></p> |
| |
| <h3><a name="ApacheFelixOSGiBundleRepository-obrdeploy"></a>obr deploy</h3> |
| |
| <p>Syntax:</p> |
| <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> |
| <pre>obr deploy <bundle-name>[;<version>] ... | <bundle-id> ... |
| </pre> |
| </div></div> |
| <p>This command tries to install or update the specified bundles and |
| all of their dependencies by default. You can specify either the bundle |
| name or the bundle identifier. If a bundle's name contains spaces, then |
| it must be surrounded by quotes. It is also possible to specify a |
| precise version if more than one version exists, such as:</p> |
| <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> |
| <pre>obr deploy "Bundle Repository";1.0.0 |
| </pre> |
| </div></div> |
| <p>For the above example, if version "1.0.0" of "Bundle Repository" is |
| already installed locally, then the command will attempt to update it |
| and all of its dependencies; otherwise, the command will install it and |
| all of its dependencies.</p> |
| |
| <p><a name="ApacheFelixOSGiBundleRepository-obrstart"></a></p> |
| |
| <h3><a name="ApacheFelixOSGiBundleRepository-obrstart"></a>obr start</h3> |
| |
| <p>Syntax:</p> |
| <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> |
| <pre>obr start [-nodeps] <bundle-name>[;<version>] ... |
| </pre> |
| </div></div> |
| <p>This command installs and starts the specified bundles and all of |
| their dependencies by default; use the "-nodeps" switch to ignore |
| dependencies. If a bundle's name contains spaces, then it must be |
| surrounded by quotes. If a specified bundle is already installed, then |
| this command has no effect. It is also possible to specify a precise |
| version if more than one version exists, such as:</p> |
| <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> |
| <pre>obr start "Bundle Repository";1.0.0 |
| </pre> |
| </div></div> |
| <p>The above example installs and starts the "1.0.0" version of the bundle named "Bundle Repository" and its dependencies.</p> |
| |
| <p><a name="ApacheFelixOSGiBundleRepository-obrsource"></a></p> |
| |
| <h3><a name="ApacheFelixOSGiBundleRepository-obrsource"></a>obr source</h3> |
| |
| <p>Syntax:</p> |
| <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> |
| <pre>obr source [-x] <local-dir> <bundle-name>[;<version>] ... |
| </pre> |
| </div></div> |
| <p>This command retrieves the source archives of the specified bundles |
| and saves them to the specified local directory; use the "-x" switch to |
| automatically extract the source archives. If a bundle name contains |
| spaces, then it must be surrounded by quotes. It is also possible to |
| specify a precise version if more than one version exists, such as:</p> |
| <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> |
| <pre>obr source /home/rickhall/tmp "Bundle Repository";1.0.0 |
| </pre> |
| </div></div> |
| <p>The above example retrieves the source archive of version "1.0.0" of |
| the bundle named "Bundle Repository" and saves it to the specified |
| local directory.</p> |
| |
| <h3><a name="ApacheFelixOSGiBundleRepository-obrjavadoc"></a>obr javadoc</h3> |
| |
| <p>Syntax:</p> |
| <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> |
| <pre>obr javadoc [-x] <local-dir> <bundle-name>[;<version>] ... |
| </pre> |
| </div></div> |
| <p>This command retrieves the javadoc archives of the specified bundles |
| and saves them to the specified local directory; use the "-x" switch to |
| automatically extract the javadoc archives. If a bundle name contains |
| spaces, then it must be surrounded by quotes. It is also possible to |
| specify a precise version if more than one version exists, such as:</p> |
| <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> |
| <pre>obr javadoc /home/rickhall/tmp "Bundle Repository";1.0.0 |
| </pre> |
| </div></div> |
| <p>The above example retrieves the javadoc archive of version "1.0.0" |
| of the bundle named "Bundle Repository" and saves it to the specified |
| local directory.</p> |
| |
| <p><a name="ApacheFelixOSGiBundleRepository-proxy"></a></p> |
| |
| <h2><a name="ApacheFelixOSGiBundleRepository-UsingOBRwithaProxy"></a>Using OBR with a Proxy</h2> |
| |
| <p>If you use a proxy for Web access, then OBR will not work for you in |
| its default configuration; certain system properties must be set to |
| enable OBR to work with a proxy. These properties are:</p> |
| |
| <ul> |
| <li>http.proxyHost - the name of the proxy host.</li> |
| <li>http.proxyPort - the port of the proxy host.</li> |
| <li>http.proxyAuth |
| - the user name and password to use when connecting to the proxy; this |
| string should be the user name and password separated by a colon (e.g., |
| rickhall:mypassword).</li> |
| </ul> |
| |
| |
| <p>These system properties can be set directly on the command line when |
| starting the JVM using the standard "-D<prop>=<value>" |
| syntax or you can put them in the lib/system.properties file of your |
| Felix installation; see documentation on configuring Felix for more |
| information.</p> |
| |
| <p><a name="ApacheFelixOSGiBundleRepository-sourcepackaging"></a></p> |
| |
| <h2><a name="ApacheFelixOSGiBundleRepository-BundleSourcePackaging"></a>Bundle Source Packaging</h2> |
| |
| <p>Coming soon...</p> |
| |
| <p><a name="ApacheFelixOSGiBundleRepository-r3note"></a></p> |
| |
| <h2><a name="ApacheFelixOSGiBundleRepository-NoteonOSGiR3Bundles"></a>Note on OSGi R3 Bundles</h2> |
| |
| <p>In contrast to OSGi R4 the previous specifications, most notably R3, allowed bundles without the <tt>Bundle-SymbolicName</tt> |
| header. The Felix OSGi Bundle Repository implementation heavily relies |
| on the symbolic name being defined in bundles. As a consequence bundles |
| without a symbolic name are not fully supported by the Bundle |
| Repository:</p> |
| |
| <ul> |
| <li>Bundles installed in the framework are used by the Bundle |
| Repository implementation to resolve dependencies regardless of whether |
| they have a <tt>Bundle-SymbolicName</tt> header or not. Resolution of dependencies against the installed bundles takes place based on the <tt>Export-Package</tt> headers.</li> |
| <li>Bundles installed in the framework without a <tt>Bundle-SymbolicName</tt> |
| header cannot be updated by the Bundle Repository implementation |
| because updates from the bundle repository cannot be correlated to such |
| "anonymous" bundles.</li> |
| </ul> |
| |
| |
| |
| <p><a name="ApacheFelixOSGiBundleRepository-feedback"></a></p> |
| |
| <h2><a name="ApacheFelixOSGiBundleRepository-Feedback"></a>Feedback</h2> |
| |
| <p>Subscribe to the Felix users mailing list by sending a message to <a href="mailto:users-subscribe@felix.apache.org" rel="nofollow">users-subscribe@felix.apache.org</a>; after subscribing, email questions or feedback to <a href="mailto:users@felix.apache.org" rel="nofollow">users@felix.apache.org</a>.</p> |
| </div> |
| </body></html> |
