Error during site generation #12

rigoford · 2014-12-01T11:27:57Z

Having updated the scoverage-samples project to use scoverage-maven-plugin version 1.0.0 according to the documentation in GitHub, i.e. in build:

<plugin>
  <groupId>org.scoverage</groupId>
  <artifactId>scoverage-maven-plugin</artifactId>
  <version>1.0.0</version>
  <configuration>
    <minimumCoverage>80</minimumCoverage>
    <failOnMinimumCoverage>false</failOnMinimumCoverage>
  </configuration>
  <executions>
    <execution>
      <goals>
        <goal>check</goal>
      </goals>
      <phase>test</phase>
    </execution>
  </executions>
</plugin>

and in reporting:

<plugin>
  <groupId>org.scoverage</groupId>
  <artifactId>scoverage-maven-plugin</artifactId>
  <version>1.0.0</version>
  <reportSets>
    <reportSet>
      <reports>
        <report>report-only</report>
      </reports>
    </reportSet>
  </reportSets>
</plugin>

Running "mvn clean install" works fine (scoverage-maven-plugin runs and reports level of coverage). However running "mvn site" straight after results in a failure:

"[ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project scoverage-samples: Error during site generation: $MY_PATH\scoverage\scoverage-samples\target\site\scoverage$MY_PATH\scoverage\scoverage-samples\src\main\scala\com\sksamuel\scoverage\samples\SimpleObject.scala.html (The filename, directory name, or volume label syntax is incorrect) -> [Help 1]"

A "target/site/scoverage/index.html" file is created but none of the links within that page work - "$MY_PATH/scoverage-samples/src/main/scala/com/sksamuel/scoverage/samples/Charmax.scala.html" does not exist.

Please advise. Thanks

gslowikowski · 2014-12-01T13:07:35Z

Hi

I need stacktrace. Run "mvn site -X" and attach log here, please.

BTW I see, you are testing with https://github.com/scoverage/scoverage-samples project. The "pom.xml" file in this sample is outdated and should be deleted. There are more samples in https://github.com/scoverage/scoverage-maven-samples so there is no need to update this one.

rigoford · 2014-12-01T13:52:57Z

Hi,

I've cloned scoverage-maven-samples and in the simple/scala-plugin-scala-2.11 project, running "mvn clean scoverage:report -X" gives me a final output (stacktrace) of:

[ERROR] $MY_PATH\scoverage\scoverage-maven-samples\simple\scala-plugin-scala-2.11\target\site\scoverage\$MY_PATH\scoverage\scoverage-maven-samples\simpl
e\scala-plugin-scala-2.11\src\main\scala\HelloServiceScala.scala.html (The filename, directory name, or volume label syntax is incorrect)
java.io.FileNotFoundException: $MY_PATH\scoverage\scoverage-maven-samples\simple\scala-plugin-scala-2.11\target\site\scoverage\$MY_PATH\scoverage\scover
age-maven-samples\simple\scala-plugin-scala-2.11\src\main\scala\HelloServiceScala.scala.html (The filename, directory name, or volume label syntax is incorrect)
        at java.io.FileOutputStream.open(Native Method)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:221)
        at java.io.FileOutputStream.<init>(FileOutputStream.java:171)
        at java.io.FileWriter.<init>(FileWriter.java:90)
        at scoverage.IOUtils$.writeToFile(IOUtils.scala:39)
        at scoverage.report.ScoverageHtmlWriter.scoverage$report$ScoverageHtmlWriter$$writeFile(ScoverageHtmlWriter.scala:42)
        at scoverage.report.ScoverageHtmlWriter$$anonfun$scoverage$report$ScoverageHtmlWriter$$writePackage$1.apply(ScoverageHtmlWriter.scala:35)
        at scoverage.report.ScoverageHtmlWriter$$anonfun$scoverage$report$ScoverageHtmlWriter$$writePackage$1.apply(ScoverageHtmlWriter.scala:35)
        at scala.collection.immutable.List.foreach(List.scala:318)
        at scoverage.report.ScoverageHtmlWriter.scoverage$report$ScoverageHtmlWriter$$writePackage(ScoverageHtmlWriter.scala:35)
        at scoverage.report.ScoverageHtmlWriter$$anonfun$write$1.apply(ScoverageHtmlWriter.scala:23)
        at scoverage.report.ScoverageHtmlWriter$$anonfun$write$1.apply(ScoverageHtmlWriter.scala:23)
        at scala.collection.immutable.List.foreach(List.scala:318)
        at scoverage.report.ScoverageHtmlWriter.write(ScoverageHtmlWriter.scala:23)
        at org.scoverage.plugin.SCoverageReportMojo.generate(SCoverageReportMojo.java:206)
        at org.scoverage.plugin.SCoverageReportMojo.execute(SCoverageReportMojo.java:314)
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
        at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
        at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
        at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
        at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
[ERROR]

It looks like there's an absolute path being used when it should be relative.

Thanks

gslowikowski · 2014-12-01T14:09:42Z

This example works for me and I use Windows too. Something is wrong inside scalac-scoverage-plugin.

You can try this option http://scoverage.github.io/scoverage-maven-plugin/1.0.0/pre-compile-mojo.html#scalacPluginVersion. Set the value to 1.0.1 to use latest https://github.com/scoverage/scalac-scoverage-plugin. Maybe it's already fixed.

gslowikowski · 2014-12-01T15:33:23Z

Where is $MY_PATH from?

rigoford · 2014-12-01T16:16:29Z

Just my attempt to obfuscate the real path - take it as being c:\

rigoford · 2014-12-01T16:32:28Z

The difference seems to be that I'm using Git Bash. If I use a Windows command prompt, "mvn scoverage:report" run in scoverage-maven-samples/simple/scala-plugin-scala-2.11 is successful. Unfortunately, the majority of our developers use Git Bash...

I assume we're unlikely to see this issue as part of a Jenkins build when publishing a maven site.

rigoford · 2014-12-01T16:47:24Z

Interestingly, when running scoverage:report (Windows command) against the scoverage-maven-samples/simple/scala-plugin-scala-2.11 module, the various html report files are created but the service.html contains broken links, the URLs are of the form <a href="(empty)/HelloServiceScala.scala.html">.

I've yet to get the report goal to work against the old scoverage-samples module, but I assume it should.

gslowikowski · 2014-12-01T17:02:25Z

This is because source location does not reflect package names. I did it intentionally to expose this problem and forgot about it :( I've just tried with -Dscoverage.scalacPluginVersion=1.0.1 and it didn't help. It means the bug in scalac-scoverage-plugin is still there.

rigoford · 2014-12-01T17:08:28Z

Ah. Fair enough. Do you want that raised as a separate issue for tracking?

Any thoughts about the Git Bash vs Windows Command prompt, is the issue going to be the way the file serarator is determined?

gslowikowski · 2014-12-01T17:39:17Z

I will consult the first issue with scalac plugin author. I never used Git Bash, will learn it.

gslowikowski · 2014-12-04T21:27:23Z

I've just tried git bash and it works for me, but I've seen similar path problem when implementing aggregated report today. I suspect it can appear when accessing scoverage files from outside of the project/module, but I tried to execute regular report from outside of the project (scala-plugin-scala-2.11) and it worked. Anyway, I will investigate.

rigoford · 2014-12-11T15:36:20Z

I've discovered part of the problem, the build section of my pom was missing a sourceDirectory element. Adding this means "mvn clean install site" completes successfully when run from the Windows command prompt.

Debugging scoverage-maven-plugin and scalac-scoverage-plugin I can see the issue when building in git bash. Basically value of the sourceDir and outputDirectory directories evaluated by scoverage-maven-plugin starts with "c:/..." (note lower case 'c'), where as in scalac-scoverage-plugin the source path of the Scala files that have been 'measured' starts with "C:/..." (note upper case 'C'). Therefore the String.replace call in the relativeSource function of ScoverageHtmlWriter does not correctly match (and replace) the absolute path.

gslowikowski · 2014-12-11T22:12:56Z

Thank you for your work.

I'm surprised because I see "G:" in Maven invocation log with "-X" option, in target/scoverage.xml file and target/scoverage-data/*.xml files. I didn't debug now. Do you see slashes in the above places or only in the debugger?

I will try to help anyway, I see two potential problems:

In scala-maven-plugin. I've tested on scoverage-maven-samples/simple/scala-plugin-scala-2.11 (mvn clean scoverage:report -X call) and I found two interesting things in the log:
in net.alchim31.maven:scala-maven-plugin:3.2.0:compile mojo configuration:

<sourceDir>${project.build.sourceDirectory}/../scala</sourceDir>

I forgot about this strange default value (http://davidb.github.io/scala-maven-plugin/compile-mojo.html#sourceDir), didn't like it since I saw it for the first time
and

<useCanonicalPath default-value="true">${maven.scala.useCanonicalPath}</useCanonicalPath>

(http://davidb.github.io/scala-maven-plugin/compile-mojo.html#useCanonicalPath)
These two settings together may be responsible for producing different path after File.getCanonicalPath() invocation.
This problem should not exist in projects using sbt-compiler-maven-plugin. Can you check two things:
does setting <useCanonicalPath>false</useCanonicalPath> helps
does the same problem exists in projects using sbt-compiler-maven-plugin?

In scalac-scoverage-plugin. I would like to know what the beginnings of your paths look like in Maven log with -X option, target/scoverage.xml file and target/scoverage-data/*.xml files.

gslowikowski · 2014-12-12T14:57:13Z

I've debugged today, with and without Git Bash (I use msysgit 1.7.3.1, gitbash.exe). All my paths start with "G:" (I work on "G" drive). Always capital "G" and backslash, never slash. I wonder what differences are between our environments, why you have slash in your paths.

rigoford · 2014-12-15T10:13:59Z

So the issue appears to come from the "relativeSource" function in scoverage.report.ScoverageHtmlWriter, or more correctly the path values of the Statements in the coverage object (in "scoverage.coverage.xml", which are of the form "C:\scoverage\scoverage-maven-samples\simple\scala-plugin-scala-2.11\src\main\scala\HelloServiceScala.scala") and the path value of the sourceDirectory variable (which is of the form "c:\scoverage\scoverage-maven-samples\simple\scala-plugin-scala-2.11\src\main\scala"). Notice the upper case "C" vs lowecase "c". The string replace call in "relativeSource" is then unable to replace "C:\scoverage\scoverage-maven-samples\simple\scala-plugin-scala-2.11\src\main\scala" with "".

So the question is, for me, why does the scala-scoverage-plugin use an upper case drive letter while the scoverage-maven-plugin uses a lower case driver letter when run in git bash (but not when run in Windows command prompt).

nodejs/node-v0.x-archive#7880 talks about git bash normalising the drive letter to lower case. I'll investigate that.

gslowikowski · 2014-12-15T10:49:41Z

Please answer my questions from previous comment. Additionally, do you have "C:" and "c:" or "C:/" and "c:/" because there were slashes in you previous comment and there are backslashes. We must be very precise if we want to find a solution to this strange issue.

gslowikowski · 2014-12-15T10:51:56Z

SCoverage has nothing to do with Node, I don't see a word about bash in the issue you cited.

gslowikowski · 2014-12-15T11:16:00Z

I don't like this relativeSource function at all. There are too many limitations with current implementation of source directory processing, for example: you cannot have multiple sources (it's natural in both Maven and SBT).

rigoford · 2014-12-15T11:54:08Z

My paths start with "c:" and "C:" (note backslash). Running "mvn scoverage:report -X" I see a mixture of "c:" and "C:" being used.

I was more interested in whether my git bash was normalising my drive letter to lower case rather than Node.

gslowikowski · 2014-12-15T13:54:50Z

Where you see lower- and where uppercase "c"?

rigoford · 2014-12-15T15:19:44Z

The classpath contains a mixture of "C:" and "c:" while the configuration for the scoverage-maven-plugin is all lowercase, e.g.:

[INFO] --- scoverage-maven-plugin:1.0.0:report (default-cli) @ scoverage-samples ---
[DEBUG] Configuring mojo org.scoverage:scoverage-maven-plugin:1.0.0:report from plugin realm ClassRealm[plugin>org.scoverage:scoverage-maven-plugin:1.0.0, parent: sun.misc.Launcher$AppClassLoader@3f677737]
[DEBUG] Configuring mojo 'org.scoverage:scoverage-maven-plugin:1.0.0:report' with basic configurator -->
DEBUG dataDirectory = c:\Dev-workspaces\Misc\scoverage\scoverage-samples\target\scoverage-data
DEBUG destDir = scoverage
DEBUG failOnError = true
DEBUG outputDirectory = c:\Dev-workspaces\Misc\scoverage\scoverage-samples\target\site\scoverage
DEBUG project = MavenProject: org.scoverage:scoverage-samples:0.99.2 @ c:\Dev-workspaces\Misc\scoverage\scoverage-samples\pom.xml
DEBUG skip = false
DEBUG xmlOutputDirectory = c:\Dev-workspaces\Misc\scoverage\scoverage-samples\target
[DEBUG] -- end configuration --

The paths of files listed in the "target\scoverage.xml" and "target\scoverage-data\scoverage.coverage.xml" files all begin "C:".

rigoford · 2014-12-15T15:47:25Z

In scala-scoverage-plugin, there appears to be an inconsistent use of "canonicalPath" (in Location.scala) and "getAbsolutePath" (in ScoverageHtmlWriter.scala), according to the JavaDoc for java.io.File, "getCanonicalPath" with convert the drive letter to a standard case (for me upper case) while "getAbsolutePath" does not.

gslowikowski · 2014-12-15T16:03:42Z

I'm glad that you found it. I have uppercase "C" everywhere whatever I try. Will you create issue for https://github.com/scoverage/scalac-scoverage-plugin/ or should I do it?

gslowikowski · 2014-12-15T16:08:35Z

Probably consistent usage of canonicalPath would solve the problem.

rigoford · 2014-12-15T16:15:51Z

I can do it. In fact I'll fix it and send a pull request. Thanks for your help and patience.

rigoford · 2014-12-16T13:05:17Z

Pull request sent (scoverage/scalac-scoverage-plugin#75)

gslowikowski · 2014-12-22T10:29:08Z

Version 1.0.2 released. It depends on scalac-scoverage-plugin 1.0.2, containing your fix.

Thank you for cooperation.

rigoford closed this as completed Dec 16, 2014

gslowikowski added this to the 1.0.2 milestone Jan 9, 2015

Error during site generation #12

Error during site generation #12

Comments

rigoford commented Dec 1, 2014

gslowikowski commented Dec 1, 2014

Uh oh!

rigoford commented Dec 1, 2014

Uh oh!

gslowikowski commented Dec 1, 2014

Uh oh!

gslowikowski commented Dec 1, 2014

Uh oh!

rigoford commented Dec 1, 2014

Uh oh!

rigoford commented Dec 1, 2014

Uh oh!

rigoford commented Dec 1, 2014

Uh oh!

gslowikowski commented Dec 1, 2014

Uh oh!

rigoford commented Dec 1, 2014

Uh oh!

gslowikowski commented Dec 1, 2014

Uh oh!

gslowikowski commented Dec 4, 2014

Uh oh!

rigoford commented Dec 11, 2014

Uh oh!

gslowikowski commented Dec 11, 2014

Uh oh!

gslowikowski commented Dec 12, 2014

Uh oh!

rigoford commented Dec 15, 2014

Uh oh!

gslowikowski commented Dec 15, 2014

Uh oh!

gslowikowski commented Dec 15, 2014

Uh oh!

gslowikowski commented Dec 15, 2014

Uh oh!

rigoford commented Dec 15, 2014

Uh oh!

gslowikowski commented Dec 15, 2014

Uh oh!

rigoford commented Dec 15, 2014

Uh oh!

rigoford commented Dec 15, 2014

Uh oh!

gslowikowski commented Dec 15, 2014

Uh oh!

gslowikowski commented Dec 15, 2014

Uh oh!

rigoford commented Dec 15, 2014

Uh oh!

rigoford commented Dec 16, 2014

Uh oh!

gslowikowski commented Dec 22, 2014

Uh oh!