Roadmap

Steven Christou edited this page Mar 10, 2016 · 24 revisions

These items will be released in future versions of Cobertura.

We would like to hear your opinion and ideas! To discuss this and other items, please check the issues list.

Cobertura (2.1.0)

Create Cobertura DSL

Introducing a DSL to perform tasks allows us to decouple Cobertura functionality from Ant. This way we also provide a direct interface to other tools, such as Maven plugins, providing greater flexibility and leading to cleaner implementations.

Example: currently Cobertura Maven plugin executes Cobertura invoking its Ant tasks, which recompile the code, rerun the tests and create the reports. Providing a DSL, the plugin could perform the instrumentation after a Maven compilation is performed, as well as create the reports after the tests were run. This means that compilations and tests would be run just once, shortening build time.

(Done: Jose Rozanec)

Default Coverage Annotation

In 2.0 we introduce annotations for cobertura to ignore instrumenting. By default we want to set at least one annotation (something like @CoberturaIgnoreInstrument), that way people will not need to specify the annotation argument. (In Progress: Steve Christou)

Add JDK 8 JUnit (lambda expression)

We should get a jump start on this as it is critical to migrate to the latest version. (This might require us changing our ASM version to 5.0 which is still in alpha stage).

Minor tests cleanup

The JUnit tests are kind of ugly and we should do some cleanup. Currently we have entire .java and .groovy files stored as strings and written to files. Instead of creating them, we should have those files in the test/resources folder and use them when needed. Code that is specific to certain environment should also be removed. Default tempDir "/tmp" should be changed to some "${project_home}/target/tmp", so that those files get removed on Mavens lifecycle. (In Progress: Steve Christou)

Ability to enable/disable code complexity calculator.

It would be nice to give people the option to add/remove the complexity calculator, that way on a report, they do not need to encounter any parsing exceptions that occur from javancss or javacc.

Future Releases (2.2.0+)

Memory improvement

Currently we store all the cobertura results as an int array and it keeps track of the number of lines executed. I believe if people do not care about how many times a line was executed and only care about if the code was executed, instead switching to a boolean array would be a lot cleaner and friendlier on memory and (possibly but highly unlikely) speed.

Quiet mode

Adding a -q tag would set cobertura to not output anything. It has been requested multiple times and I think that it is not a bad feature. This will be available for all targets (instrument, report, merge, etc.) In some locations we are doing System.println which should be changed to use loggers. I believe we need to write a custom logger and not use the log4j api to remove any dependencies in the log4j jar. Worst possible situation we could do System.setOut|Error to a random or null PrintStream, or redirect to a file.

Add github service hook

It would be cool to add a new github service hook for cobertura code coverage results. When viewing an individual file you can see the code coverage results for the latest build. Where there are the options Edit, Raw, Blame, History and Delete we could add a new Coverage button. This will allow for people of open source projects to view the coverage and see if certain areas of code are being executed or not. However this will require that the cobertura results be committed also. Thoughts or suggestions?

Update HTML Report

Currently the html reporting looks "old" and could use a revamp. If possible I would like to add either a java to html generator, or another method for generating the results.

Add badges to HTML/XML reports

Similar to how travis-ci has the badge that displays current build status, it would be nice to have a tiny coverage badge that displays the coverage of the overall code. (In progress: Steve Christou)

Add better support for JVM languages

Cobertura works on JVM bytecode. Currently there are several fast growing languages, as Scala. We would like to be able to produce accurate reports for other JVM languages, not just Java. Since all instrumentation data is stored in the ProjectData object, we can create some object containing data about coverage, complexity and source code. The creation of this kind of object should be of some strategy per JVM language, which would be able to interpret how do the .class files reported at ProjectData map to the corresponding source code.

This kind of object may be called GenericReport, since it holds all information about the project, and does not match a specific format. Strategies can be provided to translate its information into a specific format (ex.: html, xml, etc.). Some ideas for this were prototyped at this fork.

We may try providing support for Scala, which is a fast growing language.

Add JSON output

Cobertura reports coverage with HTML and XML, however not JSON format. It would be nice to have cobertura also report in JSON format.

Finished Items

Maven migration

Migrate project from Ant to Maven. (Done: Jose Rozanec and Steve Christou)

Github page fixup

Fix the github page to have a README.md file that looks nice. (Done: Jose Rozanec)

Make cleaner website

The website could use a more modern look-and-feel. (Done: Steve Christou)

Add JDK 6/5 JUnit

I want to make sure that cobertura does not break backward compatibility and works on JDK 6 and 5 if possible. (Done: Steve Christou)

Add Findbugs/PMD/CPD

These tools should help with removing potential bugs or bad code. (Done: Jose Rozanec)