2019-11-12 2:28 UTC+01:00, Alex Herbert <alex.d.herb...@gmail.com>: > > >> On 11 Nov 2019, at 23:40, Gilles Sadowski <gillese...@gmail.com> wrote: >> >> Hi. >> >> Maybe I'm missing what the issues really are, > > All empty japicmp reports on the site. > Some confusing empty Jacoco aggregate reports on the site. > >> so sorry if this top-posted >> reply is beside the points: >> 1. There always have been several issues with JapiCmp (I do not remember >> exactly which; it must be in the ML archive); it never worked with >> Commons >> RNG. [As as been mentioned in some thread and on JIRA, it might be worth >> spending time (if any) setting up the tools provided by the "revapi" >> project.] >> For now, Clirr still works fine for [RNG] (IIUC because of its "old" JDK >> target) >> and there is no need to have JapiCmp. > > I’ve got japicmp to work in master. Maybe old versions had problems that > have now been fixed.
I seem to remember that it failed the build for release 1.0 because there was no version to compare with (and it couldn't be prevented to run using the CP setup - cf. below). > > I think commons-parent should not be setup to generated empty reports when > it is not included as a profile. +1 That was one of the issue. Such plugins are optionally activated by the presence of a file, and should not run if the file is not present. The setup works for other tools but it didn't for JapiCmp. >> 2. IMHO, there is no need for Jacoco aggregate reports; each module has >> its >> own "plain" report, accessible under the module's "sub-site" along with >> all >> the other reports concerned with that particular body of code. If >> designed >> correctly (and in order to work under JPMS), the modules must have >> acyclic dependencies, and it seems to me equally meaningless to have >> modules >> aggregate reports as to have aggregate reports of external dependencies. > > +1. > > I’ve disabled the aggregate report in RNG. I think it should be disabled in > commons-parent. + 1 AFAICT, the latest CP enhanced automation does not take into account the "multi-module" maven feature. I had raised the question of why a "dist-archive" module is necessary: It seems to me that all the info being in the modules, the main POM should be able to generate, collect and "archive" all the artefacts under its own "target" directory. I've never dug very deep into maven, so I don't how whether it's possible or whether it's indeed to be done the (contorted, IMHO) way it is now. Regards, Gilles > It only makes sense to projects that have integration tests > to exercise combinations of components that cannot be tested standalone. > >> 3. People who will want more reports about some version of the library >> can download the project and run <whatever> locally. It was never >> mandated that the web site maintains a full history of all the versions; >> quite >> the contrary, users are always (kindly) requested to upgrade to the last >> version of a component (and IIUC, we are asked that older versions are >> made more difficult to access and download). >> >> Regards, >> Gilles >> >> 2019-11-11 23:05 UTC+01:00, Alex Herbert <alex.d.herb...@gmail.com>: >>> >>> >>>> On 11 Nov 2019, at 18:36, Gilles Sadowski <gillese...@gmail.com> wrote: >>>> >>>>>> [...] >>>>>> >>>>>> I will try and find out why these are running and just remove them. >>>>> >>>>> The pom requires this to skip aggregate reports [2]: >>>>> >>>>> <plugin> >>>>> <groupId>org.jacoco</groupId> >>>>> <artifactId>jacoco-maven-plugin</artifactId> >>>>> <reportSets> >>>>> <reportSet> >>>>> <reports> >>>>> <!-- select non-aggregate reports --> >>>>> <report>report</report> >>>>> </reports> >>>>> </reportSet> >>>>> </reportSets> >>>>> </plugin> >>>>> >>>>> [2] https://www.eclemma.org/jacoco/trunk/doc/maven.html >>>>> >>>>> >>>>> Is it OK to take my release branch and do the modifications on that >>>>> to: >>>>> >>>>> 1. add JAPIcmp (since the <japicmp.skip>true</japicmp.skip> in the >>>>> parent still generates reports) >>>>> >>>>> 2. skip JaCoCo aggregates >>>>> >>>>> to rebuild build and update the live site? >>>> >>>> I'd rather leave the release branch as is. >>>> >>>> IMO, the site should be fixed and built and updated from the "master" >>>> branch >>>> (since that will happen anyway the next time someone updates it). >>>> >>>> Gilles >>> >>> Master has now been updated to ignore the JaCoCo aggregate report. master >>> is >>> also configured to use the new japicmp functionality. I added it when >>> reviewing 1.3 RC1 and noticed the japicmp report was empty. I didn’t >>> think >>> it warranted a new RC as it is just a report and I presumed this empty >>> report was normal. But it may be that this is the first time we released >>> a >>> component since commons-parent added japicmp without using actually >>> using >>> japicmp. >>> >>> Anyway master has the correct configuration for site builds so this >>> requires >>> no configuration changes. >>> >>> Unfortunately using master will not allow a full site generation to be >>> used >>> as a drop in replacement using only command line properties. >>> >>> Both clirr and japicmp put the version in the report so it will appear >>> as >>> 1.4-SNAPSHOT. You can dynamically update the version to compare against >>> but >>> not the current version. There is no way to set the version using >>> command >>> line parameters so you have to do this: >>> >>> mvn versions:set -DnewVersion=1.3 >>> mvn package site -Dcommons.release.version=1.2 >>> mvn versions:set -DnewVersion=1.4-SNAPSHOT >>> >>> This is a bit of a fudge because it updates all the POMs with a fudged >>> version. So although the reports now state “1.3” the code is using the >>> current source (from 1.4-SNAPSHOT) to build the jar file. >>> >>> For now this solution will work as the source has not changed. But once >>> the >>> source starts to diverge a site generation would produce incorrect >>> reports >>> for the current release so this is not to be used at any time to >>> regenerate >>> the entire site. >>> >>> I will try and get the site sorted using this approach by updating the >>> site >>> menus (to drop the Jacoco aggregate report) and fix japicmp. >>> >>> >>> — >>> >>> Issues with commons parent: >>> >>> japicmp >>> >>> For japicmp it seems the maven plugin is a bit immature in that even if >>> it >>> is set to skip it will create a menu in the reports during site >>> creation. >>> >>> So introducing the configuration in the main part of the pom for japicmp >>> in >>> commons-parent means that any commons codebase not using japicmp will >>> have >>> this empty report. Ideally the configuration should all be in the >>> profile. >>> So if the profile is not enabled then japicmp does not effectively >>> exist, >>> rather than relying on its broken skip report execution. >>> >>> At current commons-parent effectively forces all commons projects to >>> either >>> use japicmp or have an empty report in the site. >>> >>> >>> JaCoCo >>> >>> By default the aggregate reports only appear when the module has >>> dependencies on other modules. It thus only effects multi-module builds. >>> What parts of commons are multi-module? I know of: >>> >>> - RNG >>> - Numbers >>> - Geometry >>> - Statistics >>> >>> Are there any others? >>> >>> For all of these the following fix from RNG could be used: >>> >>> <reportSets> >>> <reportSet> >>> <reports> >>> <!-- select non-aggregate reports --> >>> <report>report</report> >>> </reports> >>> </reportSet> >>> </reportSets> >>> >>> Perhaps this should go into parent. Then multi-module builds would have >>> to >>> explicitly decide if they wanted an aggregate report. This should go >>> into >>> the POM for each module that wants it. Putting it into the top level POM, >>> or >>> any other module POM that has no dependencies, creates the empty report >>> seen >>> for RNG. >>> >>> Alex >>> >>> >>>> >>>>>> >>>>>> >>>>>> [...] >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
