Support https

[Jentsch]

Currently all references to external resources done via http. This is an issue if you try to serve the results of scoverage via https. In this case modern browsers are blocking the those resources. Are there any reasons not use https? Otherwise I would open a pull request that just replaces http with https in relevant places.

[gslowikowski]

This was already fixed.

[jfklingler]

We're running into the same problem. It has been fixed in the latest snapshot, but there hasn't been a release yet. We tried using the snapshots of sbt-scoverage/scalac-coverage-plugin, and it worked for a bit, but then a snapshot update broke everything. (Not complaining - snapshots are't supposed to be stable.) Only once scalac-scoverage-plugin is released, can the build plugins (sbt-scoverage, etc.) update and release to finally fix this issue.

[sksamuel]

I can do a new release of the plugin but there's some confusion over a ticket. If @gslowikowski can confirm we're ready to release (or what I need to revert to be ready) then putting a release onto maven central is easy.

[gslowikowski]

The problematic PRs are #167 (issue #165) and #169.
I would like to have test project for this issue. I have the feeling, that this is only user's project misconfiguration, not a real issue. We need @maiflai help here.

If the users want 1.2.0 release quickly (and they want it), I would recommend to revert changes coming from #167 and #169, make a release, and return to this problem afterwards.

Additionally, sbt-scoverage project in master is broken. There are some PRs fixing it (I tested scoverage/sbt-scoverage#168).

[maiflai]

Sorry for not keeping in touch - from the Gradle side I agree that the problem is likely related to the Gradle configuration rather than the scalac plugin.

Personally I think that the reporter should fail if it can't find the appropriate source file; I've had trouble understanding blank Sonar reports because it too silently skips things...

I agree that those PRs should be rolled back if they were only introduced to work around this issue, I'm happy to work through it on the Gradle side.

For what it's worth - apparently it's possible to omit the protocol from the CDN urls and then it will simply default to the protocol that the resource is served under. This might be more friendly than forcing HTTPS?

[gslowikowski]

Omitting protocol will not work when browsing from local filesystem.

[maiflai]

Ah, yes, good point

[ericbroder]

+1 for this. I am also having this problem which was apparently fixed here: 9ff7e25

But fix not released yet.

[ericbroder]

Thanks, this is resolved now.