Move graph functionality to a separate module and maven artifact

[timothy-khom]

API(s)

package com.google.common.graph

How do you want it to be improved?

Move it to to a separate module and maven artifact

Why do we need it to be improved?

It will allow to pull the required version of graph functionality into the project independent of the rest of google.guava capabilities.

Example

<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava-graph</artifactId>
</dependency>

Current Behavior

Graph functionality is distributed along with the entire guava

Desired Behavior

To be able to depend on graph module independently

Concrete Use Cases

E.g. our apps uses some corporate bom, which relies on quite old guava verision and it is fine for the common functionality. It is not pretty easy to upgrade guava version in the bom, which used across the company. But we want to leverage the newest graph features as of latest guava artifact. So it would be much more flexible to just pull what we need from graph module without impact on others

Checklist

• I agree to follow the code of conduct.

• I have read and understood the contribution guidelines.

• I have read and understood Guava's philosophy, and I strongly believe that this proposal aligns with it.

[Chris Povirk]

Unfortunately, mixing a new version of com.google.common.graph with older versions of other Guava packages will likely lead to runtime errors, since common.graph probably relies on APIs that were added in newer Guava versions.

(There are also some additional problems that would arise if we split Guava after having released it as a full jar for all these years. And even if we'd released it as separate jars all this time, that could lead to issues, too, especially since Maven doesn't resolve version conflicts in favor of the newest version.)

Your best bet is probably to download a new Guava and have a took like Proguard or jarjar rewrite it to a new package, preserving only common.graph and its needed dependencies. (You'd likely also have it "hide" those dependencies by moving them into common.graph as package-private or by giving them an unappealing package name.) Then you could use com.yourcompany.guavagraph.

Also: If there's anything worth sharing about your difficulties with updating Guava, let us know. We know that our past habit of removing APIs was a big cause of problems until ~6 years ago, but we also know that random small problems can break things and force rollbacks. There might well not be much we can do, but let us know if you think otherwise.

[timothy-khom]

@cpovirk thank you for the the response and suggestions