-
Notifications
You must be signed in to change notification settings - Fork 50
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
Using coveralls in cross-project #104
Comments
I have the same problem |
The reason behind it is most likely that Here is full stack trace that I am getting:
And here is the fix: #113 |
@gslowikowski / @GRBurst this would hopefully sort out this issue @gslowikowski one thing to keep in mind that this solution used Java 7 feature which may be problematic due to this comment in (though I'd argue that if we are to handle Java 6 we should have a |
Hey @fommil git blame shows you as the author of this line: https://github.com/scoverage/sbt-coveralls/blob/master/build.sbt#L26 Is there any reason we should keep compatibility with Java version that is not even covered with official support anymore? I guess one of the typical reasons in the past - Android - is at the point where Java 7+ versions are already supported out of the box. |
I don't use this anymore |
Guys, can you confirm that the problem exists when I see, that the conversion to paths ( If both: But if only The solution would be to filter non-existent source roots. Can you check your failing builds? |
Hey @gslowikowski you are right - removing this directory obviously helps. But I don't think that filtering out non-existent paths is the right solution. IMHO the problem is in incorrectly recognizing nested directories and I have submitted fix for that here: #113 It sorts out this problem altogether. |
@pdolega I remember about your PR, but it's always better to fix the real source of the problem. The algorithm of recognizing nested directories works properly for existing directories. After changing val allSources = (sources ++ multiSources).filter(_.isDirectory()).distinct problem is solved. Additionally, I think we need scripted test here. It should be added now or later. When I was executing your unit tests, I had to check on a real project, what paths are passed by SBT - relative, absolute, or maybe canonical? BTW, I didn't verify plugin behavior on projects with non-canonical paths (e.g. something like |
Ah! I misread you comment. Apologies. I read this part incorrectly:
Let me check it out - it might be that you are absolutely right with diagnosis of the problem (and you are definitely right as for the scripted test) |
@gslowikowski you were right indeed. Change in
Above Good point! PS. I have update PR with your suggested change, now I need to add scripted test for this scenario. |
Fixed by #113 |
Version Add resolvers += Resolver.sonatypeRepo("snapshots") to project's settings to test it. |
Version |
Latest version works perfectly for our Cross-Project builds. Thanks a lot to everyone involved for fixing it!!! |
Hey,
I am having troubles to use
sbt coveralls
with a cross-project. Since the coverage reports are not available for scalajs (as far as I know), I want to test the coverage of theJVM
part only.Currently I am doing the following with
sbt 1.0.4
:This results in the following exception:
This is strange, because the shown path does not exist and
graph
is a pure cross-project, which means that I only have a sharedsrc
folder, e.g.graph/shared/src/
and notgraph/jvm/src
. Heregraph/jvm
only contains atarget
folder.However, if I call
sbt coveralls
on a pure scala sbt sub-project, it succeeds.This indicates that there is an issue with the coverage of the JVM part of cross projects.
How can I get it to work?
Thanks for your help in advance!
Kind regards :-)
The text was updated successfully, but these errors were encountered: