On 12/11/2019 09:06, Gilles Sadowski wrote:
2019-11-12 2:28 UTC+01:00, Alex Herbert <[email protected]>:
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 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).
Looking at the documentation I think this problem has been fixed with
optional properties. The appropriate property is not used in CP but a
project could just set it to true and the build would not fail.
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.
I've tried to update RNG to work with japicmp conditionally.
Unfortunately once the maven plugin is included there is no way to
totally disable it. It will always put up an empty report in the site
generation.
The fix was to locally change CP 49 (which RNG depends on) to move all
the configuration inside the profile that is activated using the file
'src/site/resources/profile.japicmp'.
A first fix with this present broke the RNG build on pre-Java8 JDKs. The
profile activation should also include activation if the JDK is 1.8+:
<activation>
<jdk>[1.8,)</jdk>
<file>
<exists>src/site/resources/profile.japicmp</exists>
</file>
</activation>
I've rebuilt the report pages of the site using this set-up (fixed RNG,
fudged CP 49 locally). The JaCoCo aggregates are gone and the japicmp
reports are gone for all but:
https://commons.apache.org/proper/commons-rng/commons-rng-client-api/japicmp.html
https://commons.apache.org/proper/commons-rng/commons-rng-core/japicmp.html
https://commons.apache.org/proper/commons-rng/commons-rng-simple/japicmp.html
https://commons.apache.org/proper/commons-rng/commons-rng-sampling/japicmp.html
To fix the RNG build so that it can optionally include japicmp in the
report menus will require a change to the parent.
However some projects may not be using
'src/site/resources/profile.japicmp' to activate the profile. They may
be directly using <japicmp.skip>false</japicmp.skip>.
So how to proceed with a fix for CP?
Alex
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 <[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]
---------------------------------------------------------------------
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]
