Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-user] NPE during dependency resolution of platform fragment bundle with a Fragment-Host and a p2.inf using 0.20.0

So this is a bug in Tycho? If you think so, please open a bug report to make sure that this doesn't get lost.

Regards
Tobias


> -----Original Message-----
> From: tycho-user-bounces@xxxxxxxxxxx [mailto:tycho-user-bounces@xxxxxxxxxxx]
> On Behalf Of Justin Georgeson
> Sent: Montag, 21. April 2014 21:25
> 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
> 
> 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.


Back to the top