https://kotlinlang.org logo
Title
a

Alan Evans

11/12/2018, 9:54 PM
I would achieve this by modularizing the moshi classes into their own module. Such that only changes to that module will cause the moshi kapt to run again. Advantage, your tests and release build times will also be faster, unlike any hack solution that only makes debug builds faster.
p

Paul Woitaschek

11/13/2018, 9:23 AM
moshi has a reflection dependency but in release builds I want to have generated adapters.
I solved it by adding another build type for tests:
buildTypes {
    forTests {
      initWith debug
      matchingFallbacks = ["debug"]
    }
  }

  ...
  kaptRelease(Deps.Moshi.compiler)
  kaptForTests(Deps.Moshi.compiler)
a

Alan Evans

11/13/2018, 11:52 AM
Oh I see, out of interest, why don't you want reflection for tests? If you don't trust their adapter generation, wouldn't running
TestRelease
test it?
p

Paul Woitaschek

11/13/2018, 1:28 PM
I trust their adapter generation, I just don't trust mine 😉
For example I test the polymorphic adapter as it has to be set up by hand. Also I have polymorphic adapters where some parts are hand written and others autogenerated
g

GurpreetSK

11/13/2018, 4:25 PM
I might be late (or maybe not helpful), but moshi 1.8 supports codegen and reflection based deserialisation as per your needs. You can use reflection for dev builds, and codegen for rest variants.
p

Paul Woitaschek

11/13/2018, 5:14 PM
I know thats what this is all about