Page History

Collection of OSGi conversion tips

...

jars with xmlbeans compilation

...

Also, any package we may have with "impl" or "internal" needs to be explicitly listed in the Export-Packages.Packages.

If the xmlbeans compilation is to be used by an xmlbeans compilation in another bundle (for example, the "environment" element defined in the geronimo-service-builder compilation), extra steps are needed to make these available. In the defining bundle, all of the generated classes AND all of the packages under the schemaorg_apache_xmlbeans directory need to be exported. Because the bnd tool omits impl directories by default, these must be explicitly listed. Here's a sample from the geronimo-service-builder:

                    <instructions>
                        <!--<_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))</_versionpolicy>-->
                        <Import-Package>org.apache.xmlbeans.impl.schema,*</Import-Package>
                        <Export-Package>
                            org.apache.geronimo.deployment.xbeans.impl,
                            org.apache.geronimo.deployment.javabean.xbeans.impl,
                            org.apache.geronimo.deployment.xbeans*,
                            org.apache.geronimo.deployment.javabean.xbeans*,
                            schemaorg_apache_xmlbeans*,
                            org.apache.geronimo.deployment.dconfigbean,
                            org.apache.geronimo.deployment.service*
                        </Export-Package>
                    </instructions>

On the importing side, all of these classes need to be imported as well. The schemaorg_apache_xmlbeans directory is a bit
problematic because the bnd tool cannot handle wild-cards on the import unless the packages are explicitly referenced in the
code. The schemaorg packages are not referenced in the code and generate lot of cryptically named directories that are difficult to transfer over to the importing side. For the schemaorg directories, DynamicImport-Package can be used. This example is from the geronimo-connector-builder-1_6 plugin:

                    <instructions>
                        <!--packages containing "impl" or "internal" are excluded by default -->
                        <Import-Package>org.apache.xmlbeans.impl.schema;version="2.4",org.apache.geronimo.deployment.xbeans.impl,org.apache.geronimo.deployment.javabean.xbeans.impl,*</Import-Package>
                        <DynamicImport-Package>schemaorg_apache_xmlbeans.*</DynamicImport-Package>
                        <!--<_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))</_versionpolicy>-->
                    </instructions>

If the xmlbeans compilation is to be used by an xmlbeans compilation in another bundle (for example, the "environment" element defined in the geronimo-service-builder compilation), extra steps are needed to make these available. In the defining bundle, all of the generated classes AND all of the packages under the schemaorg_apache_xmlbeans directory need to be exported. Because the bnd tool omits impl directories by default, these must be explicitly listed. Here's a sample from the geronimo-service-builder:

                    <instructions>
                        <!--<_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))</_versionpolicy>-->
                        <Import-Package>org.apache.xmlbeans.impl.schema,*</Import-Package>
                        <Export-Package>
                            org.apache.geronimo.deployment.xbeans.impl,
                            org.apache.geronimo.deployment.javabean.xbeans.impl,
                            org.apache.geronimo.deployment.xbeans*,
                            org.apache.geronimo.deployment.javabean.xbeans*,
                            schemaorg_apache_xmlbeans*,
                            org.apache.geronimo.deployment.dconfigbean,
                            org.apache.geronimo.deployment.service*
                        </Export-Package>
                    </instructions>

On the importing side, all of these classes need to be imported as well. The schemaorg_apache_xmlbeans directory is a bit
problematic because the bnd tool cannot handle wild-cards on the import unless the packages are explicitly referenced in the
code. The schemaorg packages are not referenced in the code and generate lot of cryptically named directories that are difficult to transfer over to the importing side. For the schemaorg directories, DynamicImport-Package can be used. This example is from the geronimo-connector-builder-1_6 plugin:

                    <instructions>
                        <!--packages containing "impl" or "internal" are excluded by default -->
                        <Import-Package>org.apache.xmlbeans.impl.schema;version="2.4",org.apache.geronimo.deployment.xbeans.impl,org.apache.geronimo.deployment.javabean.xbeans.impl,*</Import-Package>
                        <DynamicImport-Package>schemaorg_apache_xmlbeans.*</DynamicImport-Package>
                        <!--<_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))</_versionpolicy>-->
                    </instructions>

Non-bundle interference

Many problems with building plugins are caused by non-bundle dependencies getting installed in felix rather than bundleized equivalents. Unfortuneately it looks like felix only says "non-framework bundles cannot be started" without telling us the location of the non-bundle. Running

...

The pax-logging-api together with pax-logging-service provides a logging service in the OSGi environment that works with all commonly used logging API.

General OSGi tips

• The Bundle-ClassPath can refer to a directory within the bundle. Make sure there is an entry just for that directory in the JAR file of the bundle. Otherwise, classes might not be loaded from that directory.
• Always specify some wild mark in the filePattern (the second argument) in the bundle.findEntries() call to ensure the same set of entries is returned on different OSGi frameworks.