Re: [equinox-dev] understanding resolving results

[Martin Lippert <mlippert@xxxxxxxxx>]

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 <tjwatson@xxxxxxxxxx>:
> 
> 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 <mlippert@xxxxxxxxx>
> Sent by: equinox-dev-bounces@xxxxxxxxxxx
> To: Equinox Dev <equinox-dev@xxxxxxxxxxx>
> 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@xxxxxxxxxxx
> 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@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/equinox-dev