Minecraftforge: Forge mdk/dev enviornment uses a different guava version (25.1) then the one present at runtime in production (21.0)

[MajorTuvok]

Minecraft Version: 1.14.4

Forge Version: .55

Logs: See this issue

Steps to Reproduce:
Freshly install Forge .55 into the vanilla launcher and add a mod which depends on Methods added to guava >21.0 (for example buildinggadgets 3.0.3). It cannot load due to the NoSuchMethodError.
Description of issue:
In Dev enviornment we have dependency on guava version 25.1, but in production only 21.0 is present. This resulted in us using guava's ImmutableList#builderWithExpectedSize (which was added in guava 23.1) and then recieving https://github.com/Direwolf20-MC/BuildingGadgets/issues/347 because only an outdated guava version is present.

I have no idea, whether dev env. is wrong or whether the downloaded version is erronous, but they should be identical.

[cpw]

Interesting. This is probably a dev env failure - not sure what's pulling in the more recent version. We should be aligned unless we're doing something exceptional.

[cpw]

I just looked, and forge only has guava 21.0 in its dependencies. It sounds like building gadgets has a broken introduced dependency on later guava.

[MajorTuvok]

I don't know where that would be coming from, as we only add junit as a dependency for the test configurations. It doesn't even touch main configuration/source set...

[MajorTuvok]

I'll check with the mdk tomorrow and see whether that also shows up there - I don't see where a newer dependency on guava would come from if we add no dependencies.

[MajorTuvok]

I just downloaded the .55 mdk and imported it. The mdk also depends on 25.1.

[MajorTuvok]

I just deleted my .gradle directory and then downloaded the mdk again - It just redownloaded guava 25.1...

[Cloudhunter]

I just downloaded the latest MDK, and imported it. Can confirm that 25.1 is downloaded as a dependency.

[Barteks2x]

Newer guava appears to be coming from net.minecraftforge:mergetool:1.0.6

[LexManos]

And thus we have dependency nightmares. No idea if there is a way on FGs end to define nontransitive for these libraries.

[cpw]

Ah shit, that's where it's coming from. Yeah, you can tell gradle to ignore deps of the mergetool lib. To be honest, it should probably not expose it's deps anyway.

[LexManos]

Alright, so looking into it more, im not exactly sure how to fix, as I don't think the maven spec allows for declaring a dep and NOT its transtive deps.
We can however lock specific versions using the [] notation. However, this is a isssue for anything hosted by Mojang's library repo, as they do not provide maven-metadata.xml and thus those versions can't be resolved.
The only be would be for us to nuke the pom from mergetool, or to publish the API as a different artifact with no deps.

I'll look more into it later, this isn't a show stopper.

[MajorTuvok]

I guess forcing mc's guava version in merge tool isn't an option (why is mojang on this old version of guava?!?)?

[MajorTuvok]

As this was fixed now - closing