[
https://issues.apache.org/jira/browse/BEAM-5379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16622707#comment-16622707
]
Robert Burke commented on BEAM-5379:
------------------------------------
I have less time to work on this than intended, so I'm unassigning myself from
it.
Note for whomever takes this: The current jenkins machines and gogradle
currently use go1.10, which doesn't yet have go modules, so a first pre-step
would definitely be to update the jenkin's Go version.
The end result should be for it to be easy for non-Gophers to run the go tests,
and make changes to the Go SDK, which at this point means making sure the
various Gradle commands for building and testing the Go SDK continue to work.
However, this does allow for a lot of lee-way in implementation, since gradle
can just invoke shell scripts that use the go tool directly, rather than trying
to munge itself into Gradle the way GoGradle does. Gogradle might also have a
good migration path by the time this is picked up too.
> Go Modules versioning support
> -----------------------------
>
> Key: BEAM-5379
> URL: https://issues.apache.org/jira/browse/BEAM-5379
> Project: Beam
> Issue Type: Improvement
> Components: sdk-go
> Reporter: Robert Burke
> Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This would make it easier for non-Go developers to update and test changes to
> the Go SDK without jumping through hoops to set up Go Paths at first.
> Right now, we us the gogradle plugin for gradle to handle re-producible
> builds. Without doing something with the GO_PATH relative to a user's local
> git repo though, changes made in the user's repo are not represented when
> gradle is invoked to test everything.
> One of at least the following needs to be accomplished:
> * gogradle moves to support the Go Modules experiment in Go 1.11, and the SDK
> migrates to that
> * or we re-implement our gradle go rules ourselves to use them,
> * or some third option, that moves away from the GO_PATH nit.
> This issue should be resolved after deciding and implementing a clear
> versioning story for the SDK, ideally along Go best practices.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
