[
https://issues.apache.org/jira/browse/BEAM-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15871282#comment-15871282
]
Daniel Halperin commented on BEAM-1399:
---------------------------------------
Wow, you did a whole bunch of good research here, [~staslev]! Thanks!
I have a very shallow reaction to your #1 -- is this so bad? We essentially
already have this for Javadoc:
https://github.com/apache/beam/blob/master/sdks/java/javadoc/pom.xml
Maybe we change that module from being "javadoc" to being "reporting", and
integrate code coverage with `report:aggregate` there as well. As for whether
this is well supported by Beam... I actually think it would not be so bad,
because we look at code coverage on pull requests (or we would if it were
accurate). So it would be easy to tell when a new module was missing from
`reporting`. In fact -- we'd get a better forcing function to update Javadoc as
well!
Thoughts?
> Code coverage numbers are not accurate
> --------------------------------------
>
> Key: BEAM-1399
> URL: https://issues.apache.org/jira/browse/BEAM-1399
> Project: Beam
> Issue Type: Bug
> Components: build-system, sdk-java-core, testing
> Reporter: Daniel Halperin
> Labels: newbie, starter
>
> We've started adding Java Code Coverage numbers to PRs using the jacoco
> plugin. However, we are getting very low coverage reported for things like
> the Java SDK core.
> My belief is that this is happening because we test the bulk of the SDK not
> in the SDK module , but in fact in the DirectRunner and other similar modules.
> JaCoCo has a {{report:aggregate}} target that might do the trick, but with a
> few minutes of playing with it I wasn't able to make it work satisfactorily.
> Basic work in https://github.com/apache/beam/pull/1800
> This is a good "random improvement" issue for anyone to pick up.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
