always produce coverage reports for unit & integration tests #326
Conversation
|
Would it be simpler to do this change after #307? |
java-manta-client/pom.xml
Outdated
| @@ -234,31 +234,31 @@ | |||
| <relocations> | |||
| <relocation> | |||
| <pattern>com.joyent.http</pattern> | |||
| <shadedPattern>com.joyent.manta.http</shadedPattern> | |||
There was a problem hiding this comment.
What's the rational to change the shaded pattern? I'll admit the original package name was suboptimal.
If you want to change it, you will need to look for the code points where we detect if we are using a shaded artifact or not. If I recall correctly, this is being done in the kryo module and it may be done elsewhere. In those places, there is a string that refers to the shaded package name.
There was a problem hiding this comment.
It made it easier to exclude them later, since all of the shaded classes match a single pattern. I think it could work with shadedPattern untouched and a more complicated pattern to unpack later.
|
|
If you change the shading pattern, you will need to change this line: https://github.com/joyent/java-manta/blob/master/java-manta-client-kryo-serialization/src/main/java/com/joyent/manta/serialization/EncryptionStateSerializer.java#L110 |
cburroughs
force-pushed
the
inter-cov-diff
branch
from
597bcc8 to
d946c35
Compare
|
Kept the existing shaded paths, and adding corresponding exclusions. |
cburroughs
force-pushed
the
inter-cov-diff
branch
2 times, most recently
from
cbaa1ce to
40ee31b
Compare
Previously code coverage reports were only generated as part of the `site` goal, and were thus rarely looked at. Binding the reports to the same phase ensures they are always available for inspection. Due to shading, several hoops need to be jumped through so that the integration test report can refer to the source and classes under test. Actions are bound to several maven phases to move files around, acting as if java-manta-client was part of the integration test module. ref TritonDataCenter#317
|
This is rebased after the Great Unshading and is ready to look at again: Examples (internal): |
| <overWrite>true</overWrite> | ||
| <outputDirectory>${project.build.directory}/classes</outputDirectory> | ||
| <includes>**/*.class</includes> | ||
| <excludes>com/joyent/manta/com/**,com/joyent/manta/org/**,com/joyent/manta/io/**,com/joyent/manta/http/signature/**</excludes> |
There was a problem hiding this comment.
Just out of curiosity, under what circumstances would this <excludes> list change? They seem to be the relocation roots but I just want to be sure I know how to maintain this. I'm assuming coverage for library classes shows up if this isn't set?
There was a problem hiding this comment.
Yep, this is just working backwards from the relocation roots in java-manta-client/pom.xml. Additions there may also require changes here. At some point (4.0?) I think it would be worthwhile to have only a single package path for relocated (ex com.joyent.manta.shade) just to keep things a bit tidier.
There was a problem hiding this comment.
Agreed about the single package relocation. The question of "why isn't everything shaded to the same place?" has crossed my mind once before. I'll file an issue for this.
Previously code coverage reports were only generated as part of the
sitegoal, and were thus rarely looked at. Binding the reports tothe same phase ensures they are always available for inspection.
Due to shading, several hoops need to be jumped through so that the
integration test report can refer to the source and classes under test.
Actions are bound to several maven phases to move files around, acting
as if java-manta-client was part of the integration test module.
ref #317