Hi, I updated the site now (removed the trailing OBR abbreviation) and adapted the pom.xml with the modified URL.
Regards Felix Richard S. Hall schrieb: > Felix Meschberger wrote: >> Hi, >> >> Richard S. Hall schrieb: >> >>> If we are going to edit the page to not have parentheses, then we might >>> as well get rid of the "OBR" too since it doesn't really make sense the >>> way it is now without them... >>> >> >> Agreed. >> >> But if I had removed it completely, the URL would have changed. And this >> I considered a bigger problem, especially since the URL is also referred >> to in the bundlerepository bundle. >> > > In Bundle-DocURL? > >> On the other hand this title is visible in two places AFAICT: The window >> title of the browser and in the table of contents of the Subproject >> Documentation page. Both are generated automatically from the page name. >> >> >> WDYT ? >> > > Well, if we don't want to break the manifest metadata, then we should > open an issue to fix it on the next release of the bundle repository, I > guess. Then it can be updated everywhere. The only other option would be > to set up some sort of redirect, but then we would still have to > remember to edit it for the next release of the bundle, so that approach > doesn't seem much better. > > -> richard > >> Regards >> Felix >> >> >>> -> richard >>> >>> >>> [EMAIL PROTECTED] wrote: >>> >>>> Page Edited : FELIX <http://cwiki.apache.org/confluence/display/FELIX> >>>> : Apache Felix OSGi Bundle Repository OBR >>>> <http://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+OSGi+Bundle+Repository+OBR> >>>> >>>> >>>> >>>> Apache Felix OSGi Bundle Repository OBR >>>> <http://cwiki.apache.org/confluence/display/FELIX/Apache+Felix+OSGi+Bundle+Repository+OBR> >>>> >>>> has been edited by Felix Meschberger >>>> <http://cwiki.apache.org/confluence/display/%7Efmeschbe> (Sep 10, >>>> 2008). >>>> >>>> Change summary: >>>> >>>> Remove brackets from page name >>>> >>>> (View changes) >>>> <http://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=7950&originalVersion=15&revisedVersion=16> >>>> >>>> >>>> >>>> Content: >>>> >>>> >>>> Apache Felix OSGi Bundle Repository (OBR) >>>> >>>> * Motivation <#ApacheFelixOSGiBundleRepositoryOBR-Motivation> >>>> * Overview <#ApacheFelixOSGiBundleRepositoryOBR-Overview> >>>> * OBR Repository File >>>> <#ApacheFelixOSGiBundleRepositoryOBR-OBRRepositoryFile> >>>> * OBR Service API >>>> <#ApacheFelixOSGiBundleRepositoryOBR-OBRServiceAPI> >>>> * OBR Shell Command >>>> <#ApacheFelixOSGiBundleRepositoryOBR-OBRShellCommand> >>>> o obr help >>>> <#ApacheFelixOSGiBundleRepositoryOBR-%7B%7Bobrhelp%7D%7D> >>>> o obr list-url >>>> >>>> <#ApacheFelixOSGiBundleRepositoryOBR-%7B%7Bobrlisturl%7D%7D> >>>> o obr add-url >>>> <#ApacheFelixOSGiBundleRepositoryOBR-%7B%7Bobraddurl%7D%7D> >>>> o obr remove-url >>>> >>>> <#ApacheFelixOSGiBundleRepositoryOBR-%7B%7Bobrremoveurl%7D%7D> >>>> o obr list >>>> <#ApacheFelixOSGiBundleRepositoryOBR-%7B%7Bobrlist%7D%7D> >>>> o obr info >>>> <#ApacheFelixOSGiBundleRepositoryOBR-%7B%7Bobrinfo%7D%7D> >>>> o obr deploy >>>> <#ApacheFelixOSGiBundleRepositoryOBR-%7B%7Bobrdeploy%7D%7D> >>>> o obr start >>>> <#ApacheFelixOSGiBundleRepositoryOBR-%7B%7Bobrstart%7D%7D> >>>> o obr source >>>> <#ApacheFelixOSGiBundleRepositoryOBR-%7B%7Bobrsource%7D%7D> >>>> o obr javadoc >>>> >>>> <#ApacheFelixOSGiBundleRepositoryOBR-%7B%7Bobrjavadoc%7D%7D> >>>> * Using OBR with a Proxy >>>> <#ApacheFelixOSGiBundleRepositoryOBR-UsingOBRwithaProxy> >>>> * Bundle Source Packaging >>>> <#ApacheFelixOSGiBundleRepositoryOBR-BundleSourcePackaging> >>>> * Note on OSGi R3 Bundles >>>> <#ApacheFelixOSGiBundleRepositoryOBR-NoteonOSGiR3Bundles> >>>> * Feedback <#ApacheFelixOSGiBundleRepositoryOBR-Feedback> >>>> >>>> >>>> Motivation >>>> >>>> The goal of the Apache Felix OSGi Bundle Repository (OBR) is two-fold: >>>> >>>> 1. To simplify deploying and using available bundles with Felix. >>>> 2. To encourage independent bundle development so that communities >>>> of interest can grow. >>>> >>>> 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. >>>> >>>> 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 obr >>>> list-url, obr add-url, and obr remove-url commands for more details. >>>> >>>> >>>> Overview >>>> >>>> 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. >>>> >>>> OBR defines the following entities: >>>> >>>> * /*Repository Admin*/ - a service to access a federation of >>>> repositories. >>>> * /*Repository*/ - provides access to a set of resources. >>>> * /*Resource*/ - a description of an artifact to be installed on a >>>> device. >>>> * /*Capability*/ - a named set of properties. >>>> * /*Requirement*/ - an assertion on a capability. >>>> * /*Resolver*/ - an object to resolve resource dependencies and to >>>> deploy them. >>>> * /*Repository file*/ - XML file containing resource meta-data. >>>> >>>> The following diagram illustrates the relationships among these >>>> entities: >>>> >>>> The client has access to a federated set of repositories via the >>>> Repository Admin service; such as depicted in this view: >>>> >>>> >>>> OBR Repository File >>>> >>>> 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 /*resource*/ is used >>>> instead of /*bundle*/ in the OBR repository syntax; a detailed >>>> description of the OBR meta-data format is available in the OSGi RFC >>>> 112^ <http://www2.osgi.org/download/rfc-0112_BundleRepository.pdf> >>>> 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: >>>> >>>> <repository presentationname="..." symbolicname="..." ... > >>>> <resource> >>>> <description>...</description> >>>> <size>...</size> >>>> <documentation>...</documentation> >>>> <source>...</source> >>>> <category id="..."/> >>>> <capability>...</capability> >>>> ... >>>> <requirement>...</requirement> >>>> ... >>>> </resource> >>>> ... >>>> </repository> >>>> 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. >>>> >>>> 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: >>>> >>>> <capability name='package'> >>>> <p n='package' v='org.foo.bar'/> >>>> <p n='version' t='version' v='1.0.0'/> >>>> </capability> >>>> 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: >>>> >>>> <require name='package' extend='false' >>>> multiple='false' optional='false' >>>> filter='(&(package=org.foo.bar)(version>=1.0.0))'> >>>> Import package org.foo.bar >>>> </require> >>>> 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 bindex to generate this meta-data from a >>>> bundle's manifest). >>>> >>>> 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. >>>> >>>> Two other important pieces of meta-data are Bundle-SymbolicName and >>>> Bundle-Version; 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. >>>> >>>> >>>> OBR Service API >>>> >>>> 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: >>>> >>>> public interface RepositoryAdmin >>>> { >>>> public Resource[] discoverResources(String filterExpr); >>>> public Resolver resolver(); >>>> public Repository addRepository(URL repository)? >>>> throws Exception; >>>> public boolean removeRepository(URL repository); >>>> public Repository[] listRepositories(); >>>> public Resource getResource(String respositoryId); >>>> } >>>> >>>> In order to resolve and deploy available resources, the Repository >>>> Admin provides Resolver instances, which are defined as follows: >>>> >>>> public interface Resolver >>>> { >>>> public void add(Resource resource); >>>> public Requirement[] getUnsatisfiedRequirements(); >>>> public Resource[] getOptionalResources(); >>>> public Requirement[] getReason(Resource resource); >>>> public Resource[] getResources(Requirement requirement); >>>> public Resource[] getRequiredResources(); >>>> public Resource[] getAddedResources(); >>>> public boolean resolve(); >>>> public void deploy(boolean start); >>>> } >>>> >>>> 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: >>>> >>>> RepositoryAdmin repoAdmin = ... // Get repo admin service >>>> Resolver resolver = repoAdmin.resolver(); >>>> Resource resource = repoAdmin.discoverResources(filterStr); >>>> resolver.add(resource); >>>> if (resolver.resolve()) >>>> { >>>> resolver.deploy(true); >>>> } >>>> else >>>> { >>>> Requirement[] reqs = resolver.getUnsatisfiedRequirements(); >>>> for (int i = 0; i < reqs.length; i++) >>>> { >>>> System.out.println("Unable to resolve: " + reqs[i]); >>>> } >>>> } >>>> >>>> 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. >>>> >>>> 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. >>>> >>>> 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' shell service >>>> </confluence/display/FELIX/Apache+Felix+Shell+Service>. The OBR shell >>>> command is discussed in the next section. >>>> >>>> >>>> OBR Shell Command >>>> >>>> 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. >>>> >>>> >>>> obr help >>>> >>>> Syntax: >>>> >>>> obr help [add-url | remove-url | list-url | list | info | deploy | >>>> start | source | javadoc] >>>> This command is used to display additional information about >>>> the other >>>> OBR commands. >>>> >>>> >>>> obr list-url >>>> >>>> Syntax: >>>> >>>> obr list-url >>>> This command gets the URLs to the repository files used by the >>>> Repository Admin. >>>> >>>> >>>> obr add-url >>>> >>>> Syntax: >>>> >>>> obr add-url [<repository-file-url> ...] >>>> 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. >>>> >>>> >>>> obr remove-url >>>> >>>> Syntax: >>>> >>>> obr remove-url [<repository-file-url> ...] >>>> 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. >>>> >>>> >>>> obr list >>>> >>>> Syntax: >>>> >>>> obr list [<string> ...] >>>> 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. >>>> >>>> >>>> obr info >>>> >>>> Syntax: >>>> >>>> obr info <bundle-name>[;<version>] ... >>>> 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: >>>> >>>> obr info "Bundle Repository";1.0.0 >>>> The above example retrieves the meta-data for version "1.0.0" >>>> of the >>>> bundle named "Bundle Repository". >>>> >>>> >>>> obr deploy >>>> >>>> Syntax: >>>> >>>> obr deploy <bundle-name>[;<version>] ... | <bundle-id> ... >>>> 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: >>>> >>>> obr deploy "Bundle Repository";1.0.0 >>>> 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. >>>> >>>> >>>> obr start >>>> >>>> Syntax: >>>> >>>> obr start [-nodeps] <bundle-name>[;<version>] ... >>>> 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: >>>> >>>> obr start "Bundle Repository";1.0.0 >>>> The above example installs and starts the "1.0.0" version of the >>>> bundle named "Bundle Repository" and its dependencies. >>>> >>>> >>>> obr source >>>> >>>> Syntax: >>>> >>>> obr source [-x] <local-dir> <bundle-name>[;<version>] ... >>>> 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: >>>> >>>> obr source /home/rickhall/tmp "Bundle Repository";1.0.0 >>>> 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. >>>> >>>> >>>> obr javadoc >>>> >>>> Syntax: >>>> >>>> obr javadoc [-x] <local-dir> <bundle-name>[;<version>] ... >>>> 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: >>>> >>>> obr javadoc /home/rickhall/tmp "Bundle Repository";1.0.0 >>>> 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. >>>> >>>> >>>> Using OBR with a Proxy >>>> >>>> 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: >>>> >>>> * http.proxyHost - the name of the proxy host. >>>> * http.proxyPort - the port of the proxy host. >>>> * 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). >>>> >>>> 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. >>>> >>>> >>>> Bundle Source Packaging >>>> >>>> Coming soon... >>>> >>>> >>>> Note on OSGi R3 Bundles >>>> >>>> In contrast to OSGi R4 the previous specifications, most notably R3, >>>> allowed bundles without the Bundle-SymbolicName 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: >>>> >>>> * Bundles installed in the framework are used by the Bundle >>>> Repository implementation to resolve dependencies regardless of >>>> whether they have a Bundle-SymbolicName header or not. >>>> Resolution of dependencies against the installed bundles takes >>>> place based on the Export-Package headers. >>>> * Bundles installed in the framework without a Bundle-SymbolicName >>>> header cannot be updated by the Bundle Repository implementation >>>> because updates from the bundle repository cannot be correlated >>>> to such "anonymous" bundles. >>>> >>>> >>>> Feedback >>>> >>>> Subscribe to the Felix users mailing list by sending a message to >>>> [EMAIL PROTECTED] >>>> <mailto:[EMAIL PROTECTED]>; after subscribing, email >>>> questions or feedback to [EMAIL PROTECTED] >>>> <mailto:[EMAIL PROTECTED]>. >>>> >>>> Powered by Atlassian Confluence >>>> <http://www.atlassian.com/software/confluence/default.jsp?clicked=footer> >>>> >>>> (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request >>>> <http://jira.atlassian.com/secure/BrowseProject.jspa?id=10470> >>>> >>>> Unsubscribe or edit your notifications preferences >>>> <http://cwiki.apache.org/confluence/users/viewnotifications.action> >>>> >
