Skip to content
This repository has been archived by the owner on Oct 1, 2020. It is now read-only.

Moving some class from internal to public API #111

Open
barabeladavid opened this issue Dec 3, 2015 · 6 comments
Open

Moving some class from internal to public API #111

barabeladavid opened this issue Dec 3, 2015 · 6 comments

Comments

@barabeladavid
Copy link

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?

@marchof marchof added the jacoco label Dec 7, 2015
@marchof
Copy link
Member

marchof commented Dec 7, 2015

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?

@barabeladavid
Copy link
Author

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

@barabeladavid
Copy link
Author

Any thoughts regarding our request?

@marchof
Copy link
Member

marchof commented Jan 11, 2016

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
Copy link
Member

marchof commented Jan 11, 2016

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.

@barabeladavid
Copy link
Author

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants