From rkennke at redhat.com  Thu Feb 15 10:59:15 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 15 Feb 2018 11:59:15 +0100
Subject: Problems building jtreg
Message-ID: <CAAN-KyhGY=i9n36E5qmbjwbC3dq0jDO7fssezg8zoGsgC8bToA@mail.gmail.com>

Hi all,
I am trying to build latest jdk. It requires jtreg 4.2 b12.
AdoptOpenJDK doesn't provide that.

Therefore I am trying to build jtreg myself. I first tried 'make -C
make' which did not work at all. I then tried:

bash make/build-all.sh /path/to/jdk8

Which made some progress, but then failed because it could not find
'shasum'. I am trying this on latest CentOS7. It does have:

sha1sum    sha224sum  sha256sum  sha384sum  sha512sum

I replaced shasum with sha1sum all over the build scripts, but
apparently it does not accept the '-a' flag.

Any ideas?

Cheers, Roman

From martijnverburg at gmail.com  Thu Feb 15 11:12:31 2018
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Thu, 15 Feb 2018 11:12:31 +0000
Subject: Problems building jtreg
In-Reply-To: <CAAN-KyhGY=i9n36E5qmbjwbC3dq0jDO7fssezg8zoGsgC8bToA@mail.gmail.com>
References: <CAAN-KyhGY=i9n36E5qmbjwbC3dq0jDO7fssezg8zoGsgC8bToA@mail.gmail.com>
Message-ID: <CAP7YuAR5nyk_bkmRUdEWnf=rdFQZvvueogcLeiMUN7vYZmh7Mg@mail.gmail.com>

Hi Roman,

I think https://ci.adoptopenjdk.net/view/all/job/jtreg/283/ has what you
need?  Was built on the 8th of Feb

Cheers,
Martijn

On 15 February 2018 at 10:59, Roman Kennke <rkennke at redhat.com> wrote:

> Hi all,
> I am trying to build latest jdk. It requires jtreg 4.2 b12.
> AdoptOpenJDK doesn't provide that.
>
> Therefore I am trying to build jtreg myself. I first tried 'make -C
> make' which did not work at all. I then tried:
>
> bash make/build-all.sh /path/to/jdk8
>
> Which made some progress, but then failed because it could not find
> 'shasum'. I am trying this on latest CentOS7. It does have:
>
> sha1sum    sha224sum  sha256sum  sha384sum  sha512sum
>
> I replaced shasum with sha1sum all over the build scripts, but
> apparently it does not accept the '-a' flag.
>
> Any ideas?
>
> Cheers, Roman
>

From rkennke at redhat.com  Thu Feb 15 11:22:02 2018
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 15 Feb 2018 12:22:02 +0100
Subject: Problems building jtreg
In-Reply-To: <CAP7YuAR5nyk_bkmRUdEWnf=rdFQZvvueogcLeiMUN7vYZmh7Mg@mail.gmail.com>
References: <CAAN-KyhGY=i9n36E5qmbjwbC3dq0jDO7fssezg8zoGsgC8bToA@mail.gmail.com>
 <CAP7YuAR5nyk_bkmRUdEWnf=rdFQZvvueogcLeiMUN7vYZmh7Mg@mail.gmail.com>
Message-ID: <CAAN-KygQC7FN9cmNmDiJnmaLuouns16=iRnspcroR6ESNfwoxw@mail.gmail.com>

Ah. I was looking at:
https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/

Thank you for pointing me to this :-)

Would still be nice to be able to easily build jtreg myself. :-)

Cheers, Roman

On Thu, Feb 15, 2018 at 12:12 PM, Martijn Verburg
<martijnverburg at gmail.com> wrote:
> Hi Roman,
>
> I think https://ci.adoptopenjdk.net/view/all/job/jtreg/283/ has what you
> need?  Was built on the 8th of Feb
>
> Cheers,
> Martijn
>
> On 15 February 2018 at 10:59, Roman Kennke <rkennke at redhat.com> wrote:
>>
>> Hi all,
>> I am trying to build latest jdk. It requires jtreg 4.2 b12.
>> AdoptOpenJDK doesn't provide that.
>>
>> Therefore I am trying to build jtreg myself. I first tried 'make -C
>> make' which did not work at all. I then tried:
>>
>> bash make/build-all.sh /path/to/jdk8
>>
>> Which made some progress, but then failed because it could not find
>> 'shasum'. I am trying this on latest CentOS7. It does have:
>>
>> sha1sum    sha224sum  sha256sum  sha384sum  sha512sum
>>
>> I replaced shasum with sha1sum all over the build scripts, but
>> apparently it does not accept the '-a' flag.
>>
>> Any ideas?
>>
>> Cheers, Roman
>
>

From jonathan.gibbons at oracle.com  Thu Feb 15 15:14:04 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 15 Feb 2018 07:14:04 -0800
Subject: Problems building jtreg
In-Reply-To: <CAAN-KyhGY=i9n36E5qmbjwbC3dq0jDO7fssezg8zoGsgC8bToA@mail.gmail.com>
References: <CAAN-KyhGY=i9n36E5qmbjwbC3dq0jDO7fssezg8zoGsgC8bToA@mail.gmail.com>
Message-ID: <c57bfcaa-208d-c97b-3563-3213249bc9fe@oracle.com>

Roman,

I will update the build-all.sh script. Perhaps you will be able to test 
it on CentOS.

-- Jon


On 2/15/18 2:59 AM, Roman Kennke wrote:
> Hi all,
> I am trying to build latest jdk. It requires jtreg 4.2 b12.
> AdoptOpenJDK doesn't provide that.
>
> Therefore I am trying to build jtreg myself. I first tried 'make -C
> make' which did not work at all. I then tried:
>
> bash make/build-all.sh /path/to/jdk8
>
> Which made some progress, but then failed because it could not find
> 'shasum'. I am trying this on latest CentOS7. It does have:
>
> sha1sum    sha224sum  sha256sum  sha384sum  sha512sum
>
> I replaced shasum with sha1sum all over the build scripts, but
> apparently it does not accept the '-a' flag.
>
> Any ideas?
>
> Cheers, Roman


From volker.simonis at gmail.com  Tue Feb 20 16:01:02 2018
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 20 Feb 2018 17:01:02 +0100
Subject: Change "7902090: Update JDK_Version to be more future-proof" breaks
 some jtreg tests
Message-ID: <CA+3eh11NUEFD_URFexJTy76nL64ZGqnvVQyZsA=A9OavJEdoUA@mail.gmail.com>

Hi Johnathan,

it seems that your change "7902090: Update JDK_Version to be more
future-proof" breaks some jtreg tests. Specifically, all tests which
set "-source 1.9 -target 1.9" for the compile step (e.g.
test/jdk/java/lang/String/concat/ImplicitStringConcatArgCount.java
) will fail with a null pointer exception:

----------Stack trace:(9/649)----------
java.lang.NullPointerException
        at com.sun.javatest.regtest.exec.CompileAction.isModuleOptionsAllowed(CompileAction.java:525)
        at com.sun.javatest.regtest.exec.CompileAction.getJavacCommandArgs(CompileAction.java:469)
        at com.sun.javatest.regtest.exec.CompileAction.run(CompileAction.java:357)
        at com.sun.javatest.regtest.exec.RegressionScript.run(RegressionScript.java:247)
        at com.sun.javatest.Script.run(Script.java:241)
        at com.sun.javatest.DefaultTestRunner.runTest(DefaultTestRunner.java:174)
        at com.sun.javatest.DefaultTestRunner.access$100(DefaultTestRunner.java:43)
        at com.sun.javatest.DefaultTestRunner$1.run(DefaultTestRunner.java:66)
result: Not run. Test running...

So the new behavior doesn't really seem to be more "future-proof" :)

Do you plan to fix this in jtreg or do you want to change all the
jtreg tests which use "1.9"  to use "9" instead? I personally think
that at least as long as "javac" supports both notations, jtreg should
support them as well.

Thanks,
Volker

From jonathan.gibbons at oracle.com  Tue Feb 20 16:07:07 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 20 Feb 2018 08:07:07 -0800
Subject: Change "7902090: Update JDK_Version to be more future-proof"
 breaks some jtreg tests
In-Reply-To: <CA+3eh11NUEFD_URFexJTy76nL64ZGqnvVQyZsA=A9OavJEdoUA@mail.gmail.com>
References: <CA+3eh11NUEFD_URFexJTy76nL64ZGqnvVQyZsA=A9OavJEdoUA@mail.gmail.com>
Message-ID: <04e586f1-ff8d-4594-0559-62be348f20f0@oracle.com>

Volker,

Thanks for the report.

1.9 is not an official version number, but neither is NPE the intended 
effect. I will check out the code to see the possibilities.

-- Jon


On 2/20/18 8:01 AM, Volker Simonis wrote:
> Hi Johnathan,
>
> it seems that your change "7902090: Update JDK_Version to be more
> future-proof" breaks some jtreg tests. Specifically, all tests which
> set "-source 1.9 -target 1.9" for the compile step (e.g.
> test/jdk/java/lang/String/concat/ImplicitStringConcatArgCount.java
> ) will fail with a null pointer exception:
>
> ----------Stack trace:(9/649)----------
> java.lang.NullPointerException
>          at com.sun.javatest.regtest.exec.CompileAction.isModuleOptionsAllowed(CompileAction.java:525)
>          at com.sun.javatest.regtest.exec.CompileAction.getJavacCommandArgs(CompileAction.java:469)
>          at com.sun.javatest.regtest.exec.CompileAction.run(CompileAction.java:357)
>          at com.sun.javatest.regtest.exec.RegressionScript.run(RegressionScript.java:247)
>          at com.sun.javatest.Script.run(Script.java:241)
>          at com.sun.javatest.DefaultTestRunner.runTest(DefaultTestRunner.java:174)
>          at com.sun.javatest.DefaultTestRunner.access$100(DefaultTestRunner.java:43)
>          at com.sun.javatest.DefaultTestRunner$1.run(DefaultTestRunner.java:66)
> result: Not run. Test running...
>
> So the new behavior doesn't really seem to be more "future-proof" :)
>
> Do you plan to fix this in jtreg or do you want to change all the
> jtreg tests which use "1.9"  to use "9" instead? I personally think
> that at least as long as "javac" supports both notations, jtreg should
> support them as well.
>
> Thanks,
> Volker


From jonathan.gibbons at oracle.com  Fri Feb 23 00:10:05 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 22 Feb 2018 16:10:05 -0800
Subject: Change "7902090: Update JDK_Version to be more future-proof"
 breaks some jtreg tests
In-Reply-To: <04e586f1-ff8d-4594-0559-62be348f20f0@oracle.com>
References: <CA+3eh11NUEFD_URFexJTy76nL64ZGqnvVQyZsA=A9OavJEdoUA@mail.gmail.com>
 <04e586f1-ff8d-4594-0559-62be348f20f0@oracle.com>
Message-ID: <5A8F5BDD.5030600@oracle.com>

Volker,

Yes, I'd forgotten that specific use case of JDK_Version.forName, and 
regrettably agree that the method should agree with javac. I see javac 
has (finally) started restricting the version name in 11.

-- Jon

On 02/20/2018 08:07 AM, Jonathan Gibbons wrote:
> Volker,
>
> Thanks for the report.
>
> 1.9 is not an official version number, but neither is NPE the intended 
> effect. I will check out the code to see the possibilities.
>
> -- Jon
>
>
> On 2/20/18 8:01 AM, Volker Simonis wrote:
>> Hi Johnathan,
>>
>> it seems that your change "7902090: Update JDK_Version to be more
>> future-proof" breaks some jtreg tests. Specifically, all tests which
>> set "-source 1.9 -target 1.9" for the compile step (e.g.
>> test/jdk/java/lang/String/concat/ImplicitStringConcatArgCount.java
>> ) will fail with a null pointer exception:
>>
>> ----------Stack trace:(9/649)----------
>> java.lang.NullPointerException
>>          at 
>> com.sun.javatest.regtest.exec.CompileAction.isModuleOptionsAllowed(CompileAction.java:525)
>>          at 
>> com.sun.javatest.regtest.exec.CompileAction.getJavacCommandArgs(CompileAction.java:469)
>>          at 
>> com.sun.javatest.regtest.exec.CompileAction.run(CompileAction.java:357)
>>          at 
>> com.sun.javatest.regtest.exec.RegressionScript.run(RegressionScript.java:247)
>>          at com.sun.javatest.Script.run(Script.java:241)
>>          at 
>> com.sun.javatest.DefaultTestRunner.runTest(DefaultTestRunner.java:174)
>>          at 
>> com.sun.javatest.DefaultTestRunner.access$100(DefaultTestRunner.java:43)
>>          at 
>> com.sun.javatest.DefaultTestRunner$1.run(DefaultTestRunner.java:66)
>> result: Not run. Test running...
>>
>> So the new behavior doesn't really seem to be more "future-proof" :)
>>
>> Do you plan to fix this in jtreg or do you want to change all the
>> jtreg tests which use "1.9"  to use "9" instead? I personally think
>> that at least as long as "javac" supports both notations, jtreg should
>> support them as well.
>>
>> Thanks,
>> Volker
>


From eric at metricspace.net  Wed Feb 28 12:42:57 2018
From: eric at metricspace.net (Eric McCorkle)
Date: Wed, 28 Feb 2018 07:42:57 -0500
Subject: Better jcov integration
Message-ID: <6d88a4b5-2f2d-5a5b-9aff-9a79ea7b626e@metricspace.net>

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cobertura.diff
Type: text/x-patch
Size: 20559 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/code-tools-dev/attachments/20180228/35e6dc19/cobertura.diff>

From martijnverburg at gmail.com  Wed Feb 28 13:13:54 2018
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Wed, 28 Feb 2018 13:13:54 +0000
Subject: Better jcov integration
In-Reply-To: <6d88a4b5-2f2d-5a5b-9aff-9a79ea7b626e@metricspace.net>
References: <6d88a4b5-2f2d-5a5b-9aff-9a79ea7b626e@metricspace.net>
Message-ID: <CAP7YuASSrKyDNYpr3qzVq9AYxitbryBRffvQvUsft7Myj5maoQ@mail.gmail.com>

Hi Eric,

If it can?t be accepted as an net.openjdk project then we could host it at
AdoptOpenJDK (we already have some OpenJDK related Maven plugins there for
example).

I?ll let Jonathan et al comment on the rest.

Cheers,
Martijn

On Wed, 28 Feb 2018 at 12:43, Eric McCorkle <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.
>
-- 
Cheers, Martijn (Sent from Gmail Mobile)

From jonathan.gibbons at oracle.com  Wed Feb 28 17:05:32 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 28 Feb 2018 09:05:32 -0800
Subject: Better jcov integration
In-Reply-To: <6d88a4b5-2f2d-5a5b-9aff-9a79ea7b626e@metricspace.net>
References: <6d88a4b5-2f2d-5a5b-9aff-9a79ea7b626e@metricspace.net>
Message-ID: <37489267-c6b7-0882-f5af-d90574ebab04@oracle.com>

cc: jcov-dev at ojn

Hi Eric,

Generally, writing reports in other useful formats certainly seems like 
a good, pragmatic suggestion, although I'll leave it to the JCov team to 
comment in more detail.

-- Jon


On 2/28/18 4:42 AM, Eric McCorkle 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.


From alexey.fedorchenko at oracle.com  Wed Feb 28 20:20:41 2018
From: alexey.fedorchenko at oracle.com (Alexey Fedorchenko)
Date: Wed, 28 Feb 2018 12:20:41 -0800
Subject: Better jcov integration
In-Reply-To: <6d88a4b5-2f2d-5a5b-9aff-9a79ea7b626e@metricspace.net>
References: <6d88a4b5-2f2d-5a5b-9aff-9a79ea7b626e@metricspace.net>
Message-ID: <1B54BB8C-6877-4425-897D-687926294A6D@oracle.com>

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 <https://bugs.openjdk.java.net/browse/CODETOOLS-7902125>

?Alexey

> On Feb 28, 2018, at 4:42 AM, Eric McCorkle <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>


From jonathan.gibbons at oracle.com  Wed Feb 28 21:03:50 2018
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 28 Feb 2018 13:03:50 -0800
Subject: Better jcov integration
In-Reply-To: <1B54BB8C-6877-4425-897D-687926294A6D@oracle.com>
References: <6d88a4b5-2f2d-5a5b-9aff-9a79ea7b626e@metricspace.net>
 <1B54BB8C-6877-4425-897D-687926294A6D@oracle.com>
Message-ID: <5A971936.2070707@oracle.com>

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


From kevin.looney at oracle.com  Wed Feb 28 21:12:19 2018
From: kevin.looney at oracle.com (Kevin Looney)
Date: Wed, 28 Feb 2018 13:12:19 -0800
Subject: Better jcov integration
In-Reply-To: <5A971936.2070707@oracle.com>
References: <6d88a4b5-2f2d-5a5b-9aff-9a79ea7b626e@metricspace.net>
 <1B54BB8C-6877-4425-897D-687926294A6D@oracle.com>
 <5A971936.2070707@oracle.com>
Message-ID: <645767c7-9ced-0b52-acbb-e9d6fc01d005@oracle.com>

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