[YANGIDE-13] Guava is on the classpath twice, with different versions Created: 09/May/16 Updated: 19/Oct/17 |
|
| Status: | Open |
| Project: | yangide |
| Component/s: | General |
| Affects Version/s: | unspecified |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Michael Vorburger | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| External issue ID: | 5866 |
| Description |
|
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. This is typically Not Good, because which one gets loaded depends on classpath ordering, and this can be very confusing for developers when debugging. We can probably safely simply remove either or the other. I'm assuming that the v18 in lib as Bundle-Classpath comes in for & via yangtools, so it seems smarter to keep that one and strike the other one. |
| Comments |
| Comment by Michael Vorburger [ 09/May/16 ] |
| Comment by Michael Vorburger [ 10/May/16 ] |
|
https://git.opendaylight.org/gerrit/#/c/38624/ proposed; David on looking at your https://git.opendaylight.org/gerrit/#/c/38596/2/plugins/org.opendaylight.yangide.yangparser/META-INF/MANIFEST.MF 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 & ANTLR as in their respective own MANIFEST.. 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. |