Re: [tycho-user] NPE during dependency resolution of platform fragment b

["Oberlies, Tobias" <tobias.oberlies@xxxxxxx>]

See my replies inline.

Justin Georgeson wrote:
> 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?

I agree completely. Another case of the same problem is SWT (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=361901 )

> 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.

Well, you certainly have a circular runtime dependency - but not necessarily a circular build time dependency. By default, Tycho tries to follow the runtime dependencies also at build time, so I wonder if the NPE is simply caused by the fact that your attempt to trick Tycho no longer works.

But there is a supported solution for your use case: Define a filter on your p2.inf dependency and make sure that it is not taken into account during dependency resolution. E.g. only make the p2.inf dependency apply if the property "com.lgc.example.buildtime" is _not_ set and then set the property in the build. See the proposed change for above bug for an example: https://git.eclipse.org/r/#/c/18022/

Note that you should have a dedicated "buildtime" flag for every runtime cycle - the p2.inf dependency should only be disabled for the build of the cycle but not (accidentally) by the consumers of the cycle.

> 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'm not sure this would have helped. If there is in fact a defect in Tycho, it probably wouldn't have been considered important enough to postpone the release. Your chances are better if you test snapshots and report bugs during development.

> I can provide a test project.

I'd say, first see how far you get with the ideas above.

Regards
Tobias


> [1] http://dev.eclipse.org/mhonarc/lists/tycho-user/msg05187.html
>