- 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
Needs Triage (15)
- Mon, Jan 21, 7:13 PM
Assigned: Info-Screen
Sat, Feb 16
Wed, Feb 13
https://stackoverflow.com/questions/44413952/gradle-implementation-vs-api-configuration suggests that findBugs should be implementation not api.
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
Mon, Feb 11
Basically a tool that looks at what your unit tests do and tries to find cases you might have forgotten
Todo: use "api"
Sun, Feb 10
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?
Sat, Feb 9
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