Bundles and Plug-in Projects

A bundle is an OSGI mechanism for grouping Java classes into a modular, sharable unit. In TIBCO Business Studio, a plug-in project implements a bundle.

Plug-in properties, including the packages it exports and the objects on which it depends, are described in the plug-in manifest. The manifest file is located in plug-inFolderNameMETA-IF/MANIFEST.MF. The default editor for the file is a manifest editor which displays OSGi headers in property sheets and in the MANIFEST.MF source view. Plug-in Project Best Practices summarizes the best practices you should follow when configuring plug-ins.
Plug-in Project Best Practices
Property Manifest Editor UI OSGi Header in Source View Best Practice
Unique Identifier Overview > ID Bundle-SymbolicName Give the plug-in a symbolic name that follows Java package name conventions. That is, com.companyName.plug-inName.
Version Overview > Version Bundle-Version Follow the recommendations in Versions.
Display Name Overview > Name Bundle-Name Give the plug-in an appropriate, descriptive display name.
Dependencies Dependencies >

Imported Packages

Required Plug-ins

Import-Package

Require-Bundle

  • Express dependencies based on the contents of the plug-in:
    • For plug-ins that you create or if you want tight control of the dependency, specify the dependency as a required bundle. You can (but are not required to) indicate a perfect match to a specific plug-in and build. For example, when TIBCO Business Studio generates a component implementation, the component's dependency on the plug-in containing the component implementation is expressed as [1.0.0.qualifier,1.0.0.qualifier].
    • For third-party plug-ins, specify the dependency as an imported package. To allow packages to be upgraded without requiring plug-ins dependent on those packages to be upgraded, specify package dependency ranges of the form [x.y.z,x+1.0.0). That is, up to, but not including the next major version. For example, [2.3.0, 3.0.0).
  • Minimize or eliminate optional imports.
Exported Packages Runtime > Exported Packages Export-Package
  • Export only those packages imported by other plug-ins.
  • Put classes that are not exported in packages that are not exported.
  • Specify versions of all exported packages.
  • Import all exported packages, with a range floor of the exported package version, and a range ceiling of the next major version exclusive, per the range definition above.
  • If the classes in the exported packages use other classes (for example, they extend classes from another package or the classes appear in method signatures) add the uses directive to the export package definition.