The OSGi plugin uses an older version of the BND tool for generating proper OSGi manifest information, and this version of the library doesn’t handle bytecode for newer JDK versions, especially “invoke dynamic” bytecode. As the Groovy project uses the Gradle OSGi plugin, we’ve not been able to properly osgi-fy our “indy” JARs. The BND team recently released 2.1.0, and I’ve made a pull request with changes to switch to that newer version of the library: https://github.com/gradle/gradle/pull/167
The pull request updates the version to 2.1.0 and fixes the imports as there was a package change for the ‘Analyzer’ class.
Do you know if this is backwards compatible for users of the osgi plugin? We can’t make this change if it isn’t.
I hope it is, but as I’m not a hard-core OSGi expert nor one of those working on BND, I can’t swear it’s the case!
All I can say is that this new version is improving upon the previous ones and fixes problems with JDK 7 and 8 which will become more and more common-place. I understand the potential backward compatibility issue, but at some point you have to fix things! When making the changes to the plugin, all I could notice was the change in package for the class the plugin was using, that’s all.
If it’s a breaking change for our uses, then we have to wait until Gradle 2.0 to make this change… or update the plugin to be decoupled from a particularly BND version. Introducing breaking changes is simply not an option.
We’ll have to ask the BND authors for information on what changed.
What bnd are you using now?
I will probably never understand why Gradle, an otherwise very nice and interesting system, is rather monolithic, with plugin dependencies fixed, whereas Maven was already on the right track with this (and also classpath per plugin, which I also think has advantages over the global classpath for a build). bnd version here is just one example, Jetty version is another, there are others. Are there any plans to address these issues in 2.0?
wujek
The change is from 1.50.0 to 2.1.0.
@wujek: there is absolutely zero debate that the following is better:
- Plugins are written in a way that they are decoupled from the tool that they are integrating 2. Plugins do not share dependencies unnecessarily.
Neither of those things are trivial. #1 is very plugin specific and adds significant overhead to the development.
As for #2, this requires significant changes to the structure of plugins and how they are managed. It will happen at some point.
No one is disagreeing with you that it would be better to have #1 and #2.
That might break some people. After 2.0.0 we follow the semantic versioning rules as set by OSGi
In what way might it break some people’s code?
I would expect it only breaks code that uses the BND library directly, not so much the metadata generation itself. Is that correct Peter?
It is a pretty big jump from 1.50 to 2.2 now. The manifest will not likely break anybody since I am pretty careful about this. However, API changed. However, that should be easy to test.
From the perspective of the Gradle OSGi plugin bundling BND, the changes were trivial, since only the Analyzer was used explicitely, and that was just a package change.
What is most important here is your remark that the manifest will not likely break anybody, which is the crux of the story here. The generated manifest is the key delivery and should be the same if not better than those generated with earlier versions.
I completely agree, users of the plugin are using the plugin to generate metadata, which doesn’t work now with JDK7, so this should be fixed.