Source directories must not be nested

[martinhrvn]

Hi,
I'm trying a very simple build with coveralls, but it fails with this error:
ava.lang.IllegalArgumentException: requirement failed: Source directories must not be nested

It's a single module buils and contains one src/main/scala directory

build.sbt only contains:

lazy val sprayVersion = "1.3.2"
organization := "com.example"
version := "0.1.0"
scalaVersion := "2.11.5"
name := "coveralls-test"
libraryDependencies ++= Seq(
"commons-codec" % "commons-codec" % "1.10",
"io.spray" %% "spray-json" % sprayVersion,
"io.spray" %% "spray-client" % sprayVersion,
"com.typesafe.scala-logging" %% "scala-logging" % "3.1.0",
"ch.qos.logback" % "logback-classic" % "1.1.3",
"ch.qos.logback" % "logback-core" % "1.1.3",
"com.typesafe.akka" %% "akka-actor" % "2.3.14",
"org.scalatest" %% "scalatest" % "2.2.4" % Test,
"junit" % "junit" % "4.12" % Test,
"org.pegdown" % "pegdown" % "1.1.0" % Test)

Any ideas?

[earldouglas]

I just ran into this as well. It looks like isChild will detect any given directory as a child of itself. Consider using sbt.IO.relativize instead.

[reid-spencer]

This is biting me too. Looks like I'm headed for a downgrade of sbt-scoverage and sbt-coveralls plugins as well. 👎

[AndrewWhitaker]

What's odd is that there's a test case that explicitly checks to make sure that the result of calling isChild with identical child and parent is true. Is this by design? The fix is easy enough, like @earldouglas pointed out.

[earldouglas]

Is this by design?

It does appear to be by design, however only the one test case appears to rely on it.

This could be addressed simply by changing isChild to:

def isChild(child: File, parent: File): Boolean =
  sbt.IO.relativize(parent, child).isDefined

and changing that test case to expect false.

[jackewitz]

I just ran into this as well with:

• sbt-scoverage 1.3.3
• sbt-coveralls 1.0.3

Which versions should I use to get your bugfix? Have you released a stable version of sbt-coveralls (or combination of sbt-scoverage and sbt-coveralls) already?

[zzztimbo]

I'm using the same versions as @jackewitz and having the same issues.

[zzztimbo]

@jackewitz this pull request answers your questions about which versions to use:

https://github.com/alexandru/shade/pull/21/files

[zzztimbo]

Has anyone run into this issue after downgrading? #56

[ozoli]

@zzztimbo I had no issues using the versions shown in the pull request ie.

addSbtPlugin("org.scoverage" % "sbt-scoverage" % "1.0.1")
addSbtPlugin("org.scoverage" % "sbt-coveralls" % "1.0.0")

[jackewitz]

I had no issues using the versions shown at @ozoli comment. Great. :-)

[jeffmay]

I just encountered this with sbt-scoverage 1.3.5 and sbt-coveralls 1.0.3 as well.
My fix was to downgrade to sbt-scoverage 1.0.1 and sbt-coveralls 1.0.0 as recommended as well.

[ruippeixotog]

Despite being closed, this issue still affects many users as there's no published version of the two plugins since then. I'll have to downgrade them in my project too, but downgrading from sbt-scoverage 1.3.5 to 1.0.3 seems a big jump... @sksamuel, is there any idea of when might you release a new version?

[sksamuel]

I've put coveralls 1.1.0 onto maven central (note: not bintray)

[ruippeixotog]

@sksamuel thank you for your quick action, I was able to make it work now with sbt-scoverage 1.3.5 and sbt-coveralls 1.1.0!

However, I had to run coverageReport between the test and coverall tasks. Otherwise, I get a java.io.FileNotFoundException on coveralls, saying that it didn't found coverage-report/cobertura.xml. Is running coverageReport now required? If so, can you update the README so that it includes this?

Thank you once more!