Header Rules

Determining required Execution Environment (EE)

Set via configuration (additional header or specific parameter)
Derived from highest major version digest of the bundles class files (done)
Use lowes (known) EE satisfying the bundles external package references (exclude packages from referenced bundles with isProvided = false) (done)
~~Use default (configurable)~~ (not necessary, because we find always the best possible EE)

Filter "public" packages of required EE (see attachment:OSGiBestPractices.pdf slide 12) (done)
(optional) !**.impl.**, !**.internal.** (configurable)
(optional) Export filtered packages from 2.) with x-friends:="" directive for tests (if referenced, configurable)
(optional) Export filtered packages from 2.) with x-internal:=true. Note: Don't add x-internal:=true to exports already marked with the x-friends directive: "the 'x-friends' directive has no effect in the presence of the 'x-internal' directive".

Resolve version from package ** packageinfo file (done) ** bnd annotation ** own annotation ** Mojo configuration
If not present, use bundle version (done) or default to 0.0.0 (configurable)
Set default version for packages contained in FAMILY of required EE (public and vendor packages) (done)

Import packages referenced from class files (done)
Import additional packages from configuration (configurable)
Import exported packages (http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html) (done) ** Ignore exported packages refering to a private package (http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html) ** Ignore exported packages where there is no private package referring to the exported package (http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html)
Apply configured filter (configurable)
Filter "public" packages of required EE (done)
Mark unresolvable packages as optional (done) or ignore them (configurable)

Strict version when package is internal (x-friends or x-internal:=true)
Strict version if current bundle exports the current package (internal implementations may not implement future features (even if API is backwards compatible, e.g. new methods to implement) (done)
Default Version if package is exported with default version (done)
Default version if package is contained in FAMILY of required EE (public and vendor packages) (done)
Use the Version of the exported package to determine the import version range: ** default version -> default version (done) ** version -> if fits in version range of bundle reference -> version range (done), otherweise go on with points below (currently, the package version will be used) ** version of external public package -> to range ** version of external private package -> strict version

If BundleReference to exporter is marked as optional (done)
If package is contained in vendor specific packages of required EEs FAMILY (???)

If bundle makes use of Class.forName (attachment:OSGiBestPractices.pdf slide 18) (done)
Configured via additional header (configurable)

!!! Currently not supported !!!

Option 1: Place all code in a single plug-in
Option 2: Place test code in a separate plug-in ** In Maven test classes are usually contained in a different source folder but in a package which is named like the package of the testet under test. -> Leads to "Class not found" in OSGi, because of separate class loaders for each bundle
Option 3: Place test code in a fragment ** It is not possible to share code between fragments.. reuse of test harness classes or creation of a master test suite nearly impossible

EE Jars on OSGi page? (attachment:OSGiBestPractices.pdf slide 9) -> ee.foundation, ee.minimum
Do notassume that everything in the Java Runtime Environment (JRE) will be available to your bundle. Only java.* packages are reliably available from the boot class path. (slide 12)
Hide Implementation Details: Do not export the implementation packages•Export and/or import the public details while keeping the implementation details private (slide 16)
Workaround for using Class.forName: Use @DynamicImport-Package: *@ This may work but can result in unintended side effects since your bundle may import packages it did not expect (slide 18)
A bundle should import all packages it exports. But "there are two rules where one should not import an exported package: (http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html) ** An exported package refers to an private package ** There is no private package referring to the exported package"
x-friends and x-internal: http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fbundle_manifest.html