Better jcov integration

[Kevin Looney]

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>
>>
>

-- 
kevin.looney at oracle.com