[
https://issues.apache.org/jira/browse/BEAM-5379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Burke updated BEAM-5379:
-------------------------------
Description:
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.
Edite June 2020: In particular for cross use with GoGradle, we can set options
to avoid gradle's own locking system: See
https://github.com/gogradle/gogradle/issues/304
```
installDependencies.enabled = false
resolveBuildDependencies.enabled = false
```
was:
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.
> 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: P2
> Time Spent: 5h 10m
> 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.
> Edite June 2020: In particular for cross use with GoGradle, we can set
> options to avoid gradle's own locking system: See
> https://github.com/gogradle/gogradle/issues/304
> ```
> installDependencies.enabled = false
> resolveBuildDependencies.enabled = false
> ```
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
