Maven coordinates for shaded javac seem incorrect

[ZacSweers]

In looking at the 1.3 release pom, it seems like the javac configuration is incorrect.

From: https://search.maven.org/remotecontent?filepath=com/google/googlejavaformat/google-java-format-parent/1.3/google-java-format-parent-1.3.pom

<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<java.version>1.8</java.version>
<guava.version>19.0</guava.version>
<javac.version>9-dev-r3297-1-shaded</javac.version>
</properties>
<dependencyManagement>
<dependencies>
<!--  Required runtime dependencies  -->
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>${guava.version}</version>
</dependency>
<dependency>
<groupId>com.google.errorprone</groupId>
<artifactId>javac</artifactId>
<version>${javac.version}</version>
</dependency>

The maven coordinates for the shaded javac are still the same as the normal javac, which means it will compete with any existing javac jars on the path even though the sources used by GJF are shaded, so if the normal javac jar is on the path and wins, GJF will fail to find the classes because they won't be shaded. It seems to me that the artifactId should also be different.

This is to say: If someone has another version of the error-prone javac jar on the path, it could be used instead of this shaded one, and subsequently break GJF since it depends on shaded package names that would no longer be present.

[msridhar]

In particular, if there are Error Prone plugin checkers on the processor path, that could result in a different javac version also getting pulled in there.

[ronshapiro]

I think that what you're saying is that another com:google:errorprone:javac:not-shaded-javac could be in the dependency tree, causing some build systems to not place the shaded version on the classpath at all (I initially read it as saying that both may be on the classpath, but one might win, which isn't true). Is that correct? If so it may be worth updating what you wrote, as I find it confusing.

If that's the case, that sounds reasonable to me. What you'd like is for one library's error-prone javac code to not conflict with the version that GJF needs shaded.

[msridhar]

@ronshapiro yes, that's exactly right, we were only seeing the not-shaded version in the processorpath, which broke GJF.

[ZacSweers]

Updated the wording

[ZacSweers]

Any thoughts on this? Seems like a fairly serious issue with the release in its current state, as no one can use custom error prone checkers and GJF-using tools like dagger in the same project

[cushon]

I'm going to fix this soonish.

[cushon]

I published a new javac version 9-dev-r4023-3 with separate javac and javac-shaded artifacts, and updated GJF to use it in fee1ed2.

[ZacSweers]

Great. I hate to be that person, but any chance of a (patch) release soon? Otherwise we can just do a fork of this internally for now

[sormuras]

@hzsweers You can also use jitpack to compile and provide the current master snapshot version. See https://jitpack.io/#google/google-java-format/master-SNAPSHOT for details how to declare a dependency in Maven, Gradle, etc.

[ZacSweers]

We run on buck, so unfortunately jitpack isn't a straightforward option. It's easy enough for us to take a cut of master and stick it up on our internal artifactory though, was just asking in case there was a release planned for like, tomorrow or something before going through the trouble :)

[cushon]

I released it: https://github.com/google/google-java-format/releases/tag/google-java-format-1.4

[ZacSweers]

Thanks Liam!