I have gotten the same error on other dependencies. Gogradle sometimes fails to pull down the dependencies. Retrying ./gradlew :sdks:go:resolveBuildDependencies in the past did allow me to fetch the dependencies. Others who focus only on the Go SDK work using the standard Go development process by checking out the apache beam package into their GOPATH editing it there. I rarely do this because I typically focus on changes that are either outside the Go SDK or span multiple languages.
On Wed, May 29, 2019 at 5:00 AM Kengo Seki <sek...@apache.org> wrote: > It was my fault, probably my gradle cache was broken. > Running gradlew succeeded after removing ~/.gradle. > I'm sorry for bothering you. > > Kengo Seki <sek...@apache.org> > > On Wed, May 29, 2019 at 6:45 PM Kengo Seki <sek...@apache.org> wrote: > > > > Hi Beam developers, > > > > I tried to build Go SDK on the master branch, but encountered the > > following error. > > > > ``` > > $ ./gradlew :sdks:go:resolveBuildDependencies > > > > (snip) > > > > FAILURE: Build failed with an exception. > > > > * What went wrong: > > Execution failed for task ':sdks:go:resolveBuildDependencies'. > > > Exception in resolution, message is: > > Cannot resolve dependency:github.com/coreos/etcd: > > commit='11214aa33bf5a47d3d9d8dafe0f6b97237dfe921', > > urls=[https://github.com/co > > reos/etcd.git, g...@github.com:coreos/etcd.git] > > Resolution stack is: > > +- github.com/apache/beam/sdks/go > > ``` > > > > Replacing the "coreos" organizations with "etcd-io" in GitHub URLs in > > gogradle.lock seems to work. > > > > ``` > > $ sed -i s,coreos/etcd,etcd-io/etcd,g sdks/go/gogradle.lock > > $ ./gradlew :sdks:go:resolveBuildDependencies > > > > (snip) > > > > BUILD SUCCESSFUL in 4s > > 2 actionable tasks: 2 executed > > ``` > > > > But I'm not sure whether it's a valid solution, since I'm not familiar > > with Gogradle and it seems that gogradle.lock shouldn't be edited > > directly according to its header comment. > > Is the above approach valid, or is there a more proper way to solve > > this problem...? > > > > Kengo Seki <sek...@apache.org> >
