Hi Evgeny, > why not https://github.com/scoverage which seems to provide Gradle plugin?
there are my few points why I'd prefer jacoco to other code coverage tools - bytecode instrumentation at runtime (no need to double compile as well as no risk of deploying instrumented code automatically) - the same tool for each language built on top of jvm (my team currently uses java, scala and groovy) - the same analysis and reporting tools (i.e. no need to configure build pipelines somehow differently across different languages) > is there reliable unambiguous way to distinguish bytecode which can be produced by Scala compiler from bytecode which can be produced by Java/Kotlin/Groovy? - modern scala annotates top-level classes with either "scala/reflect/ScalaSignature" or "scala/reflect/ScalaLongSignature" and adds either "ScalaSig" or "Scala" class attributes to the nested classes. - here is the doc (https://www.scala-lang.org/old/sid/10) that can be used as a reference and the corresponding sample <https://github.com/szhem/jacoco/blob/scala-support/org.jacoco.core/src/org/jacoco/core/internal/analysis/filter/ScalaFilter.java#L20> that can be extended by all the scala-related filters <https://github.com/szhem/jacoco/blob/scala-support/org.jacoco.core/src/org/jacoco/core/internal/analysis/filter/ScalaAccessorFilter.java#L29> to prevent affecting filters for other languages. There are three options of adding scala support (and extension points as well) which come to my mind - backporting filters from sbt-scala plugin (I've already done some basic steps) - adding support of java spi to allow adding new filters as easy as just dropping a jar into the build classpath (example is available here <https://github.com/szhem/jacoco/blob/service-loader/org.jacoco.core/src/org/jacoco/core/internal/analysis/filter/Filters.java#L38>, the drawback - it requires java 6) - in case it's necessary to support java 5 as well, java spi sample can be easily replaced with ClassLoader.getResources(...) What do you think? Kind Regards, Sergey On Thursday, February 14, 2019 at 9:57:58 PM UTC+3, Evgeny Mandrikov wrote: > > > > On Thursday, February 14, 2019 at 5:48:41 PM UTC+1, Sergey Zhemzhitsky > wrote: >> >> Thanks a lot for clarification. >> > > BTW even if nice to see interest in JaCoCo for Scala, nevertheless IMO > important to note/ask about alternatives - e.g. why not > https://github.com/scoverage which seems to provide Gradle plugin? > > >> Would you mind if I add the corresponding pull request to support scala >> filters then? >> > > In any case of course you can open pull request! > > However please be aware that > > - filters require clear detailed description and careful testing (unit > tests and so called "validation tests" that use real compiler, etc) - > please have a look at tickets linked from changelog entries about filtering > - our knowledge of Scala is very limited ;) > - as we don't have short-term plans to work on filters for Scala and > taking into account previous point, we can't guarantee that PR will be > immediately reviewed/merged > > So maybe you can start from description here? And IMO the most interesting > question - is there reliable unambiguous way to distinguish bytecode which > can be produced by Scala compiler from bytecode which can be produced by > Java/Kotlin/Groovy? e.g. Kotlin annotates its classes by "kotlin/Metadata", > recent Groovy versions annotate methods by "Generated" - see similar > discussions about Kotlin at > https://github.com/jacoco/jacoco/issues/552#issuecomment-392611472 and > about Groovy at > https://github.com/jacoco/jacoco/pull/733#issuecomment-416176217 > > -- You received this message because you are subscribed to the Google Groups "JaCoCo and EclEmma Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jacoco/77e66ad5-9a42-49a8-8410-514c18f4b476%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
