New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Version 1.0.0 appears to be broken with latest version of sbt #62

Closed
jedesah opened this Issue Sep 25, 2015 · 24 comments

Comments

Projects
None yet
7 participants
@jedesah
Contributor

jedesah commented Sep 25, 2015

Looking at CoberturaReader in version 1.0.0, it looks very fragile and sure enough with sbt 0.13.9, source files are not found because they are missing the src / main / scala in the path.

I don't know if sbt changed it's behavior in a recent version, I suspect it used to store the class files under target under src / main / scala and does not do so anymore. CoberturaMultiSourceReader seems like it should behave fine for our build, so maybe all that is needed is a new release.

@rorygraves

This comment has been minimized.

Show comment
Hide comment
@rorygraves

rorygraves Sep 25, 2015

Contributor

I think this needs some more investigation - I had a brief fiddle with this and it was still not working correctly for the multi-module ensime project. I'm hoping to look at this in anger within the next couple of weeks because I should have some more time in about a week.

Contributor

rorygraves commented Sep 25, 2015

I think this needs some more investigation - I had a brief fiddle with this and it was still not working correctly for the multi-module ensime project. I'm hoping to look at this in anger within the next couple of weeks because I should have some more time in about a week.

@jedesah

This comment has been minimized.

Show comment
Hide comment
@jedesah

jedesah Sep 25, 2015

Contributor

As I hinted in the description, I think this is probably fixed in master. If I can confirm this, can we do a snapshot release?

Contributor

jedesah commented Sep 25, 2015

As I hinted in the description, I think this is probably fixed in master. If I can confirm this, can we do a snapshot release?

@rorygraves

This comment has been minimized.

Show comment
Hide comment
@rorygraves

rorygraves Sep 25, 2015

Contributor

Yes. Or even 1.0.1

Contributor

rorygraves commented Sep 25, 2015

Yes. Or even 1.0.1

@jedesah

This comment has been minimized.

Show comment
Hide comment
@jedesah

jedesah Sep 25, 2015

Contributor

Ok, I just tried the master version of the plugin on our build and it works!

Contributor

jedesah commented Sep 25, 2015

Ok, I just tried the master version of the plugin on our build and it works!

@alexflav23

This comment has been minimized.

Show comment
Hide comment
@alexflav23

alexflav23 Sep 29, 2015

@jedesah @rorygraves Any chance a new release will be out anytime soon to fix the multi-build issues? It's been quite a while since coverage is missing from the scene and it would be great to restore things to the right order. Let me know if I can help with any dev effort.

alexflav23 commented Sep 29, 2015

@jedesah @rorygraves Any chance a new release will be out anytime soon to fix the multi-build issues? It's been quite a while since coverage is missing from the scene and it would be great to restore things to the right order. Let me know if I can help with any dev effort.

@lenzenc

This comment has been minimized.

Show comment
Hide comment
@lenzenc

lenzenc Oct 3, 2015

Any update on a fix for this issue?

lenzenc commented Oct 3, 2015

Any update on a fix for this issue?

@kshakir

This comment has been minimized.

Show comment
Hide comment
@kshakir

kshakir Oct 9, 2015

Contributor

I just tried a custom build of c64417d, and still ran into this issue on travis. The CoberturaMultiSourceReader cannot locate the files, and is generating a coveralls.json with an empty "source_files": []. This is also testable locally, by running sbt coveralls, where the coveralls.json is still generated, even though it won't be sent to coveralls.io unless further configured.

No idea if this issue is because of a newer version of sbt, a non-multi-build problem, or just a general bug in the CoberturaMultiSourceReader.

The cobertura.xml generated by sbt coverage test lists the paths as:

  • src/main/scala/org/example/MyClass.scala

Meanwhile, the (sourceDirectories in Compile) returns:

  • /Users/kshakir/src/example/src/main/scala-2.11
  • /Users/kshakir/src/example/src/main/scala
  • /Users/kshakir/src/example/src/main/java
  • /Users/kshakir/src/example/target/scala-2.11/src_managed/main

Thus the full paths incorrectly resolve to:

  • /Users/kshakir/src/example/src/main/scala/src/main/scala/org/example/MyClass.scala

A workaround that works for me in .travis.yml is to hack the sources used in the after_success:

sudo: false
language: scala
scala:
  - 2.11.7
jdk:
  - oraclejdk8

script: sbt clean coverage test
after_success: sbt 'set unmanagedSourceDirectories in Compile := Seq(file("."))' coveralls

TL;DR: Try sbt 'set unmanagedSourceDirectories in Compile := Seq(file("."))' coveralls

Contributor

kshakir commented Oct 9, 2015

I just tried a custom build of c64417d, and still ran into this issue on travis. The CoberturaMultiSourceReader cannot locate the files, and is generating a coveralls.json with an empty "source_files": []. This is also testable locally, by running sbt coveralls, where the coveralls.json is still generated, even though it won't be sent to coveralls.io unless further configured.

No idea if this issue is because of a newer version of sbt, a non-multi-build problem, or just a general bug in the CoberturaMultiSourceReader.

The cobertura.xml generated by sbt coverage test lists the paths as:

  • src/main/scala/org/example/MyClass.scala

Meanwhile, the (sourceDirectories in Compile) returns:

  • /Users/kshakir/src/example/src/main/scala-2.11
  • /Users/kshakir/src/example/src/main/scala
  • /Users/kshakir/src/example/src/main/java
  • /Users/kshakir/src/example/target/scala-2.11/src_managed/main

Thus the full paths incorrectly resolve to:

  • /Users/kshakir/src/example/src/main/scala/src/main/scala/org/example/MyClass.scala

A workaround that works for me in .travis.yml is to hack the sources used in the after_success:

sudo: false
language: scala
scala:
  - 2.11.7
jdk:
  - oraclejdk8

script: sbt clean coverage test
after_success: sbt 'set unmanagedSourceDirectories in Compile := Seq(file("."))' coveralls

TL;DR: Try sbt 'set unmanagedSourceDirectories in Compile := Seq(file("."))' coveralls

@rorygraves

This comment has been minimized.

Show comment
Hide comment
@rorygraves

rorygraves Oct 9, 2015

Contributor

Hi, this is a known issue and is on my list to fix as soon as I'm able to.

Thanks for the hint btw ;)

On 9 Oct 2015, at 19:01, kshakir notifications@github.com wrote:

I just tried a custom build of c64417d, and still ran into this issue on travis. The CoberturaMultiSourceReader cannot locate the files, and is generating a coveralls.json with an empty "source_files": []. This is also testable locally, by running sbt coveralls, where the coveralls.json is still generated, even though it won't be sent to coveralls.io unless further configured.

No idea if this issue is because of a newer version of sbt, a non-multi-build problem, or just a general bug in the CoberturaMultiSourceReader.

The cobertura.xml generated by sbt coverage test lists the paths as:

src/main/scala/org/example/MyClass.scala
Meanwhile, the (sourceDirectories in Compile) returns:

/Users/kshakir/src/example/src/main/scala-2.11
/Users/kshakir/src/example/src/main/scala
/Users/kshakir/src/example/src/main/java
/Users/kshakir/src/example/target/scala-2.11/src_managed/main
Thus the full paths incorrectly resolve to:

/Users/kshakir/src/example/src/main/scala/src/main/scala/org/example/MyClass.scala
A workaround that works for me in .travis.yml is to hack the sources used in the after_success:

sudo: false
language: scala
scala:

  • 2.11.7
    jdk:
  • oraclejdk8

script: sbt clean coverage test
after_success: sbt 'set unmanagedSourceDirectories in Compile := Seq(file("."))' coveralls
TL;DR: Try sbt 'set unmanagedSourceDirectories in Compile := Seq(file("."))' coveralls


Reply to this email directly or view it on GitHub.

Contributor

rorygraves commented Oct 9, 2015

Hi, this is a known issue and is on my list to fix as soon as I'm able to.

Thanks for the hint btw ;)

On 9 Oct 2015, at 19:01, kshakir notifications@github.com wrote:

I just tried a custom build of c64417d, and still ran into this issue on travis. The CoberturaMultiSourceReader cannot locate the files, and is generating a coveralls.json with an empty "source_files": []. This is also testable locally, by running sbt coveralls, where the coveralls.json is still generated, even though it won't be sent to coveralls.io unless further configured.

No idea if this issue is because of a newer version of sbt, a non-multi-build problem, or just a general bug in the CoberturaMultiSourceReader.

The cobertura.xml generated by sbt coverage test lists the paths as:

src/main/scala/org/example/MyClass.scala
Meanwhile, the (sourceDirectories in Compile) returns:

/Users/kshakir/src/example/src/main/scala-2.11
/Users/kshakir/src/example/src/main/scala
/Users/kshakir/src/example/src/main/java
/Users/kshakir/src/example/target/scala-2.11/src_managed/main
Thus the full paths incorrectly resolve to:

/Users/kshakir/src/example/src/main/scala/src/main/scala/org/example/MyClass.scala
A workaround that works for me in .travis.yml is to hack the sources used in the after_success:

sudo: false
language: scala
scala:

  • 2.11.7
    jdk:
  • oraclejdk8

script: sbt clean coverage test
after_success: sbt 'set unmanagedSourceDirectories in Compile := Seq(file("."))' coveralls
TL;DR: Try sbt 'set unmanagedSourceDirectories in Compile := Seq(file("."))' coveralls


Reply to this email directly or view it on GitHub.

@alexflav23

This comment has been minimized.

Show comment
Hide comment
@alexflav23

alexflav23 commented Oct 23, 2015

Hi @rorygraves,

Any updates?

@rorygraves

This comment has been minimized.

Show comment
Hide comment
@rorygraves

rorygraves Oct 26, 2015

Contributor

I'm working on it this week.

Contributor

rorygraves commented Oct 26, 2015

I'm working on it this week.

@jedesah

This comment has been minimized.

Show comment
Hide comment
@jedesah

jedesah Oct 26, 2015

Contributor

Yay! Just flattred the repo to show my appreciation! 😄

Contributor

jedesah commented Oct 26, 2015

Yay! Just flattred the repo to show my appreciation! 😄

@rorygraves

This comment has been minimized.

Show comment
Hide comment
@rorygraves

rorygraves Nov 2, 2015

Contributor

I haven't forgotten - I can see the issue, just trying to work out the 'right' fix without borking everything

Contributor

rorygraves commented Nov 2, 2015

I haven't forgotten - I can see the issue, just trying to work out the 'right' fix without borking everything

@alexflav23

This comment has been minimized.

Show comment
Hide comment
@alexflav23

alexflav23 Nov 14, 2015

@rorygraves Any news on this and anything the community can do to help? This is the main coveralls plugin and its currently broken for the whole eco-system.

alexflav23 commented Nov 14, 2015

@rorygraves Any news on this and anything the community can do to help? This is the main coveralls plugin and its currently broken for the whole eco-system.

@rorygraves

This comment has been minimized.

Show comment
Hide comment
@rorygraves

rorygraves Nov 14, 2015

Contributor

Hi @alexflav23 Sorry for the slow process, life and illness have been slowing me down. I believe I understand the issue and am hoping to have a PR together this weekend.

Contributor

rorygraves commented Nov 14, 2015

Hi @alexflav23 Sorry for the slow process, life and illness have been slowing me down. I believe I understand the issue and am hoping to have a PR together this weekend.

@rorygraves

This comment has been minimized.

Show comment
Hide comment
@rorygraves

rorygraves Nov 22, 2015

Contributor

A quick update, I believe I actually have a working fix, I'm just tidying up and PR will be tonight or tomorrow.

Contributor

rorygraves commented Nov 22, 2015

A quick update, I believe I actually have a working fix, I'm just tidying up and PR will be tonight or tomorrow.

@alexflav23

This comment has been minimized.

Show comment
Hide comment
@alexflav23

alexflav23 Nov 22, 2015

Hi @rorygraves,

That's great news, really looking forward to it.

alexflav23 commented Nov 22, 2015

Hi @rorygraves,

That's great news, really looking forward to it.

@alexflav23

This comment has been minimized.

Show comment
Hide comment
@alexflav23

alexflav23 commented Dec 5, 2015

Hi @rorygraves,

Any news?

@rorygraves

This comment has been minimized.

Show comment
Hide comment
@rorygraves

rorygraves Dec 5, 2015

Contributor

Waiting on @gslowikowski to review and @sksamuel to merge release.

Contributor

rorygraves commented Dec 5, 2015

Waiting on @gslowikowski to review and @sksamuel to merge release.

@sksamuel

This comment has been minimized.

Show comment
Hide comment
@sksamuel

sksamuel Dec 6, 2015

Member

@rorygraves are you just wanting me to do a 1.0.1 release of master ?

Member

sksamuel commented Dec 6, 2015

@rorygraves are you just wanting me to do a 1.0.1 release of master ?

@sksamuel

This comment has been minimized.

Show comment
Hide comment
@sksamuel

sksamuel Dec 8, 2015

Member

I've released 1.0.2 to maven central. Note: That's maven central NOT bintray (as I continue to have issues with that). @alexflav23

Member

sksamuel commented Dec 8, 2015

I've released 1.0.2 to maven central. Note: That's maven central NOT bintray (as I continue to have issues with that). @alexflav23

@sksamuel sksamuel closed this Dec 8, 2015

@alexflav23

This comment has been minimized.

Show comment
Hide comment
@alexflav23

alexflav23 Dec 8, 2015

HI @sksamuel,

What's the issue with Bintray, can I help with anything? Otherwise many thanks, means everyone can already start using it.

alexflav23 commented Dec 8, 2015

HI @sksamuel,

What's the issue with Bintray, can I help with anything? Otherwise many thanks, means everyone can already start using it.

@sksamuel

This comment has been minimized.

Show comment
Hide comment
@sksamuel

sksamuel Dec 8, 2015

Member

Can't get bintray to sync with the sbt repo. But it doesn't matter, there's
no reason to use it. Can just use sonatype which I'm familiar with and
everyone has access to maven central.

On 8 December 2015 at 13:34, Flavian Alexandru notifications@github.com
wrote:

HI @sksamuel https://github.com/sksamuel,

What's the issue with Bintray, can I help with anything? Otherwise many
thanks, means everyone can already start using it.


Reply to this email directly or view it on GitHub
#62 (comment)
.

Member

sksamuel commented Dec 8, 2015

Can't get bintray to sync with the sbt repo. But it doesn't matter, there's
no reason to use it. Can just use sonatype which I'm familiar with and
everyone has access to maven central.

On 8 December 2015 at 13:34, Flavian Alexandru notifications@github.com
wrote:

HI @sksamuel https://github.com/sksamuel,

What's the issue with Bintray, can I help with anything? Otherwise many
thanks, means everyone can already start using it.


Reply to this email directly or view it on GitHub
#62 (comment)
.

@gslowikowski

This comment has been minimized.

Show comment
Hide comment
@gslowikowski

gslowikowski Dec 9, 2015

Member

Update README.md file with latest sbt-scoverage and sbt-coveralls plugin versions.

Member

gslowikowski commented Dec 9, 2015

Update README.md file with latest sbt-scoverage and sbt-coveralls plugin versions.

@sksamuel

This comment has been minimized.

Show comment
Hide comment
@sksamuel

sksamuel Dec 10, 2015

Member

done

On 9 December 2015 at 21:20, Grzegorz Slowikowski notifications@github.com
wrote:

Update README.md file with latest sbt-scoverage and sbt-coveralls plugin
versions.


Reply to this email directly or view it on GitHub
#62 (comment)
.

Member

sksamuel commented Dec 10, 2015

done

On 9 December 2015 at 21:20, Grzegorz Slowikowski notifications@github.com
wrote:

Update README.md file with latest sbt-scoverage and sbt-coveralls plugin
versions.


Reply to this email directly or view it on GitHub
#62 (comment)
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment