converting source path from absolute to relative #275
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
stuhood
approved these changes
Jul 31, 2019
| // instead of the canonical path. This is required to make it work with | ||
| // remoting or in a distributed environment. | ||
| def getRelativePath(filePath: String): String = { | ||
| val base = new File(".").getCanonicalPath + File.separator |
There was a problem hiding this comment.
This operation is relativize: https://docs.oracle.com/javase/tutorial/essential/io/pathOps.html#relativize
This was referenced Jul 31, 2019
|
Hi guys You assumed that current working directory is project's root directory. This is not always true. For example in Maven you can specify |
|
@gslowikowski |
illicitonion
pushed a commit
to pantsbuild/pants
that referenced
this pull request
Mar 6, 2020
Co-authored-by: Ny Saechao <[email protected]> The problem is also referenced here : scoverage/scalac-scoverage-plugin#275 ### Problem Currently, at compile time, scoverage stores (as a string) the conical sourcePath (path for the source file) for a statement inside the instrument file `scoverage.coverage`. This string is then again required during report generation to get the source file in `ScoverageHtmlWriter` . This breaks in a distributed environment where report generation is happening on a different machine and is unable to locate the source file due to the absolute path. ### Solution The current fix makes the path relative when storing and turns it back to a conical one (w.r.t cwd) on retrieving. For now, the fix is merged in twitter forked version of scoverage (version 1.0.2-twitter). ### Result Scoverage can now work in a distributed environment.
wisechengyi
pushed a commit
to pantsbuild/pants
that referenced
this pull request
Mar 6, 2020
Co-authored-by: Ny Saechao <[email protected]> The problem is also referenced here : scoverage/scalac-scoverage-plugin#275 ### Problem Currently, at compile time, scoverage stores (as a string) the conical sourcePath (path for the source file) for a statement inside the instrument file `scoverage.coverage`. This string is then again required during report generation to get the source file in `ScoverageHtmlWriter` . This breaks in a distributed environment where report generation is happening on a different machine and is unable to locate the source file due to the absolute path. ### Solution The current fix makes the path relative when storing and turns it back to a conical one (w.r.t cwd) on retrieving. For now, the fix is merged in twitter forked version of scoverage (version 1.0.2-twitter). ### Result Scoverage can now work in a distributed environment.
wisechengyi
pushed a commit
to pantsbuild/pants
that referenced
this pull request
May 4, 2020
Co-authored-by: Ny Saechao <[email protected]> The problem is also referenced here : scoverage/scalac-scoverage-plugin#275 ### Problem Currently, at compile time, scoverage stores (as a string) the conical sourcePath (path for the source file) for a statement inside the instrument file `scoverage.coverage`. This string is then again required during report generation to get the source file in `ScoverageHtmlWriter` . This breaks in a distributed environment where report generation is happening on a different machine and is unable to locate the source file due to the absolute path. ### Solution The current fix makes the path relative when storing and turns it back to a conical one (w.r.t cwd) on retrieving. For now, the fix is merged in twitter forked version of scoverage (version 1.0.2-twitter). ### Result Scoverage can now work in a distributed environment.
|
Still needed? |
|
I'm going to go ahead and close this in favor of #385, which will be merged into the V2 branch. The idea is exactly the same, but we avoid the issue raised here about assuming the source directory being |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Necessary for #265 :
Currently, at compile time, scoverage stores (as a string) the conical sourcePath (path for the source file) for a statement inside the instrument file
scoverage.coverage. This string is then again required during report generation to get the source file inScoverageHtmlWriter. This breaks in a distributed environment where report generation is happening on a different machine and is unable to locate the source file due to the absolute path.The current fix makes the path relative when storing and turns it back to a conical one (w.r.t cwd) on retrieving. Thanks