Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 09:38
    tnielens commented #155
  • Jul 25 22:14
    maiflai commented #155
  • Jul 24 19:59
    maiflai commented #156
  • Jul 24 19:54

    maiflai on 6.0.0

    (compare)

  • Jul 24 19:54

    maiflai on master

    bump gradle plugin publish to 0… (compare)

  • Jul 17 14:07
    eyalroth commented #153
  • Jul 12 21:06

    maiflai on gradle7

    (compare)

  • Jul 12 16:26
    tnielens commented #155
  • Jun 29 19:23
    nicodv commented #89
  • Jun 24 08:02

    maiflai on master

    gradle: wrapper v7.1 Merge pull request #158 from ga… (compare)

  • Jun 24 08:02
    maiflai closed #158
  • Jun 22 18:49
    himanshuupadhyay102 synchronize #16
  • Jun 22 18:35
    himanshuupadhyay102 synchronize #16
  • Jun 18 17:13
    arkangelboss-github commented #156
  • Jun 14 23:30
    arkangelboss-github commented #156
  • Jun 14 22:23
    arkangelboss-github commented #156
  • Jun 14 21:41
    arkangelboss-github commented #156
  • Jun 14 20:51
    gabrieljones opened #158
  • Jun 13 21:43

    maiflai on master

    Use Scala full version in plugi… Merge pull request #155 from he… (compare)

  • Jun 13 21:43
    maiflai closed #155
Tobias Roeser
@lefou
Ok, than I think we should clear if scoverage code (runtime / plugin) touches any API from scala-compiler.
If not, we could remove the dependency and probably also the tight version constraint
Chris Kipp
@ckipp:matrix.org
[m]
indeed
Tobias Roeser
@lefou
I think the plugin does depend on it, as the plugin API comes by the compiler jar
Chris Kipp
@ckipp:matrix.org
[m]
so the latest release is similar to what we see in 1.4.2, which was the last release before I grabbed it
cs resolve -t org.scoverage:scalac-scoverage-runtime_2.12:1.4.2
  Result:
└─ org.scoverage:scalac-scoverage-runtime_2.12:1.4.2
   ├─ org.scala-lang:scala-compiler:2.12.10
   │  ├─ org.scala-lang:scala-library:2.12.10
   │  ├─ org.scala-lang:scala-reflect:2.12.10
   │  │  └─ org.scala-lang:scala-library:2.12.10
   │  └─ org.scala-lang.modules:scala-xml_2.12:1.0.6
   │     └─ org.scala-lang:scala-library:2.12.0 -> 2.12.10
   └─ org.scala-lang:scala-library:2.12.10
Tobias Roeser
@lefou
Ah ok, I just picked 1.4.0 as it was the version used to build to mill contrib module against.
Chris Kipp
@ckipp:matrix.org
[m]
also 1.4.2 probably should have been a 1.5.0 release
and I didn't realize that before releasing 1.4.3
Tobias Roeser
@lefou
Funny thing is, the (old) module itself (built against 1.4.0) works in my setup, but the integration test in mill not :-(
Chris Kipp
@ckipp:matrix.org
[m]
but yea over the coming week or so I'll dig in much deeper and hopefully get a better understanding of this stuff to be able to give better answers
what sort of issues does Mill show?
Tobias Roeser
@lefou
Classloading mainly, e.g. cannot find scala.Option, which is typically a sign for wrong scala versions involved
But I can't find the issue right now
That's why I tried to blame someone else and looked into scoverage. :-D
Chris Kipp
@ckipp:matrix.org
[m]
walks out of the room
😼
btw I have also started publishing snapshot release for every commit
Tobias Roeser
@lefou
Just in case I missinterpet your sense for humor, I was just kidding.
Chris Kipp
@ckipp:matrix.org
[m]
so before a next release we can verify that stuff is worked as expected with Mill as well
haha no worries, I was joking as well
Tobias Roeser
@lefou
\o/
Ok, I'll defer my search for a while. Give me ping if you need my input or some testing
Chris Kipp
@ckipp:matrix.org
[m]
sounds good
Chris Kipp
@ckipp:matrix.org
[m]
If there are any sbt-scoverage users in here, I'd love to get some extra thoughts on this https://github.com/scoverage/sbt-scoverage/pull/253#discussion_r628745184
Cheng Lian
@liancheng

Hello friends! I'm maintaining the OrganizeImports Scalafix rule, which is cross-compiled with Scala 2.11, 2.12, and 2.13, and uses sbt-scoverage. A recent Scala Steward PR (liancheng/scalafix-organize-imports#169) bumping sbt-scoverage version to 1.7.0 failed because Scala 2.11 is no longer supported since 1.7.0.

Seems that I should use different versions of sbt-scoverage for different Scala versions, but I'm not sure how to do that in sbt. Could anyone provide some pointers? Thanks in advance!

Chris Kipp
@ckipp:matrix.org
[m]
Hey @liancheng , so there is a couple different things you can do
  1. Just only run coverage for your own scala version that you are working with, instead of on +test
however, if you want to ensure it runs for all versions, you can dynamically set the coverageScalacPluginVersion to an old one when you are on 2.11
However as I'm typing this I now realize that in order for that to work you'd need to include 1.4.1 for 2.11 support
however 1.4.1 is published differently, not a full binary publish 🤔 and I didn't take that into account with the recent changes to sbt-scoverage to include the compiler plugin differently for versions that didn't publish that way
I may actually need to do some tweaking in order to get that to work with 2.11 on the sbt-scoverage side
Chris Kipp
@ckipp:matrix.org
[m]
actually thinking about it, as much as I wish Scala 2.11 would just go away, I could also just add 2.11.112 back into scoverage
looking back I see where it was removed, but there is no real reason attatched to it. So unless I see a reason that would prohibit it, I might just add it back into the compiler plugin itself
Cheng Lian
@liancheng
Thanks, @ckipp:matrix.org! I'll find some time to give the snapshot version a try!
Oliver Wickham
@ollyw

Hi, I have a project that is using scoverage and noticed that the code coverage skips coverage for macro generated code. This presents a problem when using a macro annotation like so:

@mymacroannotation
object {
    def someActualMethod(): ..
}

Let's say the mymacroannotation injects an extra method, that method should indeed be skipped, but the someActualMethod doesn't need to be skipped because it was created by the user. I have debugged it a little during code generation and it is the following code that is responsible in plugin.sbt

        // ignore macro expanded code, do not send to super as we don't want any children to be instrumented
        case t
            if t.attachments.all
              .toString()
              .contains("MacroExpansionAttachment") =>
          t
If it were possible to modify the inspection of the tree so that the children which have a pos equal to t.poswere ignored, that seems like it would fix it
In this case in t.impl children
if anyone has a clue how to proceed with this, I would be grateful. I am a bit stuck, and currently about 20% of the code base is erroneously ignored
Chris Kipp
@ckipp:matrix.org
[m]
hey @ollyw I know in the past there was some issues with coverage on macros, but don't know the full details of the situation you explained. It's worth creating an issue about it
1 reply
slmzig
@slmzig
HI @ckipp:matrix.org , I have some issues with scoverage-maven-plugin after migration to scala 2.12.13. I have got an error [ERROR] error: java.lang.NoSuchMethodError: scala.tools.nsc.Global.reporter()Lscala/tools/nsc/reporters/Reporter;
Chris Kipp
@ckipp:matrix.org
[m]
Hey @slmzig that's mainly due to the compiler plugin now being published for each full binary version of Scala. The Maven plugin needs to accomodate for this
there hasn't been any active contribution on the maven plugin in quite some time, so it basically needs some love
slmzig
@slmzig
thanks for quick answer @ckipp:matrix.org , ok we need to wait some time.
Chris Kipp
@ckipp:matrix.org
[m]
I'll be honest I have no plans on working on the maven plugin, so it's basically up to someone that is actively using it to step up if they'd like to see it move forward
slmzig
@slmzig

@ckipp:matrix.org also I tried to find some workaround and found By looking at scoverage/sbt-scoverage#321 and related commits it seems like using scalac-scoverage v1.4.3 would fix it, so I tried to force it to use a different one like this:

    <plugin>
        <groupId>org.scoverage</groupId>
        <artifactId>scoverage-maven-plugin</artifactId>
        <version>${scoverage.plugin.version}</version>
        <configuration>
            <scalaVersion>2.12.13</scalaVersion>
            <scalacPluginVersion>1.4.3</scalacPluginVersion>
        </configuration>
    </plugin>

but I've got a new error:

Failure to find org.scoverage:scalac-scoverage-plugin_2.12:jar:1.4.3 in http://repo.mal.internal/content/groups/public was cached in the local rep
ository, resolution will not be reattempted until the update interval of internal.mirror has elapsed or updates are forced

but scalaVersion param accept only 2.10 or 2.11 or 2.13. How I can fix this error?
only by fixing plugin?
Chris Kipp
@ckipp:matrix.org
[m]
yea, it's expected for that to fail, since in reality you aren't looking for 2.12 of the compiler plguin since it's not published. You would need to directly target the 2.12.13 version of the compiler plugin
so yea, afaik, the only way to fix it is by actually fixing the maven plugin