Hi. Maybe I'm missing what the issues really are, 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. 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. 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 <[email protected]>: > > >> On 11 Nov 2019, at 18:36, Gilles Sadowski <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
