Closed mrutkows closed 3 years ago
My assumption is that the gogradle plugin forces you to use a "/vendor" directory and we really do not want one at all; however, the "go" command assumes that if it sees a "/vendor" directory that it overrides "go.mod". So we need to either:
a) prevent gogradle from installing anything into "/vendor" meaning we need to prevent the Task :resolveBuildDependencies
and Task :installDependencies
from installing packages into "/vendor" or
or
b) we set the new flag option on the "go" command i.e., -mod=mod
to force it to ignore the vendor directory regardless of what gogradle does.
See: https://tip.golang.org/doc/go1.14 for a desc. of this behavior
This blog explains it better and has a demo of switching between go 1.13 and go 1.14: https://www.ardanlabs.com/blog/2020/04/modules-06-vendoring.html
I should mention that a 3rd option exists, but I discounted it since it basically capitulates to the old gogradle plugin (and also bypasses it for managing deps.) and uses the "go" command to create the vendor directory i.e., go mod vendor
: https://www.honeybadger.io/blog/golang-go-package-management/
ideally, we switch to a more current gradle plugin such as: https://github.com/innobead/gogradle which works better with go.mod and is more straightforward or eliminate gradle altogether and find a better way to switch OS/ARCH for docker builds.
@pritidesai Thanks Priti!
ideally, I would love to replace the
gogradle
plugin (no sig. updates since 2017) with something more aware of the post go 1.11 moduling system and supports cross platform/arch builds simply. However, we need a means to preventgogradle
from using a "/vendor" directory and attempting to fetch its own packages/versions.