fix: try to keep autovalue out of the runtime time classpath

[elharo]

@saturnism @chingor13

[codecov]

Codecov Report

Merging #48 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #48   +/-   ##
=========================================
  Coverage     66.43%   66.43%           
  Complexity      367      367           
=========================================
  Files            34       34           
  Lines          1865     1865           
  Branches        236      236           
=========================================
  Hits           1239     1239           
  Misses          524      524           
  Partials        102      102

---

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 65646ed...22796ea. Read the comment docs.

[saturnism]

i initially suggested optional; i just double checked auto value doc but it suggests provided scope. https://github.com/google/auto/blob/master/value/userguide/index.md#in-pomxml

/cc @eamonnmcmanus :)

[eamonnmcmanus]

Maven dependencies make my head hurt. I think <optional>true</> might actually be slightly more appropriate than <scope>provided</>. But I'm not sure it makes much difference in practice.

[saturnism]

/cc @rfscholte ? ;)

[saturnism]

The behavior is similar for both choices (i.e. consumer won't get this transitive dependency).

Both are documented here: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope

Provided:

This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive

Optional:

If project Y depends on project Z, the owner of project Y can mark project Z as an optional dependency, using the "optional" element. When project X depends on project Y, X will depend only on Y and not on Y's optional dependency Z. The owner of project X may then explicitly add a dependency on Z, at her option. (It may be helpful to think of optional dependencies as "excluded by default.")

In which case, optional does sound like a better choice based on semantics.

[elharo]

We need to distinguish autovalue from autovalue-annotations. autovalue-annotations is in source ocde and should be optional. autovalue should probably be configured via the annotation processor classpath.

…

On Wed, Oct 2, 2019 at 11:27 AM Ray Tsang ***@***.***> wrote: The behavior is similar for both choices (i.e. consumer won't get this transitive dependency). Both are documented here: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope Provided: This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive Optional: If project Y depends on project Z, the owner of project Y can mark project Z as an optional dependency, using the "optional" element. When project X depends on project Y, X will depend only on Y and not on Y's optional dependency Z. The owner of project X may then explicitly add a dependency on Z, at her option. (It may be helpful to think of optional dependencies as "excluded by default.") In which case, optional does sound like a better choice based on semantics. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#48?email_source=notifications&email_token=AAHVP2A55V5WYSAVHPMQ4CDQMS4WRA5CNFSM4I4W6PCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAFFAAA#issuecomment-537546752>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHVP2GJ2YEQ5NV5HHHX7HLQMS4WRANCNFSM4I4W6PCA> .

-- Elliotte Rusty Harold elharo@macfaq.com

[elharo]

FYI, filed google/auto#765 to update the autovalue docs. This PR assumes <optional>true</optional> is correct. On Wed, Oct 2, 2019 at 11:30 AM Elliotte Rusty Harold <elharo@macfaq.com> wrote:

…

We need to distinguish autovalue from autovalue-annotations. autovalue-annotations is in source ocde and should be optional. autovalue should probably be configured via the annotation processor classpath. On Wed, Oct 2, 2019 at 11:27 AM Ray Tsang ***@***.***> wrote: > The behavior is similar for both choices (i.e. consumer won't get this > transitive dependency). > > Both are documented here: > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope > > Provided: > > This is much like compile, but indicates you expect the JDK or a > container to provide the dependency at runtime. For example, when building > a web application for the Java Enterprise Edition, you would set the > dependency on the Servlet API and related Java EE APIs to scope provided > because the web container provides those classes. This scope is only > available on the compilation and test classpath, and is not transitive > > Optional: > > If project Y depends on project Z, the owner of project Y can mark > project Z as an optional dependency, using the "optional" element. When > project X depends on project Y, X will depend only on Y and not on Y's > optional dependency Z. The owner of project X may then explicitly add a > dependency on Z, at her option. (It may be helpful to think of optional > dependencies as "excluded by default.") > > In which case, optional does sound like a better choice based on > semantics. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#48?email_source=notifications&email_token=AAHVP2A55V5WYSAVHPMQ4CDQMS4WRA5CNFSM4I4W6PCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAFFAAA#issuecomment-537546752>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAHVP2GJ2YEQ5NV5HHHX7HLQMS4WRANCNFSM4I4W6PCA> > . > -- Elliotte Rusty Harold ***@***.***

-- Elliotte Rusty Harold elharo@macfaq.com

[chingor13]

Should this actually be upstreamed to google-auth-library?

[elharo]

@chingor13 I'm not clear on how google-auth-library comes into play on this PR. The depedency is already declared in java-core's pom.xml.

[chingor13]

@elharo java-core doesn't use auto-value at all, I'm not sure why we have the dependencyManagement entry. google-auth-library does declare a dependency on auto-value-annotations

[elharo]

Could be vestigial code then. Let me try removing it completely and see what happens.

[chingor13]

You probably need to add the maven enforcer rule in this PR too.

[elharo]

Are you OK with the enforcer rule going here? You had asked for it to be moved to the shared config.

[chingor13]

Do we know that this fixes the linkage check?

[elharo]

Yes, it appears to fix the linkage check. I could put the enforcer rule here to demonstrate that, but you asked for that to go elsewhere. If you want it here, please be explicit about that.

[elharo]

Also, whether this fixes the linkage check or not, it's still a good idea to remove unnecessary code where we can.