• Moving User from Java to Kotlin
• Rename .java to .kt
• Moving Users from Java to Kotlin
• Explaining why the let is ?.let and not !!.let & fixing broken Dokka link
• Rename .java to .kt
• Converting LoggedUser to Kotlin
• Added JsonValue.minimalString & JsonValue.prettyString
• Adding LoggedUser.postsList so that Java code can access the posts
• No more parallel unit tests (the testing server can't handle them)
• IssueInTransferException is now able to report on messages that do not parse to JSON
• Better Kotlin integration

https://stackoverflow.com/questions/44413952/gradle-implementation-vs-api-configuration suggests that findBugs should be implementation not api.

In D222#5368, @CLOVIS wrote:

In D222#5365, @Hackintosh5 wrote:

Findbugs should be compileonly.

That's what I thought but findbugs works on the generated JAR, if it's compileOnly findbugs cannot access it

You're right. But D217 is the way to go.

In D222#5365, @Hackintosh5 wrote:

Findbugs should be compileonly.

Findbugs should be compileonly.

I just tested it, it works, so that's getting landed.

• Changing to "API" scope

Basically a tool that looks at what your unit tests do and tries to find cases you might have forgotten

Todo: use "api"

I can add it probably, but I have to admit, I don't even know what coverage is!

This is not the way to do it. Compile is deprecated and should not be used.

@Hackintosh5 would you know how to include this in your gradle engine?

In D214#5271, @Hackintosh5 wrote:

I know how to squash with a rebase if that's what you mean?

I can't close the revision, so I'm just going to request changes :/

Because that revision requires submodule meddling, I've made D220. This one won't be merged.

@Info-Screen this was thrown by the API during testing for this diff:

Rebasing to master to get the new unit tester that is not buggy