eclemma icon indicating copy to clipboard operation
eclemma copied to clipboard

Moving some class from internal to public API

Open barabeladavid opened this issue 10 years ago • 6 comments

We use some class from the internal API for code analyzation,

  • org.jacoco.core.internal.analysis.BundleCoverageImpl
  • org.jacoco.core.internal.analysis.SourceFileCoverageImpl

Is it possible to move org.jacoco.core.internal.analysis to the public API?

barabeladavid avatar Dec 03 '15 07:12 barabeladavid

Seems to be an https://github.com/jacoco/jacoco issue.

Anyhow: Both types are supposed to be instantiated internally by the BundleBuilder and Analyzer respectively only. Can you please elaborate about your use case why instances should be created by API users?

marchof avatar Dec 07 '15 05:12 marchof

The base use case is using a custom Coverage Builder, which ignores duplicate class file names even if their are different.

barabeladavid avatar Dec 07 '15 14:12 barabeladavid

Any thoughts regarding our request?

barabeladavid avatar Jan 11 '16 14:01 barabeladavid

The class SourceFileCoverageImpl extends SourceNodeImpl. Not sure whether this needs to be exposed too for a consistent type hierarchy. But SourceNodeImpl again exposes internal classes on its APIs.

Maybe an alternative aproach would be to provide public factory methods.

marchof avatar Jan 11 '16 16:01 marchof

Another option would be to implement a method

protected IClassFileCoverage merge(IClassFileCoverage c1, IClassFileCoverage c2);

in CoverageBuilder which throws an exception by default. So you can implement your own behavior.

What would be the merge strategy you're thinking of? Maybe we can adopt this for JaCoCo.

marchof avatar Jan 11 '16 16:01 marchof

Public factory methods could work with BundleCoverageImpl and SourceFileCoverageImpl. The second approach in our case is not the best, cause we use a custom CoverageBuilder, which is able to manage multiple package matching.

barabeladavid avatar Jan 13 '16 12:01 barabeladavid