I currently have two protobuf repos: api and timestamp:
timestamp Repo:
- README.md
- timestamp.proto
- timestamp.pb.go
- go.mod
- go.sum
api Repo:
- README.md
- protos/
- dto1.proto
- dto2.proto
Currently, timestamp contains a reference to a timestamp object that I want to use in api but I'm not sure how the import should work or how I should modify the compilation process to handle this. Complicating this process is the fact that the api repo is compiled to a separate, downstream repo for Go called api-go.
For example, consider dto1.proto:
syntax = "proto3";
package api.data;
import "<WHAT GOES HERE?>";
option go_package = "github.com/my-user/api/data"; // golang
message DTO1 {
string id = 1;
Timestamp timestamp = 2;
}
And my compilation command is this:
find $GEN_PROTO_DIR -type f -name "*.proto" -exec protoc \
--go_out=$GEN_OUT_DIR --go_opt=module=github.com/my-user/api-go \
--go-grpc_out=$GEN_OUT_DIR --go-grpc_opt=module=github.com/my-user/api-go \
--grpc-gateway_out=$GEN_OUT_DIR --grpc-gateway_opt logtostderr=true \
--grpc-gateway_opt paths=source_relative --grpc-gateway_opt
generate_unbound_methods=true \{} \;
Assuming I have a definition in timestamp for each of the programming languages I want to compile api into, how would I import this into the .proto file and what should I do to ensure that the import doesn't break in my downstream repo?
There is no native notion of remote import paths with protobuf. So the import path has to be relative to some indicated local filesystem base path (specified via -I / --proto_path).
Option 1
Generally it is easiest to just have a single repository with protobuf definitions for your organisation - e.g. a repository named acme-contract
.
└── protos
└── acme
├── api
│ └── data
│ ├── dto1.proto
│ └── dto2.proto
└── timestamp
└── timestamp.proto
Your dto1.proto will look something like:
syntax = "proto3";
package acme.api.data;
import "acme/timestamp/timestamp.proto";
message DTO1 {
string id = 1;
acme.timestamp.Timestamp timestamp = 2;
}
As long as you generate code relative to the protos/ dir of this repository, there shouldn't be an issue.
Option 2
There are various alternatives whereby you continue to have definitions split over various repositories, but you can't really escape the fact that imports are filesystem relative.
Historically that could be handled by manually cloning the various repositories and arranging directories such that the path are relative, or by using -I to point to various locations that might intentionally or incidentally contain the proto files (e.g. in $GOPATH). Those strategies tend to end up being fairly messy and difficult to maintain.
buf makes things somewhat easier now. If you were to have your timestamp repo:
.
├── buf.gen.yaml
├── buf.work.yaml
├── gen
│ └── acme
│ └── timestamp
│ └── timestamp.pb.go
├── go.mod
├── go.sum
└── protos
├── acme
│ └── timestamp
│ └── timestamp.proto
├── buf.lock
└── buf.yaml
timestamp.proto looking like:
syntax = "proto3";
package acme.timestamp;
option go_package = "github.com/my-user/timestamp/gen/acme/timestamp";
message Timestamp {
int64 unix = 1;
}
buf.gen.yaml looking like:
version: v1
plugins:
- name: go
out: gen
opt: paths=source_relative
- name: go-grpc
out: gen
opt:
- paths=source_relative
- require_unimplemented_servers=false
- name: grpc-gateway
out: gen
opt:
- paths=source_relative
- generate_unbound_methods=true
... and everything under gen/ has been generated via buf generate.
Then in your api repository:
.
├── buf.gen.yaml
├── buf.work.yaml
├── gen
│ └── acme
│ └── api
│ └── data
│ ├── dto1.pb.go
│ └── dto2.pb.go
└── protos
├── acme
│ └── api
│ └── data
│ ├── dto1.proto
│ └── dto2.proto
├── buf.lock
└── buf.yaml
With buf.yaml looking like:
version: v1
name: buf.build/your-user/api
deps:
- buf.build/your-user/timestamp
breaking:
use:
- FILE
lint:
use:
- DEFAULT
dto1.proto looking like:
syntax = "proto3";
package acme.api.data;
import "acme/timestamp/timestamp.proto";
option go_package = "github.com/your-user/api/gen/acme/api/data";
message DTO1 {
string id = 1;
acme.timestamp.Timestamp timestamp = 2;
}
and buf.gen.yaml the same as in the timestamp repo.
The code generated via buf generate will depend on the timestamp repository via Go modules:
// Code generated by protoc-gen-go. DO NOT EDIT.
// versions:
// protoc-gen-go v1.28.1
// protoc (unknown)
// source: acme/api/data/dto1.proto
package data
import (
timestamp "github.com/your-user/timestamp/gen/acme/timestamp"
protoreflect "google.golang.org/protobuf/reflect/protoreflect"
protoimpl "google.golang.org/protobuf/runtime/protoimpl"
reflect "reflect"
sync "sync"
)
// <snip>
Note that if changes are made to dependencies you'll need to ensure that both buf and Go modules are kept relatively in sync.
Option 3
If you prefer not to leverage Go modules for importing generated pb code, you could also look to have a similar setup to Option 2, but instead generate all code into a separate repository (similar to what you're doing now, by the sounds of it). This is most easily achieved by using buf managed mode, which will essentially make it not require + ignore any go_modules directives.
In api-go:
.
├── buf.gen.yaml
├── go.mod
└── go.sum
With buf.gen.yaml containing:
version: v1
managed:
enabled: true
go_package_prefix:
default: github.com/your-user/api-go/gen
plugins:
- name: go
out: gen
opt: paths=source_relative
- name: go-grpc
out: gen
opt:
- paths=source_relative
- require_unimplemented_servers=false
- name: grpc-gateway
out: gen
opt:
- paths=source_relative
- generate_unbound_methods=true
You'd then need to generate code for each respective repo (bushed to BSR):
$ buf generate buf.build/your-user/api
$ buf generate buf.build/your-user/timestamp
After which you should have some generated code for both:
.
├── buf.gen.yaml
├── gen
│ └── acme
│ ├── api
│ │ └── data
│ │ ├── dto1.pb.go
│ │ └── dto2.pb.go
│ └── timestamp
│ └── timestamp.pb.go
├── go.mod
└── go.sum
And the imports will be relative to the current module:
// Code generated by protoc-gen-go. DO NOT EDIT.
// versions:
// protoc-gen-go v1.28.1
// protoc (unknown)
// source: acme/api/data/dto1.proto
package data
import (
timestamp "github.com/your-user/api-go/gen/acme/timestamp"
protoreflect "google.golang.org/protobuf/reflect/protoreflect"
protoimpl "google.golang.org/protobuf/runtime/protoimpl"
reflect "reflect"
sync "sync"
)
// <snip>
All in all, I'd recommend Option 1 - consolidating your protobuf definitions into a single repository (including vendoring 3rd party definitions) - unless there is a particularly strong reason not to.
I have 2 grpc services (service1 and service2) that interact with each other and on some cases the rpc response of service1 will consists of a struct defined in service2, after going to several situations where duplication is inevitable, i figure that as the services grow these will be hard to manage, so i restructure the proto files into something like this for now
.
├── app
...
├── proto
│ ├── service1
│ │ ├── service1.access.proto
│ │ ├── service1.proto
│ ├── service2
│ │ ├── service2.access.proto
│ │ └── service2.proto
│ └── model
│ ├── model.service1.proto
│ └── model.service2.proto
└── proto-gen // the protoc generated files
├── service1
│ ├── service1.access.pb.go
│ └── service1.pb.go
├── service2
│ ├── service2.access.pb.go
│ └── service2.pb.go
└── model
├── model.service1.pb.go
└── model.service2.pb.go
service1 needs to import the model definition on model/model.service2.proto, so i am importing it like this
import "model/model.service2.proto";
option go_package = "proto-gen/service1";
and i generate the .pb.go files, using this protoc command
ls proto | awk '{print "protoc --proto_path=proto proto/"$1"/*.proto --go_out=plugins=grpc:."}' | sh
the command generates the .pb.go files just fine, but the code on service1.access.pb.go doesn't seem to import the model correctly, and i don't know if it related or not but when i run the app, it throws this error
cannot load model: malformed module path "model": missing dot in first path element
i spent a few hours now googling on how can i properly import another proto file, i can't seem to find any solution
The reason you got that error about model is because the generated files use the go_package of the imported file, and model is not a valid import path. You have to convince the generated file to use the full import path of the package.
This is how I did it for my source tree: I have a similar tree of proto files importing each other. If your module is named, say github.com/myapp, then run protoc with --proto-path=<directory containing github.com>, import other proto files using full path, that is github.com/myapp/proto/service1/service1.proto, and in service1.proto, define go_package = service1. This setup writes the import paths correctly in my case.
Before settling into this solution, I was using go_package=<full path to proto>, so you might give that a try as well.
Building on Burak Serdar, I want to provide my implementation.
Set the package on the proto you want to import similar to this where the location is your full path. My path is generally github.com/AllenKaplan/[project]/[package]/proto/
option go_package = [path];
In the file you wish to import to add an import. My path is generally [package]/proto/[package].proto
import = [path from protoc proto path]
The last part is the protoc command where you must define the protopath in a way that connects the import path and option go_package path
if executing from the github.com/AllenKaplan/[project] directory, I would call
protoc -I. --go_out=./[package]/proto [package]/proto/[package].proto
-I. === --proto_path.
the -I. sets the protopath to the entire project
One note, when calling protoc on your .proto files that you are importing, you will want to add source_relative: to the output will ensure the output is from the root with a set package.
My implementation of the imported protoc when called from github.com/AllenKaplan/[project]/[package]
protoc -I./proto --go_out=paths=source_relative:./proto [package].proto
I was also facing a similar issue while importing. Had changed the .protoc file option package with the following.
option go_package = "./;proto-gen/service1";
The first param means relative path where the code you want to generate.
The path relative to the --go_out , you set in your command.
Yesterday I helped a colleague install go on his Windows 10 PC. We downloaded and installed the latest (v1.12.5) from golang.org. No errors were reported during the install. We ran into problems trying to get and build a private project we're collaborating on.
The first problem was trying to use go get to fetch the project into the go/src tree. It prompted for his GitHub password and appeared to be downloading but failed with a complaint that the project contained no Go files. So we git cloned the project directly under C:\go\src. That succeeded, but attempting to build produces complaints about "use of internal package not allowed".
There are multiple prior reports of this error message on SO (e.g. golang disable "use of internal package not allowed") and as issues in golang/go (e.g. https://github.com/golang/go/issues/26446) but most of the discussions explain the problem as having to do with attempts to import from internals of packages with repositories outside the project root. That's not the case here.
The project is pure Go and all of the code in the repo builds successfully on OS-X and Linux.
For the above reasons, I believe this question is not a duplicate.
For reference, here is a much reduced view of the project directory installed under the go/src tree showing one of the files that produces the error when attempting to run go build. In this case the complaint references the internal/ace/ package as the disallowed import but the problem also occurs in other subdirectories (not shown) that import from other internal packages (also not shown.)
go
└── src
├── github.com
│ ├── Michael-F-Ellis
│ │ ├── pgcgo
│ │ │ ├── internal
│ │ │ │ ├── ace
│ │ │ ├── setacertc
│ │ │ ├ ├── main.go
Here is the outline of setacertc/main.go:
// setacertc is intended to be run from an internet-connected host to
// set the real-time-clock on the ACE11.
package main
import (
"fmt"
"log"
"math/rand"
"time"
"github.com/Michael-F-Ellis/pgcgo/internal/ace"
)
func main() {
// SNIP
}
I suspect the problem is somehow specific to a new installation and/or running Go under Windows. Any help appreciated.
I try understand how to organize go code using "internal" packages. Let me show what the structure I have:
project/
internal/
foo/
foo.go # package foo
bar/
bar.go # package bar
main.go
# here is the code from main.go
package main
import (
"project/internal/foo"
"project/internal/bar"
)
project/ is outside from GOPATH tree. Whatever path I try to import from main.go nothing works, the only case working fine is import "./internal/foo|bar". I think I do something wrong or get "internal" package idea wrong in general. Could anybody make things clearer, please?
UPDATE
The example above is correct the only what I need was to place project/ folder under $GOPATH/src. So the thing is import path like the project/internal/foo|bar is workable if we only import it from project/ subtree and not from the outside.
With modules introduction in Go v1.11 and above you don't have to specify your project path in $GOPATH/src
You need to tell Go about where each module located by creating go.mod file. Please refer to go help mod documentation.
Here is an example of how to do it:
project
| go.mod
| main.go
|
\---internal
+---bar
| bar.go
| go.mod
|
\---foo
foo.go
go.mod
project/internal/bar/go.mod
module bar
go 1.14
project/internal/bar/bar.go
package bar
import "fmt"
//Bar prints "Hello from Bar"
func Bar() {
fmt.Println("Hello from Bar")
}
project/internal/foo/go.mod
module foo
go 1.14
project/internal/foo/foo.go
package foo
import "fmt"
//Foo prints "Hello from Foo"
func Foo() {
fmt.Println("Hello from Foo")
}
project/main.go
package main
import (
"internal/bar"
"internal/foo"
)
func main() {
bar.Bar()
foo.Foo()
}
Now the most important module
project/go.mod
module project
go 1.14
require internal/bar v1.0.0
replace internal/bar => ./internal/bar
require internal/foo v1.0.0
replace internal/foo => ./internal/foo
Couple things here:
You can have any name in require. You can have project/internal/bar if you wish. What Go think it is URL address for the package, so it will try to pull it from web and give you error
go: internal/bar#v1.0.0: malformed module path "internal/bar": missing dot in first path element
That is the reason why you need to have replace where you tell Go where to find it, and that is the key!
replace internal/bar => ./internal/bar
The version doesn't matter in this case. You can have v0.0.0 and it will work.
Now, when you execute your code you will have
Hello from Bar
Hello from Foo
Here is GitHub link for this code example
The packages have to be located in your $GOPATH in order to be imported. The example you gave with import "./internal/foo|bar" works because it does a local-import. internal only makes it so code that doesn't share a common root directory to your internal directory can't import the packages within internal.
If you put all this in your gopath then tried to import from a different location like OuterFolder/project2/main.go where OuterFolder contains both project and project2 then import "../../project/internal/foo" would fail. It would also fail as import "foo" or any other way your tried due to not satisfying this condition;
An import of a path containing the element “internal” is disallowed if
the importing code is outside the tree rooted at the parent of the
“internal” directory.
Now if you had the path $GOPATH/src/project then you could do import "foo" and import "bar" from within $GOPATH/src/project/main.go and the import would succeed. Things that are not contained underneath project however would not be able to import foo or bar.
below way is more scalable, especially when you plan to build multiple binaries
github.com/servi-io/api
├── cmd/
│ ├── servi/
│ │ ├── cmdupdate/
│ │ ├── cmdquery/
│ │ └── main.go
│ └── servid/
│ ├── routes/
│ │ └── handlers/
│ ├── tests/
│ └── main.go
├── internal/
│ ├── attachments/
│ ├── locations/
│ ├── orders/
│ │ ├── customers/
│ │ ├── items/
│ │ ├── tags/
│ │ └── orders.go
│ ├── registrations/
│ └── platform/
│ ├── crypto/
│ ├── mongo/
│ └── json/
The folders inside cmd/ represents the number of binaries you want to build.
for more
Also to check: When you are using your externally imported object types: make sure you are prefixing them with the namespace they're in. As a golang newbie, I didn't know I had to do that, and was wondering why is VS Code just removing my import (for not being used) when I saved. It's because I had to prefix the imported object with the namespace name:
Example:
import (
"myInternalPackageName" // works fine as long as you follow all instructions in this thread
)
//Usage in code:
myInternalPackageName.TheStructName // prefix it, or it won't work.
If you don't put the namespace prefix before the object/struct name, VS code just removes your import for being unused, and then you still have the error: "Can't find TheStructName"... That was very confusing, and I had to do a build without VS code through the command line to understand that.
The point is: I had to specify the package prefix when actually using the struct from that internal package.
If you don't want to use the qualifier prefix when using imported objects, use:
import . "thePath" // Can use contents without prefixing.
Reference: What does the '.' (dot or period) in a Go import statement do?
everyone!
The main problem is that I fail to build my Play Framework 2.4.0 application with Gradle 2.6.
The following is my build.gradle file (nothing special, everything here is from the official docs on using gradle with play framework https://docs.gradle.org/current/userguide/play_plugin.html):
plugins {
id 'play'
}
repositories {
jcenter()
maven {
name "typesafe-maven-release"
url "https://repo.typesafe.com/typesafe/maven-releases"
}
ivy {
name "typesafe-ivy-release"
url "https://repo.typesafe.com/typesafe/ivy-releases"
layout "ivy"
}
mavenCentral()
}
model {
components {
play {
platform play: '2.4.0'
}
}
}
I used playBinary, runPlayBinary and the composite tasks one by one (such as compilePlayBinaryRoutes, compilePlayBinaryTwirlTemplates and compilePlayBinaryScala), however the result is essentially the same every time:
~/projects/QuickBlox-ChatStatsUIApp/ChatStatsUI$ gradle playBinary
:compilePlayBinaryRoutes UP-TO-DATE
:compilePlayBinaryTwirlTemplates UP-TO-DATE
:compilePlayBinaryScala
/home/qb-user/projects/QuickBlox-ChatStatsUIApp/ChatStatsUI/build/playBinary/src/compilePlayBinaryRoutes/router/Routes.scala:56: value index is not a member of object controllers.Application
controllers.Application.index(),
^
/home/qb-user/projects/QuickBlox-ChatStatsUIApp/ChatStatsUI/build/playBinary/src/compilePlayBinaryRoutes/router/Routes.scala:73: value updateSettings is not a member of object controllers.Application
controllers.Application.updateSettings(),
^
/home/qb-user/projects/QuickBlox-ChatStatsUIApp/ChatStatsUI/build/playBinary/src/compilePlayBinaryRoutes/router/Routes.scala:107: value getResource is not a member of object controllers.Application
controllers.Application.getResource(fakeValue[String]),
^
/home/qb-user/projects/QuickBlox-ChatStatsUIApp/ChatStatsUI/build/playBinary/src/compilePlayBinaryTwirlTemplates/views/html/index.template.scala:75: value get is not a member of List[String]
"""),format.raw/*57.25*/("""<tr class=""""),_display_(/*57.37*/abbreviations/*57.50*/.get(i)),format.raw/*57.57*/("""_"""),_display_(/*57.59*/i),format.raw/*57.60*/("""" title=""""),_display_(/*57.70*/keysToParse/*57.81*/.get(i + 1)),format.raw/*57.92*/(""""><td>"""),_display_(/*57.99*/abbreviations/*57.112*/.get(i)),format.raw/*57.119*/(""" """),format.raw/*57.120*/("""sum : </td><td>"""),_display_(/*57.136*/aggrResults/*57.147*/.get(i)),format.raw/*57.154*/("""</td></tr>
^
/home/qb-user/projects/QuickBlox-ChatStatsUIApp/ChatStatsUI/build/playBinary/src/compilePlayBinaryTwirlTemplates/views/html/index.template.scala:75: value get is not a member of List[String]
"""),format.raw/*57.25*/("""<tr class=""""),_display_(/*57.37*/abbreviations/*57.50*/.get(i)),format.raw/*57.57*/("""_"""),_display_(/*57.59*/i),format.raw/*57.60*/("""" title=""""),_display_(/*57.70*/keysToParse/*57.81*/.get(i + 1)),format.raw/*57.92*/(""""><td>"""),_display_(/*57.99*/abbreviations/*57.112*/.get(i)),format.raw/*57.119*/(""" """),format.raw/*57.120*/("""sum : </td><td>"""),_display_(/*57.136*/aggrResults/*57.147*/.get(i)),format.raw/*57.154*/("""</td></tr>
^
/home/qb-user/projects/QuickBlox-ChatStatsUIApp/ChatStatsUI/build/playBinary/src/compilePlayBinaryTwirlTemplates/views/html/index.template.scala:75: value get is not a member of List[String]
"""),format.raw/*57.25*/("""<tr class=""""),_display_(/*57.37*/abbreviations/*57.50*/.get(i)),format.raw/*57.57*/("""_"""),_display_(/*57.59*/i),format.raw/*57.60*/("""" title=""""),_display_(/*57.70*/keysToParse/*57.81*/.get(i + 1)),format.raw/*57.92*/(""""><td>"""),_display_(/*57.99*/abbreviations/*57.112*/.get(i)),format.raw/*57.119*/(""" """),format.raw/*57.120*/("""sum : </td><td>"""),_display_(/*57.136*/aggrResults/*57.147*/.get(i)),format.raw/*57.154*/("""</td></tr>
^
/home/qb-user/projects/QuickBlox-ChatStatsUIApp/ChatStatsUI/build/playBinary/src/compilePlayBinaryTwirlTemplates/views/html/index.template.scala:75: value get is not a member of List[Long]
"""),format.raw/*57.25*/("""<tr class=""""),_display_(/*57.37*/abbreviations/*57.50*/.get(i)),format.raw/*57.57*/("""_"""),_display_(/*57.59*/i),format.raw/*57.60*/("""" title=""""),_display_(/*57.70*/keysToParse/*57.81*/.get(i + 1)),format.raw/*57.92*/(""""><td>"""),_display_(/*57.99*/abbreviations/*57.112*/.get(i)),format.raw/*57.119*/(""" """),format.raw/*57.120*/("""sum : </td><td>"""),_display_(/*57.136*/aggrResults/*57.147*/.get(i)),format.raw/*57.154*/("""</td></tr>
^
/home/qb-user/projects/QuickBlox-ChatStatsUIApp/ChatStatsUI/build/playBinary/src/compilePlayBinaryTwirlTemplates/views/html/index.template.scala:158: value get is not a member of List[String]
document.getElementById('timeLength').value = '"""),_display_(/*140.73*/timeLengths/*140.84*/.get(1)),format.raw/*140.91*/("""'""")))}/*140.94*/else/*140.99*/{_display_(Seq[Any](format.raw/*140.100*/("""
^
/home/qb-user/projects/QuickBlox-ChatStatsUIApp/ChatStatsUI/build/playBinary/src/compilePlayBinaryTwirlTemplates/views/html/index.template.scala:182: value get is not a member of List[String]
"""),format.raw/*164.41*/("""<span title=""""),_display_(/*164.55*/keysToParse/*164.66*/.get(i + 1)),format.raw/*164.77*/("""" class=""""),_display_(/*164.87*/abbreviations/*164.100*/.get(i)),format.raw/*164.107*/("""_"""),_display_(/*164.109*/i),format.raw/*164.110*/(""""><input type="checkbox" id=""""),_display_(/*164.140*/i),format.raw/*164.141*/("""" checked onclick="change(this)">"""),_display_(/*164.175*/abbreviations/*164.188*/.get(i)),format.raw/*164.195*/("""</span>
^
/home/qb-user/projects/QuickBlox-ChatStatsUIApp/ChatStatsUI/build/playBinary/src/compilePlayBinaryTwirlTemplates/views/html/index.template.scala:182: value get is not a member of List[String]
"""),format.raw/*164.41*/("""<span title=""""),_display_(/*164.55*/keysToParse/*164.66*/.get(i + 1)),format.raw/*164.77*/("""" class=""""),_display_(/*164.87*/abbreviations/*164.100*/.get(i)),format.raw/*164.107*/("""_"""),_display_(/*164.109*/i),format.raw/*164.110*/(""""><input type="checkbox" id=""""),_display_(/*164.140*/i),format.raw/*164.141*/("""" checked onclick="change(this)">"""),_display_(/*164.175*/abbreviations/*164.188*/.get(i)),format.raw/*164.195*/("""</span>
^
/home/qb-user/projects/QuickBlox-ChatStatsUIApp/ChatStatsUI/build/playBinary/src/compilePlayBinaryTwirlTemplates/views/html/index.template.scala:182: value get is not a member of List[String]
"""),format.raw/*164.41*/("""<span title=""""),_display_(/*164.55*/keysToParse/*164.66*/.get(i + 1)),format.raw/*164.77*/("""" class=""""),_display_(/*164.87*/abbreviations/*164.100*/.get(i)),format.raw/*164.107*/("""_"""),_display_(/*164.109*/i),format.raw/*164.110*/(""""><input type="checkbox" id=""""),_display_(/*164.140*/i),format.raw/*164.141*/("""" checked onclick="change(this)">"""),_display_(/*164.175*/abbreviations/*164.188*/.get(i)),format.raw/*164.195*/("""</span>
^
11 errors found
:compilePlayBinaryScala FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':compilePlayBinaryScala'.
> Compilation failed
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
BUILD FAILED
Total time: 8.445 secs
And here's the structure of the build directory, after build failure:
build
├── playBinary
│ ├── classes
│ └── src
│ ├── compilePlayBinaryRoutes
│ │ ├── controllers
│ │ │ ├── javascript
│ │ │ │ └── JavaScriptReverseRoutes.scala
│ │ │ ├── ReverseRoutes.scala
│ │ │ └── routes.java
│ │ └── router
│ │ ├── RoutesPrefix.scala
│ │ └── Routes.scala
│ └── compilePlayBinaryTwirlTemplates
│ └── views
│ └── html
│ └── index.template.scala
└── tmp
└── compilePlayBinaryScala
My guess is that it might have something to do with the fact, that Gradle 2.6 doesn't support reverse routing for now. I tried creating a new Play application (2.4.2 this time) and built it straight away, however it also failed on the same part:
controllers.Application.index(),
^
So let's go one by one:
All the errors after the first 3 were my mistakes, but I somehow assumed, that they were caused by the first 3. All of those were basically the result of not proper treating of the data structures in scala (my bad, I'm a noob there).
The first 3 however were caused by the fact, that I had non-static methods in my main Controller. Somehow, I must have overlooked the fact, that you have to prefix your non-static methods calls in routes file with a '#' sign. So the solution is to either place the prefix in the routes file, or make methods static.
The only reference to this (static/non-static behavior), that I found is a scarce mentioning here (https://www.playframework.com/documentation/2.4.0/JavaRouting#Dependency-Injection [last line of this paragraph]).