> On 11 Nov 2019, at 23:40, Gilles Sadowski <[email protected]> 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 think commons-parent should not be setup to generated empty reports when it
is not included as a profile.
> 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. 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 <[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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
