• Intro Headers Instructions Macros Commands
Fork me on GitHub
    • Getting Started
      • How to install bnd
      • Guided Tour
      • Guided Tour Workspace & Projects
      • FAQ - Frequently Asked Questions
    • Concepts and Practices
      • Introduction
      • Concepts
      • Best practices
    • Build and Development
      • Project Setup
      • Generating JARs
      • Versioning
      • Baselining
      • Service Components
      • Metatype
      • Contracts
      • Bundle Annotations
      • Accessor Properties
      • SPI Annotations
    • Dependency and Launching
      • Resolving Dependencies
      • Launching
      • Startlevels
    • Testing
      • Testing
      • Testing with Launchpad
    • Packaging and Distribution
      • Packaging Applications
      • JPMS Libraries
      • Wrapping Libraries to OSGi Bundles
    • Documentation and Tools
      • Generating Documentation
      • Commands
      • For Developers
      • Templates for Workspaces
      • Tips for Windows users
      • Tools bound to bnd
    • Reference Material
      • Reference
      • Headers
      • Instruction Reference
      • Instruction Index
      • Macro Reference
      • Macro Index
      • Plugins
      • External Plugins
    • Configuration and Troubleshooting
      • Settings
      • Errors
      • Warnings
  • -runbundles* REPO-ENTRY ( ',' REPO-ENTRY )*
    Project

    Add additional bundles, specified with their bsn and version like in -buildpath, that are installed and started before the project is run.

    The runbundles instruction is used to specify which bundles should be installed when a framework is started. This is the primary mechanism to run applications directly from bnd/bndtools. A bundle listed in -runbundles can be either a workspace bundle (a bundle created by one of the workspace’s projects) or a bundle from one of the configured repositories. Note that all required bundles to run the application should be listed, transitive dependencies are not handles automatically so that there is full control over the runtime.

    This list can be maintained manually it is normally calculated by the resolver. That is, when a resolve is run then it will, without warning, override this list.

    For example:

    -runbundles: \
    	org.apache.felix.configadmin;version='[1.8.8,1.8.9)',\
    	org.apache.felix.http.jetty;version='[3.2.0,3.2.1)',\
    	org.apache.felix.http.servlet-api;version='[1.1.2,1.1.3)',\
    	...
    	osgi.enroute.twitter.bootstrap.webresource;version='[3.3.5,3.3.6)',\
    	osgi.enroute.web.simple.provider;version='[2.1.0,2.1.1)'
    

    Start Levels

    Some launchers support startlevels and the -runbundles instruction therefore has a startlevel attribute. This attribute must be a positive integer larger than 0.

    -runbundles: \
    	org.apache.felix.configadmin;version='[1.8.8,1.8.9)'; startlevel=100,\
    	org.apache.felix.http.jetty;version='[3.2.0,3.2.1)'; startlevel=110,\
        ...
    

    Since the common workflow is to use the resolver to calculate the set of run bundles, any start level settings would be overridden after the next resolve. There are the following solutions.

    Use the -runstartlevel instruction to let the resolver calculate the start level ordering. In that case the resolver will add the startlevel attribute.

    Use the decoration facility. With the decoration facility you can augment the -runbundles instruction by specifying the -runbundles+ property (or the -runbundles++ if you want to add literals). The keys are glob expressions and any attributes or directives will be set (or overridden) on the merged -runbundles instruction.

    -runbundles: \
    	org.apache.felix.configadmin;version='[1.8.8,1.8.9)',\
    	org.apache.felix.http.jetty;version='[3.2.0,3.2.1)',\
    	org.apache.felix.http.servlet-api;version='[1.1.2,1.1.3)',\
    
    -runbundles+: \
        org.apache.felix.servlet-api;startlevel=100, \
        *;startlevel=110
    
Search
    • Home