[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[tycho-user] NPE during dependency resolution of platform fragment bundle with a Fragment-Host and a p2.inf using 0.20.0
|
Wall of Text follows. Thanks for reading.
I’m pretty sure I’ve isolated this issue to Tycho 0.20.0. For our projects with native code, we have the main host bundle project with the Java code, and the per-platform fragment bundles.
com.lgc.example
com.lgc.example.linux.gtk.x86.64
com.lgc.example.win32.win32.x86_64
While implied by use of “fragment” in the subject, I’ll expressly confirm that each of the platform bundles have “Fragment-Host: com.lgc.example;bundle-version=”[x.y.z,x.y+1.0)” in their manifest. The version range is to ensure that the classes in the
host are API compatible with the JNI methods in the fragment. Both the Java code of the host and native code of the platform fragment are built together in a common reactor. Some direct consumers of com.lgc.example are also built in the same reactor, some consumers
build in a separate reactor against a published P2 repo containing com.lgc.example*.
For running unit tests of a bundle, com.lgc.<consumer>, that depends on com.lgc.example will also need the platform fragment so the native library can be loaded. Based on this[1] thread from January (and the linked defect reports and patch sets and blog
posts) I can have every set of host + platform fragments also provide a feature, and then define tycho-surefire-plugin in the pom.xml of every com.lgc.<consumer>.tests to have a dependency on all the necessary features. But how do I as <consumer> know that
when I’m putting a Require-Bundle on com.lgc.example in my manifest that I also have to add com.lgc.example.feature to my test bundle’s pom.xml? Shouldn’t the provider of com.lgc.example be responsible for declaring that it won’t work without the platform fragment
for P2 to satisfy that requirement without the consumer having to research that after their unit tests fail?
So to make the provider declare the existence of platform fragment bundles, we use a p2.inf file to declare a namespace provided by the platform bundle. And during the package process-test-resources phase of the host bundle, we inject a p2.inf in the host
bundle that requires the namespace provided by the fragment. The combination of the Fragment-Host header and the p2.inf file in the platform fragment cause the NPE when resolving the dependencies of the fragment. If I remove either one of them, the NPE goes
away.
Now I can imagine that peoples’ first response is that I’ve created a circular dependency and that’s the answer, but the host bundle doesn’t have dependency on the fragment during the validation phase because there’s no p2.inf requiring the namespace there
yet (not until the process-test-resources phase). So at the time of the NPE, there is no circular dependency. This implementation has been working with Tycho 0.17.0-0.19.0 using both Maven 3.0.4 and 3.2.1. I can imagine the second response being why didn’t
I test the staged 0.20.0 before release? They’re staged under an https server and by the time I get maven working with https and my companies’ authentication-requiring ntlm proxy, it’s too late. But that’s not a tycho problem that’s a pure maven problem.
I can provide a test project.
This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message.
