Is Go supported by Gradle? How to start?
I am starting my research, but so far I only find 1 plugin on https://plugins.gradle.org/search?term=go
https://github.com/echocat/gradle-golang-plugin
Generally, gradle or maven would not be needed, because:
go build is enough.
the dependencies are managed by go itself.
You see some project using Makefile (to link go build and go test and go vet).
Try Gogradle https://github.com/blindpirate/gogradle, a full featured plugin for Golang.
The reason why we need it is that Golang lacks of automatic build mechanism, package versioning and many other stuff which is supported by Gogradle.
Related
Quite new to all things Kotlin / IntelliJ / IDEA / gradle.
I'm comparing some code in about ten languages and the Kotlin Native version is the only one that I can't figure out how to build without using the IDE.
I started the project in IntelliJ IDEA by following guides on getting started with Kotlin and this was the recommended method.
By Googling, searching the IntelliJ help, and hunting here on StackOverflow I've been unable to find the answer. Most questions are about Multiplatform and phone apps. I'm just making a macOS commandline tool for now.
Is there a way included with IntelliJ IDEA to build a project form the terminal without starting up the IDE?
Or would it actually require me to use a completely different build system and just use Kotlin Native Mono install totally separate from the IntelliJ setup? Is no shared build system possible or would that be an even more advanced proposition?
There is no need to use the IntelliJ IDEA to build the Kotlin native project.
You should be able to use the gradle build or gradle nativeBinaries command from the Terminal to build the Gradle project.
Also, you could refer to the Kotlin native documentation here for details: https://kotlinlang.org/docs/native-gradle.html
I figured it out with a bit more trial and error.
IntelliJ IDEA seems to come with gradle but doesn't put it in the path. The IntelliJ IDEA project has set up a build system that will work with gradle as is though. You don't have to set up a new one from scratch.
In my case the gradle executable was at:
/System/Volumes/Data/Users/hippietrail/.gradle/wrapper/dists/gradle-7.4.2-bin/48ivgl02cpt2ed3fh9dbalvx8/gradle-7.4.2/bin/gradle
Running gradle using the full path with no parameters looks like it's doing something and takes a while, but doesn't build the project. To build it simply add the build parameter so in my case:
/System/Volumes/Data/Users/hippietrail/.gradle/wrapper/dists/gradle-7.4.2-bin/48ivgl02cpt2ed3fh9dbalvx8/gradle-7.4.2/bin/gradle build
It seems that gradle is not in the path by design and that the intended usage is via the gradlew that IntelliJ IDEA put in my project directory for me. This is an (explicit) wrapper script for gradle. So the more straightforward invocation is:
./gradlew build
I am quite new to gradle but have good experience with maven.
I am wondering what is the difference between these two below.
api project(':my-prj-1')
vs
api "com.mydomain:grpc-helper:${grpc-helperVersion}"
I can see that when using project, i am giving just the project name not the artifactory details.
So when should or when can i use api project and what is the difference compared with just api. And in this case is there any comparison possible with Maven.
(Sorry for my poor English)
I suppose you have a sub-project named my-prj-1 that can build the sub-artifact com.mydomain:grpc-helper.
By api project(':my-prj-1'), when you build the main project, the sub-project will also get built and its artifact will be used in the main project. (1)
By api "com.mydomain:grpc-helper:${grpc-helperVersion}", the main project will try to find the artifact from the repository only, if the sub-project is not built yet, the build will fail. (2)
From my experience, I would prefer the first approach since it a little bit safer. If the sub-artifact is already built then the sub-project build is skipped (due to incremental build) so there are no performance differences from the second approach.
I'm fairly new to Go coming from a Java background and am trying to figure out best practices for Go dependency management.
If I have Project A that has a dependency on Project B and I put a reference to Project B in my vendor package then running go install downloads everything I need. However, let's say I find a bug in Project B that I fix, how do I ensure that Project A stays up to date? As in, is there some way to do an install on every deploy to make sure that I'm not missing anything?
In Java, on every deploy I would do my own mvn package to best ensure that each deploy was self-sufficient. Is there some way to do the same in Go?
Apologies if this is a really basic question - but I couldn't find a good answer.
If you are using go 1.11 and above go mod for prior versions
you can use go dep
Intro: dep is a tool to manage dependencies of Go projects. bazel is a build tool that produces stable, reproducable builds. There is a bazel rule set for Go projects, including an automatic build-file generator, gazelle, that generates Bazel build files following the conventions that go build would apply, using the dependencies declared in the bazel WORKSPACE.
The WORKSPACE, though, I have to create by hand or by help of a little hackish helper tool, wtool. dep, on the other hand, helps track dependencies, is able to download them into a vendor/ directory and locking specific versions.
To me it appears that the Gopkg.lock file that dep uses to specify versions of dependencies (usually by their VCS commit hash) would be easily translated into a bazel WORKSPACE file. I have successfully done so manually in a company-internal project as well.
Is there an existing link between bazel and its Go rules and dep that I could have used instead of doing this manually?
(Additionally: Is anybody else doing this? Should I be doing this at all?)
There's a pretty new, and actively-being-developed project for this: https://github.com/scele/rules_go_dep.
There's no existing tool for this, but it should be pretty straightforward to convert entries in the lock file to WORKSPACE.
We're thinking of a command to the Gazelle build file generator to help with this (not just for dep, but other tools as well). The main plan is for Gazelle to automatically add repositories that are missing, but that will take more time to implement.
Is there a way to get the sourcecode of a dependency using gradle.
I've found that using the eclipse or the idea plugin may work but I want to keep my code IDE agnostic. Is there a way to obtain the source code for a given dependency? and/or using the eclipse or idea plugin would require me to have those IDE's installed to work?
I noticed this was solved since Gradle 2.0, the source in my case is in:
~/.gradle/caches/modules-2/files-2.1/