Awesome. Could you provide your JaCoCo definition from your POM here so we can also use that for verification of this issue?
Gj On Sun, 30 Jun 2019 at 23:26, Mark Herkrath <[email protected]> wrote: > Hi Geertjan, > > Sorry, I cannot follow this group regularly. I have validated the fix in > 11.1 beta 1 now and resolved NETBEANS-2652. > > Regards, > Mark > > > On Tue, Jun 18, 2019 at 5:59 PM Geertjan Wielenga <[email protected]> > wrote: > > > Hi Mark, > > > > Can you check that the problem is now solved in beta-1 of 11.1? > > > > Thanks, > > > > Gj > > > > > > On Sat, Jun 8, 2019 at 12:35 AM Mark Herkrath > > <[email protected]> wrote: > > > > > Hi, > > > > > > I have created NETBEANS-2652 > > > <https://issues.apache.org/jira/browse/NETBEANS-2652> and the > > > corresponding pull > > > request <https://github.com/apache/netbeans/pull/1286>. > > > > > > Mark > > > > > > On Thu, Jun 6, 2019 at 7:36 PM Geertjan Wielenga <[email protected]> > > > wrote: > > > > > > > We agree and the pull request would be awesome! :-) > > > > > > > > Gj > > > > > > > > On Thu, 6 Jun 2019 at 19:04, Mark Herkrath <[email protected] > > > > .invalid> > > > > wrote: > > > > > > > > > Hi community. > > > > > > > > > > I have written the original mail as per instructions on the NB > site. > > > > > JaCoCo is effectively not working with NB 11 unless configured in a > > > > > non-standard way. I have spent some time in analyzing and fixing > this > > > > issue > > > > > (for me). I am happy to contribute the fix to everyone, but > somebody > > > > > entitled needs to agree. Then I provide a pull request. > > > > > > > > > > Thanks, > > > > > Mark > > > > > > > > > > > Am 23.05.2019 um 18:34 schrieb Mark Herkrath < > > > [email protected] > > > > >: > > > > > > > > > > > > Hi, > > > > > > > > > > > > I am running into issues with JaCoCo in NB 11. It was working > well > > in > > > > NB > > > > > 10. > > > > > > > > > > > > The problem is the following, it got introduced by NETBEANS-1768 > - > > > > > "CodeCoverage doesn't work when custom outputDirectory is used in a > > > > > PluginExecution": > > > > > > > > > > > > In the change done, it is tested if the predetermined JaCoCo > output > > > > > directory exists. If it doesn't exist, the outputDirectory variable > > is > > > > > overwritten by the outputDirectory configuration of the JaCoCo > > > report > > > > > goal. However, if this is not defined, the outputDirectory variable > > > > becomes > > > > > null. As a result, the file is being watched via FileChangeAdapter > > > > becomes > > > > > C:\Program Files\NetBeans 11.0\bin\jacoco.xml, or similar. > > > > > > > > > > > > Now, often the Maven target directory, or at least the JaCoCo > > output > > > > > directory, doesn't exist yet when the Code Coverage report is > opened. > > > Due > > > > > to the issue described above, NB doesn't detect when jacoco.xml > > becomes > > > > > available and claims that there is no data yet. > > > > > > > > > > > > As per my understanding NETBEANS-1768 was fixed incorrectly. The > > fix > > > > > should have been only to change line 128: > > > > > > outputDirectory = PluginPropertyUtils.getPluginProperty(p, > > > > GROUP_JOCOCO, > > > > > ARTIFACT_JOCOCO, "outputDirectory", null, null); > > > > > > to > > > > > > outputDirectory = PluginPropertyUtils.getPluginProperty(p, > > > > GROUP_JOCOCO, > > > > > ARTIFACT_JOCOCO, "outputDirectory", "report", null); > > > > > > > > > > > > As a result, the outputDirectory setting will be taken from the > > > report > > > > > goal level but it will still picked up correctly if the plug > > > > configuration > > > > > is done at plugin level for example. > > > > > > > > > > > > I have commented about this issue at NETBEANS-1997, which was > > > reopened > > > > > by someone else. Possibly it would be better to create a new > ticket. > > > > JaCoCo > > > > > 0.8.3 is working well for me after applying the above change. > > > > > > > > > > > > Cheers, > > > > > > Mark > > > > > > > > > > > > > > >
