Remove deprecated methods

[elharo]

Immediately following the last release is the best time to rip out all the deprecated methods.

[garrettjonesgoogle]

We need to be very careful with removals in this library, and make sure the major libraries in the ecosystem have advanced to the version containing the new methods and have removed references to the deprecated ones. (We need to check grpc, google-cloud-java, and Beam). If we don't do this, this particular library could be a huge source of pain for diamond dependency conflicts. (It is very deep in the dependency tree.) I was almost thinking of recommend that these deprecated methods not even get removed when it is pushed to 1.0.

[elharo]

This pre-1.0 library has had one release in the last year+, and only really works on App Engine standard. Now is the time to cut the dead wood, so dependents can upgrade at a more leisurely pace. For now, they can stick with 0.11 and have one PR that upgrades to 0.12 while fixing any deprecated methods. In a non-monorepo world we can't require all usages of methods to be changed at the same time we push a new release. The sooner we make the change, the easier it will be for everyone.

[garrettjonesgoogle]

This library is used for many cases:

• Credentials is referenced in grpc-auth
• GoogleCredentials is used by almost all google-cloud-java clients

This library works on-premise, in GCE, on GKE, etc.

In a non-monorepo world, we can require that the major consumers become "eventually consistent" before the removal. This is essentially a two-phase commit.

Why does making the change sooner make it easier for everyone?

[elharo]

To upgrade those libraries one can either manually inspect all possible usages, or simply add a new version with the methods removed and see what breaks.

Removing these post-1.0 would be an API breaking change that requires a new major version so we definitely don't want to wait till then to do this.

And I'd like to get 1.0 out the door sooner rather than later. The libraries you cite are all GA or include GA artifacts, so depending on this is a problem.

Looks like I misread: only google-auth-library-appengine depends on the App Engine SDK.

[garrettjonesgoogle]

You don't have to publish a new version to maven central to see what breaks; you can mvn install your version with deprecated code removed, then compile & run tests in the major consumers locally and see if they break.

I completely agree that the dependency of GA libraries on unstable libraries is a problem - we both worked on https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/master/library-best-practices/JLBP-4.md , after all :-)

[chingor13]

We should check usage for these against artifacts that use google-auth-libarary-oauth2-http and google-auth-library-appengine

[sduskis]

@elharo, what's the status of this PR?

[chingor13]

We still need to verify that we aren't using any of these methods downstream (at least across Google controlled libraries)

[elharo]

I haven't checked on this lately, so there may be new conflicts with this specific PR, but my opinion is still the same as when I sent it: remove all the deprecated methods now, before 1.0, and without worrying about who might be calling them. No project should be immediately broken by this since dependency upgrades are not automatic. If a project does attempt an upgrade and is broken, this will be a compile time failure and easily detected.

[garrettjonesgoogle]

Disagree. This library is "common-law GA".

[elharo]

Fish or cut bait time. If this library is common-law GA, then remove the deprecation messages, commit to supporting those methods indefinitely, and publish a 1.0 version. The halfway state we're in now is confusing and unfair to library dependents.

[garrettjonesgoogle]

Completely agreed, we need to get the library out of its ambiguous state.

[elharo]

Just to be clear, I don't have an informed technical opinion on the specific methods here. I do believe we should go to 1.0, and we should remove or undeprecate these methods before we do.

[sduskis]

I see @Deprecated was removed here. If it's actively used, please also remove the @deprecated comment`

[elharo]

done

[sduskis]

Who is the owner of the decision of whether or not this ought to be merged?

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (master@af3ae75). Click here to learn what that means.
The diff coverage is 100%.

@@            Coverage Diff            @@
##             master     #190   +/-   ##
=========================================
  Coverage          ?   78.26%           
  Complexity        ?      329           
=========================================
  Files             ?       21           
  Lines             ?     1445           
  Branches          ?      158           
=========================================
  Hits              ?     1131           
  Misses            ?      236           
  Partials          ?       78

Impacted Files	Coverage Δ	Complexity Δ
...uth/oauth2/ServiceAccountJwtAccessCredentials.java	75.73% <ø> (ø)	36 <0> (?)
...java/com/google/auth/oauth2/GoogleCredentials.java	52.77% <ø> (ø)	7 <0> (?)
.../google/auth/oauth2/ServiceAccountCredentials.java	84.23% <ø> (ø)	44 <0> (?)
...p/java/com/google/auth/oauth2/UserCredentials.java	81.3% <ø> (ø)	28 <0> (?)
...tp/java/com/google/auth/oauth2/UserAuthorizer.java	76.57% <100%> (ø)	20 <0> (?)
...om/google/auth/appengine/AppEngineCredentials.java	71.73% <100%> (ø)	13 <1> (?)
...m/google/auth/oauth2/ComputeEngineCredentials.java	86.23% <100%> (ø)	31 <1> (?)
...th2_http/java/com/google/auth/oauth2/ClientId.java	78.94% <100%> (ø)	11 <1> (?)
.../com/google/auth/oauth2/CloudShellCredentials.java	80% <100%> (ø)	10 <1> (?)
...java/com/google/auth/oauth2/OAuth2Credentials.java	84.61% <100%> (ø)	35 <0> (?)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update af3ae75...3eb334c. Read the comment docs.

[sduskis]

Given lack of clear ownership, I'll take responsibility. There will potentially be subtle diamond dependency problems based on this change. The recommendation is to raise an issue in this repository, but also in the repository that's using old deprecated APIs.