• 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
  • -sub FILE-SPEC ( ',' FILE-SPEC )*
    Builder

    Enable sub-bundles to build a set of .bnd files that use bnd.bnd file as a basis. The list of bnd files can be specified with wildcards.

    You can enable sub-bundles with the -sub instruction, to build a set of .bnd files that use the bnd.bnd file as a basis. The list of sub-.bnd files can be specified with wildcards.

    Example

    Assume a bundle com.example with a main bnd.bnd file:

    -sub *.bnd

    And besides the following files:

    • sub.bundle1.bnd
    • sub.bundle2.bnd

    This will process every other .bnd file as a sub-bundle and will create a .jar file for it:

    • generated/com.example.sub.bundle1.jar
    • generated/com.example.sub.bundle2.jar

    The Bundle Symbolic Name for each sub bundle will be the name of the project + . + file name prefix of the sub bundle.

    Sub bundles are mostly treated as independent projects. They are part of the repositories and release process.

    The content of the sub .bnd files is as usual (see also Generating JARs).

    -buildpath and -classpath with sub-bundles

    The -buildpath is a project instruction. This means that it must be placed in the main bnd.bnd file, not in the sub-.bnd file. A project can only have a single -buildpath.

    Thus, in the sub bundle .bnd-files you have to use -classpath instead.

    Example:

    -classpath: \
    	${repo;org.apache.poi:poi;latest},\
    

    Use cases

    Gogo Commands

    A case where this approach is useful is, when you provide an implementation and want to separate the Gogo commands from the main code. In that case you create a main provider bundle and a Gogo bundle.

    In most cases it is best to have one project generate one bundle. However, sometimes it creates a lot of overhead and you’d like to be able to provide multiple bundles in a project since they share so much information.

    Wrapping JAR files

    Another use case is when you need to wrap .jar files, e.g. to convert non-OSGi bundles into OSGi-Bundles by adding meta-data to the Manifest. A practise to do so could be to have a single Wrapper-bundle where you do all your wrapping of external dependencies. The advantage is, that you don’t clutter up your workspace with lots of tiny Bundle-wrapping projects. With sub-bundles you can keep all your wrapped jars in one single project.

Search
    • Home