| Re: [tycho-user] NPE during dependency resolution of platform fragment bundle with a Fragment-Host and a p2.inf using 0.20.0 |
Thanks! Trying to setup my example project with the profileProperty from the linked SWT gerrit patch (18022). I think I have it setup but I still see the NPE. Tested on both windows and linux, fresh install of maven 3.2.1, Oracle JDK 1.7.0 u45 (64 bit). I've attached a zip file, but have to name it nozip or my corporate proxy will remove it from the outgoing email. On Windows run 'mvn validate -Dplatform=win64vc11' and on linux run 'mvn validate -Dplatform=linux64rh6'. > -----Original Message----- > From: tycho-user-bounces@xxxxxxxxxxx [mailto:tycho-user- > bounces@xxxxxxxxxxx] On Behalf Of Oberlies, Tobias > Sent: Saturday, April 19, 2014 4:42 AM > To: Tycho user list > Subject: Re: [tycho-user] NPE during dependency resolution of platform > fragment bundle with a Fragment-Host and a p2.inf using 0.20.0 > > 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 > > > > _______________________________________________ > tycho-user mailing list > tycho-user@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/tycho-user ---------------------------------------------------------------------- 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.
Attachment:
platform-fragment-test.nozip
Description: platform-fragment-test.nozip