Better jcov integration

[Eric McCorkle]

As it stands now, I end up needing both jcov.jar and jcov_file_saver.jar
in the build process (admittedly in a somewhat un-Maven-like manner).

The plugin build process right now ends up unpacking the main jcov jar
into the classes directory before it builds the plugin.  My first
thought was to just mirror the jcov source and build it, but
unfortunately that didn't work.  It seems Maven trips over itself trying
to process ASM 6.0 jars, something about not being able to deal with
module info correctly.  I suspect that will be corrected in time, but I
wanted to get things working in the now.

This requires a somewhat ugly hack of deploying the jcov jar to whatever
Maven environment you use to build the plugin.  Now, I also have to rely
on tools.jar, but I do that as a "system" dependency, which is expected
to be installed on whatever machine uses the plugin (you can't, to my
knowledge, use jcov with a third-party JRE installation).  That presents
a way out: if there was something like a jcov installer that placed the
jars somewhere in JAVA_HOME (there may well already be), then you could
call the jcov jars a system dependency as well.

Also, the file saver jar has to be included as a resource.  Curiously,
putting the main jcov jar on the classpath of an instrumented
application results in no coverage information being saved (despite file
saver seemingly being a subset of the classes).

So at present, the plugin is more a consumer of the jars produced by the
jcov build.

On 02/28/2018 16:12, Kevin Looney wrote:
> Seconded!
> 
> Alexey and I had a very similar discussion this morning, and came up
> with some pseudo-priorities:
> 
> 1.) Follow any Oracle mandates regarding external dependencies
> 2.) Limit-liability within a (little-p) project by keeping
> plugin/external-dependency related code separate/branched from the core
> of the project.
> 
> It might be nice to have a convention across all code-tools, like a
> "plugins directory".   I'm not sure if 'plugins' is the right name, but
> that certainly is one category of external dependencies.
> 
> In any case, I'm not sure which way to go for us on support for Maven
> (we are already inconsistent in support, since we provided something for
> SigTest - on Bill Shannon's request).  Still leaning towards Oracle's
> mandate against (not sure I wish to fight with Legal over that).
> 
> Thanks,
> Kevin
> 
> On 2/28/18 1:03 PM, Jonathan Gibbons wrote:
>> Alexey, Eric,
>>
>> Maurizio set a useful and relevant precedent when he contributed the
>> IntelliJ plugin for jtreg.
>>
>> I think it is useful to keep separate the code for a tool (like jtreg
>> or JCov) from any code
>> that "wraps" the functionality of a tool into a plugin for some larger
>> system, such as an
>> IDE or CI system, but keeping it separate does not inherently mandate
>> keeping it out of
>> a  Code Tools repository ... and having a "plugins" directory in a
>> repo could well be a
>> good way to go. It also helps keep separate any maintenance concerns
>> of the primary
>> functionality of the tool or library from any wrapper code that is
>> specific to an external
>> system, but facilitates combined building and testing where practical.
>>
>> -- Jon
>>
>>
>> On 02/28/2018 12:20 PM, Alexey Fedorchenko wrote:
>>> Hello, Eric!
>>>
>>> Thank you for the report. I have added an issue for your request [1].
>>> We will address it, I also think that having more report formats is a
>>> good suggestion.
>>>
>>> A few thoughts about the original problem of adding JCov to CI
>>> (Jenkins):
>>> - use html publisher plugin to show JCov html report
>>> - plot build data with plot plugin to look at the coverage trend for
>>> builds
>>> ( it will require using grep and sed to get data from
>>> overview-summary.html to plot.csv )
>>> - create JCov plugin for Jenkins.
>>>
>>> The latest item and Maven plugin opens a little bit bigger discussion
>>> for Code Tools projects:
>>> Could we have tool's plugins sources in tool’s repository?
>>>
>>> Thank you.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902125
>>>
>>> —Alexey
>>>
>>>> On Feb 28, 2018, at 4:42 AM, Eric McCorkle <eric at metricspace.net
>>>> <mailto:eric at metricspace.net>> wrote:
>>>>
>>>> Hello everyone,
>>>>
>>>> I recently found myself needing better integration of jcov into various
>>>> build/testing tools, so I did two things.  First, I modified the jcov
>>>> tool to generate a report in the Cobertura XML format, which is used by
>>>> Jenkins and other tools as an input format.  While these reports are
>>>> inferior in my opinion to the HTML reports jcov generates, they do
>>>> allow
>>>> integration with other tools and CI systems.  Therefore, I think
>>>> providing this functionality would likely encourage more people to use
>>>> jcov over the alternatives.
>>>>
>>>> I've attached the patch for this modification here, if anyone would
>>>> like
>>>> to review it.
>>>>
>>>>
>>>> I've also mostly wrangled the Maven plugin API to create a plugin for
>>>> using jcov in a Maven project (however, there is one remaining issue
>>>> with documentation generation that I need to correct before I call the
>>>> plugin "finished").  I'm not sure if that would be something that would
>>>> be added to codetools, if the group ID should be something like
>>>> "org.openjdk", or what else ought to be done about it.  I will gladly
>>>> contribute the code if there's a desire to adopt it.
>>>> <cobertura.diff>
>>>
>>
>