Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simple Command Line Interface for JaCoCo #525

Merged
merged 34 commits into from
May 24, 2017
Merged

Simple Command Line Interface for JaCoCo #525

merged 34 commits into from
May 24, 2017

Conversation

marchof
Copy link
Member

@marchof marchof commented Apr 28, 2017

A feature often asked for is a command line interface for JaCoCo. We have a pull request (#86) since quite some time, unfortunately without any tests and documentation. This is a new approach based on some ideas of #86.

To clearly manage expectations: The scope is about simple use cases only! For complex scenarios we have plugins to all common build systems.

Open Issues

  • Clarify and test usage of multi value options (e.g. -classfiles)
  • Improve documentation layout (long usage lines)
  • Test class XmlDocumenation or remove from test scope
  • Clarify class file version issue in build with exec-maven-plugin:1.6.0
  • Clarify why build result gets too big when compiled with Java 9

@marchof
Copy link
Member Author

marchof commented Apr 28, 2017

@mathjeff Can you please take a look and check whether your scenario is covered by this new PR? What is missing?

@marchof marchof self-assigned this Apr 28, 2017
@marchof marchof added this to the 0.7.10 milestone Apr 28, 2017
Copy link

@mathjeff mathjeff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey thanks. This looks to me like most of what Android is looking for.

I think the main thing left to do before Android is able to use this is for classname filtering to be supported in the 'instrument' and 'report' goals similarly to what the Maven plugin does. The main reason that this would be good for Android is that it enables filtering out dependencies in a manner that's approximately api-compatible with EMMA, rather than having to move or copy all of the relevant class files into a separate directory.

The usage I imagine would be as in mathjeff@0e0c5ec#diff-eec9564b9926238a12deea932c4d57f6 with "-include" and "-exclude" options that filter on fully qualified classname.

Although it sounds just as reasonable to me for filtering to be part of a separate pull request.

Thanks!

}

@Test
public void shouldCreateCsvReport_whenXmlOptionIsProvided()
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Xml" -> "Csv"

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mathjeff Fixed.

*/
public class Instrument extends Command {

@Option(name = "-destdir", usage = "directory to write instrumented Java classes to", metaVar = "<dir>", required = true)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we remove the 'dir' from '-destdir', possibly calling it '-destpath', to clarify the case where the input files is a .jar file and the value of '-destdir' is a .jar file?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mathjeff Correct, -dest is the way to go.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mathjeff Fixed.

command.printHelp(out);
return 0;
} else {
return command.execute(out, err);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll want to flush out and err somewhere, probably here; I was surprised that "[INFO] %s classes instrumented to %s.%n" wasn't getting displayed when I tested this. Of course, it's more convenient for Android if the output is empty, although I'm thinking that either we'll add a '-quiet' option to Jacoco or we'll redirect the output within Android.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mathjeff Not sure what the problem here is: in Main.main() the PrintWriters are created with auto-flushing after every line. How do you reproduce this?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I was surprised too. The simplest example I have is to ask jacoco to instrument itself:

/workspace/jacoco/org.jacoco.cli (work)$ java -jar target/org.jacoco.cli-0.7.10-SNAPSHOT-nodeps.jar instrument target/org.jacoco.cli-0.7.10-SNAPSHOT.jar -destdir /tmp/dummy.jar

, which doesn't give any output when I run it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marchof actually as far as I can see currently main does new PrintWriter(System.out) and JavaDoc says :

Creates a new PrintWriter, without automatic line flushing

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mathjeff @Godin May bad -- missread JavaDoc. Fixed ✅

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mathjeff -quiet option is now in place.

<artifactId>*</artifactId>
</exclusion>
</exclusions>
-->
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this intentional?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mathjeff I tried to directly test the "shaded" version. Unfortunatelly this does not work within the m2e IDE. Should be be removed of course.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mathjeff Fixed.

@marchof
Copy link
Member Author

marchof commented May 2, 2017

@mathjeff Hi, thanks for the detailled review! I will adress the issues you observed.

Regarding filtering: I would prefer to handle this in a separate PR as it should then be consistently implemented for the other integrations. Also the core API should be improved for this.

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.6.0</version>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marchof so far our lower bound of Maven version for build of project - is 3.0, which in his turn has Java 5 as lower bound, while exec-maven-plugin version 1.6.0 requires Java 7. This explains failure in Travis where we use JDK 6 to run Maven.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Godin Ok, thanks for the Info! We can execute the documentation as part of the test. Or is that too much of a hack?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marchof why not simply use 1.5.0 version of exec-maven-plugin that requires Java 5?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Godin ✅ Done.

@@ -68,6 +68,12 @@
<td>Ant <i>(all other dependencies included)</i></td>
</tr>
<tr>
<td><span class="el_jar">jacococli.jar</span></td>
<td>no</td>
<td>JaCoCo Ant tasks</td>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marchof copy-paste detected 😉

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Godin Thanks, fixed!

@@ -0,0 +1,2 @@
/target
/bin
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marchof I don't think this is needed - we have consolidated .gitignore

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Godin Thanks, fixed! (started this branch before we consolidates .gitignore)

@marchof
Copy link
Member Author

marchof commented May 8, 2017

Resulting jacoco-xxx.zip files for different build:

ZIP size master cli
Java 5 3,035,510 3,523,558
Java 9 3,462,577 3,956,019

Looks like we have constant overheads which sums up.

master -> cli: 475 KB

This is primarly due to a new all-in JAR and bigger coverage and test report.

Java 5 -> Java 9: 417 KB

The reason here is that the JavaDoc grows from 2,8MB to 4,1MB, probably as JavaDoc created with Java 9 comes with new features and bundles JQuery.

For Java 9 and cli both effects add-up beyond our current check limit.

As this is a pure sanity check I think we can safely lift the upper limit a bit.

@marchof
Copy link
Member Author

marchof commented May 9, 2017

@Godin @mathjeff From my point of view this feature is ready to merge. If you find some time please double check and approve the review if you agree. Thx!

@mathjeff
Copy link

mathjeff commented May 9, 2017

Hey thanks marchof@ for spending the time on this. Based on reading the code and trying out the resultant jar, this looks good to me. I'll leave the final approval/disapproval up to Godin@.

Android won't be able to directly use this yet until filtering by classname is implemented in a subsequent pull request, but this pull request looks consistent and reasonable to me.

Thanks!

@marchof
Copy link
Member Author

marchof commented May 9, 2017

@mathjeff Thanks for your feedback!

@marchof
Copy link
Member Author

marchof commented May 22, 2017

@Godin Thanks for taking the time to perform such a detailed review! You identified quite a few relevant issues. I hope for every review remark I either fixed the issue or left a comment when I was unsure how to proceed with it.

For me the remaining main issue is how the multi value arguments execfiles and classfiles should behave when no value is provided at all. There are several options:

  • Fail (make them mandatory). This may exclude some use cases for the commands.
  • Print warning (might be suppressed with --quiet
  • Consider this as valid usage (status quo)

execute("report", "--classfiles", getClassPath());

assertOk();
assertContains("[INFO] Writing report with 14 classes.", out);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marchof as discussed in #525 (comment) - Analyzing 14 classes. sounds better

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Godin Done in baaf539

<td><a href="agent.html">JaCoCo Manual</a></td>
<td></td>
<td><a href="agent.html">JaCoCo Java agent</a>, <a href="cli.html">JaCoCo Command Line Interface</a></td>
<td>Since version 0.8.0</td>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marchof given that version is only about CLI, I think will be better to have separate entries for Agent and CLI

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Godin Fixed in 8cd9627

@Godin
Copy link
Member

Godin commented May 23, 2017

@marchof Re multi value arguments: the use case that you described in #525 (comment) doesn't work as is for me:

$ bash
$ java -jar jacococli.jar merge -destfile /tmp/jacoco.exec testclients/*.exec
[INFO] Loading execution data file /private/tmp/j/testclients/*.exec.
Exception in thread "main" java.io.FileNotFoundException: testclients/*.exec (No such file or directory)

$ exit

$ zsh
$ java -jar jacococli.jar merge --destfile /tmp/jacoco.exec testclients/*.exec
zsh: no matches found: testclients/*.exec

$ exit

And I personally was puzzled multiple times by empty output in console after forgetting to provide an argument:

$ java -jar jacococli.jar classinfo
$ java -jar jacococli.jar execinfo

And by an empty report after forgetting to provide exec files:

java -jar jacococli.jar report --classfiles jacococli.jar --html report

Hence warned that potentially this might become a source of common mistakes.
An empty report after merge also might become a source of common mistakes:

java -jar jacococli.jar merge --destfile merged.exec
java -jar jacococli.jar report --classfiles jacococli.jar --html report merged.exec

For the instrument there is at least output for the ones, who are capable of reading it 😆

java -jar jacococli.jar instrument --dest instrumented
[INFO] 0 classes instrumented to /private/tmp/j/instrumented.

So printing to console sounds like a good option.
But I'm fine to leave this as is for now.

Copy link
Member

@Godin Godin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bjkail
Copy link
Contributor

bjkail commented May 24, 2017

@Godin The nullglob shell option should make it work, but it's not the default.

@marchof
Copy link
Member Author

marchof commented May 24, 2017

@Godin Added warning about not providing exec files or class files to merge, report, classinfo and execinfo in 4907b22

@marchof
Copy link
Member Author

marchof commented May 24, 2017

@Godin I think I now fixed all issues identified by you. Thx again for the detailed review!

@Godin Godin merged commit 13f12d3 into master May 24, 2017
@Godin Godin deleted the issue-525 branch May 24, 2017 22:53
@jacoco jacoco locked as resolved and limited conversation to collaborators Jan 11, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants