Added Gradle support to include OSGI headers in package #83
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change makes gradle add OSGI headers to the individual Norbert JARs, something which may or may not be useful to others. It should not impact the JARs in any way but adding manifest data.
A non-optimal solution is that all but 'cluster' project manually defines a list of packages to mark for Import. Normally these are resolved by the osgi plugin automatically (the list comes from such an automatic detection), but by default the plugin will add imports declarations such as 'com.linkedin.norbert.cluster;version="(0.6,1.0]"', i.e. an flexible version range, which isn't desired. The manual listing allows us to force 'com.linkedin.norbert.cluster;version="0.6.91"' which is more appropriate for Norbert's different "internal" packages.
An alternative approach is to use the -consumer-policy directive, but that would instead make all other imports, such as log4j, equally strict, something which may not be desired.
A second not-perfect solution is java-network project, which has a manual exports list with a single package. This is to avoid export of "com.linkedin.norbert" caused confusion in the OSGi environment, since that package is also exported from cluster project:
org.osgi.framework.BundleException: Uses constraint violation. Unable to resolve bundle revision com.example.xxxx [349.0] because it is exposed to package 'com.linkedin.norbert' from bundle revisions com.linkedin.norbert.java-network [353.0] and com.linkedin.norbert.cluster [358.0] via two dependency chains.I tried to use Export-Package: '!com.linkedin.norbert,*' which picked the right packages, but instead left of the version tag for the exported package, effectively giving it version 0.0.0 which makes it unusable.
In addition I didn't succeed with adding OSGi headers to the norbert package (bundled). This seems to be due to a bug in the osgi plugin which fails if a JAR does not have any direct source files.
Example of new META-INF/MANIFEST.MF for java-cluster project (somewhat cleaned up with line-breaks):