Re: [equinox-dev] understanding resolving results
See https://github.com/bndtools/bnd/pull/2867 for how Bnd deals with using Eclipse bundles. In summary, Bndtools uses Import-Package with bundle-symbolic-name and bundle-version attributes because Eclipse is terrible at managing packages and Require-Bundle is too promiscuous. --BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com - Original message -From: Martin Lippert Sent by: equinox-dev-boun...@eclipse.orgTo: Equinox Dev Cc:Subject: [EXTERNAL] Re: [equinox-dev] understanding resolving resultsDate: Tue, Jun 25, 2019 09:21 Hey!Quick follow-up on this one:it turned out that the resolver is perfectly correct and that there is indeed a subtle difference between those two installs. The orbit bundle for “javax.ws.rs” seemed to be the culprit. Both builds got the exact same version of the bundle, but when looking inside of the bundle into the manifest, those are slightly different. One version adds a version constraint to a package-import, the other one not. And the version constraint causes the trouble, in combination with a require-bundle on org.eclipse.core.runtime.What is the best practice these days when using org.eclipse.core.runtime? Import the used packages instead to avoid the re-export of system packages (in this case javax.xml.annotation.bind)?Thanks a lot for your help, so much appreciated !!!Cheers,-Martin> Am 12.06.2019 um 15:03 schrieb Thomas Watson :>> What happens if you run with -clean. Does the bad install still have the uses constraint error? Before doing so you may want to backup the configuration/ folder so you can get back to the "bad" state. Equinox caches previous runs wiring state. When additional bundles are installed they are resolved with the previous wiring state as a starting point. That means the additional bundles must be able to resolve with the decisions made by the resolver when it resolved the initial set of bundles. Some cases these decisions from the resolution cache may prevent additional bundles to resolve. When using -clean this will re-resolve all bundles again, it actually installs all the bundles again from scratch.> > You didn't give much detail on how the two environments got to their current state, so I am not sure if that is what is happening in this case or not. If running with -clean gets you to a state that has no resolve errors then I would bet something like this is happening. On the other hand if -clean with one environment cause errors but in the other environment results in success then we do have an anomoly to investigate. I would start by gathering resolution trace for the two runs. I would start with the top level resolver trace option (which is pretty noisy, but gets you the most data about what the resolver is doing):> > org.eclipse.osgi/resolver=true> > At this point I assume you know how to enable trace for Eclipse (e.g. specify config.ini option osgi.debug= or use -debug launch option).>> Tom> > > - Original message -> From: Martin Lippert > Sent by: equinox-dev-boun...@eclipse.org> To: Equinox Dev > Cc:> Subject: [EXTERNAL] Re: [equinox-dev] understanding resolving results> Date: Wed, Jun 12, 2019 5:46 AM> > Hey Mickael,>> > So I am looking for strategies to debug and understand this.> >> > Have you tried starting with the `-console` flag to use the OSGi console and compare the effect of the "start" action on both packages?>> Thanks for the suggestion, not sure I understand this.> Doing a “start” on a “package” ?!?>> I can see the details about the package-use-contraint violation using the “diag” command and understand the issue, but I am wondering why the resolver decided to not wire it differently, as it is on a different install with the same set of bundles around. There must be a reason for this… :-)>> Cheers,> -Martin>>>> ___> equinox-dev mailing list> equinox-dev@eclipse.org> To change your delivery options, retrieve your password, or unsubscribe from this list, visit> https://www.eclipse.org/mailman/listinfo/equinox-dev> >> ___> equinox-dev mailing list> equinox-dev@eclipse.org> To change your delivery options, retrieve your password, or unsubscribe from this list, visit> https://www.eclipse.org/mailman/listinfo/equinox-dev___equinox-dev mailing listequinox-dev@eclipse.orgTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] understanding resolving results
Hey! Quick follow-up on this one: it turned out that the resolver is perfectly correct and that there is indeed a subtle difference between those two installs. The orbit bundle for “javax.ws.rs” seemed to be the culprit. Both builds got the exact same version of the bundle, but when looking inside of the bundle into the manifest, those are slightly different. One version adds a version constraint to a package-import, the other one not. And the version constraint causes the trouble, in combination with a require-bundle on org.eclipse.core.runtime. What is the best practice these days when using org.eclipse.core.runtime? Import the used packages instead to avoid the re-export of system packages (in this case javax.xml.annotation.bind)? Thanks a lot for your help, so much appreciated !!! Cheers, -Martin > Am 12.06.2019 um 15:03 schrieb Thomas Watson : > > What happens if you run with -clean. Does the bad install still have the > uses constraint error? Before doing so you may want to backup the > configuration/ folder so you can get back to the "bad" state. Equinox caches > previous runs wiring state. When additional bundles are installed they are > resolved with the previous wiring state as a starting point. That means the > additional bundles must be able to resolve with the decisions made by the > resolver when it resolved the initial set of bundles. Some cases these > decisions from the resolution cache may prevent additional bundles to > resolve. When using -clean this will re-resolve all bundles again, it > actually installs all the bundles again from scratch. > > You didn't give much detail on how the two environments got to their current > state, so I am not sure if that is what is happening in this case or not. If > running with -clean gets you to a state that has no resolve errors then I > would bet something like this is happening. On the other hand if -clean with > one environment cause errors but in the other environment results in success > then we do have an anomoly to investigate. I would start by gathering > resolution trace for the two runs. I would start with the top level resolver > trace option (which is pretty noisy, but gets you the most data about what > the resolver is doing): > > org.eclipse.osgi/resolver=true > > At this point I assume you know how to enable trace for Eclipse (e.g. specify > config.ini option osgi.debug= or use -debug launch option). > > Tom > > > - Original message - > From: Martin Lippert > Sent by: equinox-dev-boun...@eclipse.org > To: Equinox Dev > Cc: > Subject: [EXTERNAL] Re: [equinox-dev] understanding resolving results > Date: Wed, Jun 12, 2019 5:46 AM > > Hey Mickael, > > > So I am looking for strategies to debug and understand this. > > > > Have you tried starting with the `-console` flag to use the OSGi console > > and compare the effect of the "start" action on both packages? > > Thanks for the suggestion, not sure I understand this. > Doing a “start” on a “package” ?!? > > I can see the details about the package-use-contraint violation using the > “diag” command and understand the issue, but I am wondering why the resolver > decided to not wire it differently, as it is on a different install with the > same set of bundles around. There must be a reason for this… :-) > > Cheers, > -Martin > > > > ___ > equinox-dev mailing list > equinox-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://www.eclipse.org/mailman/listinfo/equinox-dev > > > ___ > equinox-dev mailing list > equinox-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://www.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] understanding resolving results
Hey Mickael, > So I am looking for strategies to debug and understand this. > > Have you tried starting with the `-console` flag to use the OSGi console and > compare the effect of the "start" action on both packages? Thanks for the suggestion, not sure I understand this. Doing a “start” on a “package” ?!? I can see the details about the package-use-contraint violation using the “diag” command and understand the issue, but I am wondering why the resolver decided to not wire it differently, as it is on a different install with the same set of bundles around. There must be a reason for this… :-) Cheers, -Martin ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] understanding resolving results
On Wed, Jun 12, 2019 at 12:05 PM Martin Lippert wrote: > So I am looking for strategies to debug and understand this. Have you tried starting with the `-console` flag to use the OSGi console and compare the effect of the "start" action on both packages? ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] understanding resolving results
Hey! I am trying to understand a somewhat strange setting. I have two Eclipse installs with an identical set of bundles. Nevertheless, the dependency resolution is different (just fine for one case, package-use-constraint-violation in the other case). Therefore I am trying to understand why the resolver decides differently in those two cases. So I am looking for strategies to debug and understand this. Is there a way to force the resolver to resolve a specific package-import against a specific provider of that package to see what happens? Does it make sense to debug the code directly? If so, what would be a good starting point? Or is there another strategy to find out what is going on? Thanks a lot for your help! -Martin ___ equinox-dev mailing list equinox-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/equinox-dev
