Make the project OSGi compatible #15
Conversation
This imports Bnd 4.3.0 and updates the build.xml script to produce OSGi manifests for each produced jar file (except for derbyrun, derbywar, and the locales jars). Currently, no attempt is made to reproduce the old Class-Path entries. These will be reconstructed when the locale jars have been upgraded to fragments. The Bundle-SymbolicName entries have been changed to match the JPMS module names, for consistency. Affects: https://issues.apache.org/jira/browse/DERBY-7056
This updates the build.xml script and Bnd configurations to add OSGi manifests to locale jars. Currently, no attempt is made to actually use these bundles, and no Class-Path entries have been added. Affects: https://issues.apache.org/jira/browse/DERBY-7056
This adds Fragment-Host headers for bundles, and refactors the build.xml file to improve the readability of the generation of bundles. Affects: https://issues.apache.org/jira/browse/DERBY-7056
This adds Class-Path attributes compatible with the existing 10.15.1.3 manifest headers. Affects: https://issues.apache.org/jira/browse/DERBY-7056
This removes the existing code from the BundleActivator, as per the discussion on DERBY-7056. Affects: https://issues.apache.org/jira/browse/DERBY-7056
| * | ||
|
|
||
| Export-Package: \ | ||
| org.apache.derby.agg, \ |
There was a problem hiding this comment.
I wonder if an Export-Package: org.apache.derby.* would be sufficient here.
There was a problem hiding this comment.
As for checking bnd into version control: I would normally never do this, but it seems that the project is already doing this for pretty much all of the build tools.
For Export-Package: If I remember correctly, there are packages that are not exported by the JPMS module definition. Exporting a package with OSGi that's not exported by the VM's module definition will result in trouble, won't it?
There was a problem hiding this comment.
Okay, maybe there are reasons why these packages are omitted, it just feels a lot of maintenance need to keep them in sync, but maybe this is for historical reasons.
I think you are right about the checked in tools didn't noticed that, maybe it would be good to use https://ant.apache.org/ivy/ instead, but that's a little bit out of scope here.
Lets see what the maintainers think about this.
There was a problem hiding this comment.
Okay, maybe there are reasons why these packages are omitted, it just feels a lot of maintenance need to keep them in sync
Yep. What I'm hoping is that the OSGi/Bnd people will come up with a way to calculate OSGi package exports from existing JPMS descriptors (if descriptors are present). This would eliminate the duplication.
|
Having OSGi bundles would help our PathVisio project a lot. |
This set of commits makes the following changes:
.bndfiles instead of raw.mfmanifest files, with thebndtool expanding properties inside the.bndfiles to produce manifests which are then inserted into jar files directly.BundleActivatorclass has essentially been eliminated; the class still exists but does nothing.