I see. We should be able to fix that to do what we do when we embed the versions of dependencies in our Maven archetypes like so[1]: dependencies.create(project.library.java.google_api_client).getVersion()
I'll send out a PR updating the javadoc pulling to be based off the version and open up a PR. 1: https://github.com/apache/beam/blob/abece47cc1c1c88a519e54e67a2d358b439cf69c/sdks/java/maven-archetypes/examples/build.gradle#L29 *From: *Kenneth Knowles <[email protected]> *Date: *Mon, May 13, 2019 at 11:57 AM *To: *dev I expect Ankur is referring to the hardcoded linkOffline bits here: > https://github.com/apache/beam/blob/master/sdks/java/javadoc/build.gradle#L78 > since > the versions are in the URLs, and also the downloaded files used are from > those versions. This helps with flakiness, since otherwise it has to > download stuff to figure out which identifiers are linkable. > > Kenn > > *From: *Lukasz Cwik <[email protected]> > *Date: *Mon, May 13, 2019 at 9:04 AM > *To: *dev > > What is the difference between the two files you are referring to? >> >> Note that sdks/java/javadoc/build.gradle is meant to produce one giant >> javadoc across many modules that users would be interested in >> (core/extensions/io/...) meant to be published on the website. >> >> *From: *Ankur Goenka <[email protected]> >> *Date: *Fri, May 10, 2019 at 5:21 PM >> *To: *dev >> >> Hi, >>> >>> I see that the sdks/java/javadoc/build.gradle is not in sync with >>> org/apache/beam/gradle/BeamModulePlugin.groovy . >>> I wanted to check if we are maintaining or not based on that we can >>> either remove or update sdks/java/javadoc/build.gradle. >>> >>> Thanks, >>> Ankur >>> >>
