https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/YANGIDE-13 yangide <p>While looking through the dependencies of yangide for an idea I had, I just noticed that Guava is twice on the classpath of yangide.yangparser, with different versions.. one a v15 from Orbit through MANIFEST, and one a v18 in lib as Bundle-Classpath.</p> <p>This is typically Not Good, because which one gets loaded depends on classpath ordering, and this can be very confusing for developers when debugging.</p> <p>We can probably safely simply remove either or the other. I'm assuming that the v18 in lib as Bundle-Classpath comes in for &amp; via yangtools, so it seems smarter to keep that one and strike the other one.</p> <p>Operating System: All<br/> Platform: All</p> YANGIDE-13

Guava is on the classpath twice, with different versions

Bug Open Unresolved Unassigned Michael Vorburger Mon, 9 May 2016 16:09:16 +0000 Thu, 19 Oct 2017 21:25:00 +0000 unspecified General 0 0 <p><a href="https://git.opendaylight.org/gerrit/#/c/38596/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/38596/</a></p> <p><a href="https://git.opendaylight.org/gerrit/#/c/38624/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/38624/</a> proposed; David on looking at your <a href="https://git.opendaylight.org/gerrit/#/c/38596/2/plugins/org.opendaylight.yangide.yangparser/META-INF/MANIFEST.MF" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/38596/2/plugins/org.opendaylight.yangide.yangparser/META-INF/MANIFEST.MF</a> it occurred to me that when using Bundle-ClassPath: and if needing Export (an alternative would be to not Export at all, but as we seem to need) then "correct" thing to do would probably be a full Export Package for Guava &amp; ANTLR as in their respective own MANIFEST.. </p> <p>There is a probably another take on this, by directly exposing all those JARs as OSGi bundles (which they already are!) and a "normal" dependency on them, instead of Bundle-ClassPath. I think the missing piece is have them on a p2 repo. I may try this out some time in coming weeks if I get to it (low prio); for now, I would suggest we do the "full" Export Package as proposed in change 38624.</p> Development External issue ID 5866 External issue URL Rank 0|i02y87: