Conversion of of Maven dependencies
Bulk of OSGi bundle manifest generation seems to boil down to converting maven <dependency/> into either Require-Bundle or Import-Package OSGi manifest attributes.
Generation of Require-Bundle
TODO Artifact groupId/artifactId -> bundle symbolic name translation.
Parameters
- version - comes from dependency version. need to deal with version ranges too.
- visibility - "private" (the Default), maven resolves dependencies transitively, so no need to use "reexport"
- resolution - "mandatory" (the Default) or "optional" depending on "optional" dependency attribute
Generation of Import-Package
Find responsible dependency artifact
- Scan package classes for all referenced packages
- Then scan dependency artifact jars to find artifact the packages come from
- Referenced packages that do not appear to come from any dependency are logged and ignored
Parameters
- resolution - "mandatory" (the Default) or "optional" depending on "optional" dependency attribute
- version - based on version dependency attribute
- bundle-symbolic-name and bundle-version - no need... right?
Alternatively, instead of matching imported packages to artifacts, we can probably define some pattern-based rules in pom. Neither of the approaches seems bullet-proof, however.
Dependencies on other OSGi bundles
Different scopes
- compile can be converted into either Require-Bundle or Import-Package
- runtime ???
- provided/system can only be converted into Import-Package
- test ???
Import-Package and Require-Bundle version range should match dependency version (are there dependency ranges in maven?).
Likewise, optional dependency attribute should result in optional Import-Package/Require-Bundle.
Dependencies on non-bundles
- compile can be converted into Import-Package or packaged into the bundle as jar file or class folder and added to Bundle-ClassPath.
- runtime ???
- provided/system can only be converted into Import-Package
- test ???
Generation of Export-Package
Exported packages are defined using patterns
- Pro
- Humane
- Con
- Requires compiled and processed classes and can only be generated at the very end of "process-classes" phase.
- Cannot be used to calculate project dependencies
Static list of exported packages
- Pro
- Can be used to calculate project dependencies
- Can be used to configure compilation classpath access rules
- Con
- Impossible to maintain by hand
