[GitHub] [maven-javadoc-plugin] olamy opened a new pull request #37: [MJAVADOC-636] exclude some modules from aggregated javadoc
olamy opened a new pull request #37: [MJAVADOC-636] exclude some modules from aggregated javadoc URL: https://github.com/apache/maven-javadoc-plugin/pull/37 Signed-off-by: olivier lamy Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MJAVADOC) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MJAVADOC-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MJAVADOC-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify -Prun-its` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (MJAVADOC-636) Exclude some modules when building aggregate
Olivier Lamy created MJAVADOC-636: - Summary: Exclude some modules when building aggregate Key: MJAVADOC-636 URL: https://issues.apache.org/jira/browse/MJAVADOC-636 Project: Maven Javadoc Plugin Issue Type: Dependency upgrade Components: javadoc Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: 3.2.0 per default aggregate build all modules except skipped javadoc module. But user may want not skip javadoc as single module but still skipping them when building aggregate. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1751) Surefire report shows flaky tests as failures
[
https://issues.apache.org/jira/browse/SUREFIRE-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036616#comment-17036616
]
Tibor Digana commented on SUREFIRE-1751:
Why you used {{surefire-report-parser}} in you POM?
I meant a contribution on Github ;-) So i can guide you through the fix in our
code.
> Surefire report shows flaky tests as failures
> -
>
> Key: SUREFIRE-1751
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1751
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M4
>Reporter: Anu
>Priority: Critical
> Attachments: Test.zip, image-2020-02-13-11-41-03-906.png
>
>
> We have been using maven-surefire-plugin in 2.22.1 and Junit4.13 for our
> testing. Now we are trying to upgrade junit to junit5 and saw that the
> r{color:#6a8759}erunFailingTestsCount parameter isn't working with surefire
> plugin version. I upgraded surefire to 3.0.0.M4 and verified that the failing
> tests are now being retried. But the issue is flaky tests show up in the
> report as Failures.
> {color}
>
> {color:#6a8759}ie. the log shows
> {color}
> [WARNING] Tests run: 10455, Failures: 0, Errors: 0, Skipped: 993, Flakes: 10
>
> But the actual surefire report shows like below
> !image-2020-02-13-11-41-03-906.png!
>
> This is blocking our junit5 upgrade task. Can you please provide a fix for
> this at the earliest? Please let me know if you need anything else from me to
> help with the investigation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MRESOURCES-237:
Fix Version/s: 3.1.1
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 3.1.1
>
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink pointing to the wrong
> file location. The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document
> the change and provide a configuration parameter to allow the legacy behavior.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036605#comment-17036605
]
Olivier Lamy commented on MRESOURCES-237:
-
the main issue with this change: it has never been documented and I guess it's
an non intended change :)
it causes this issue [https://issues.jenkins-ci.org/browse/JENKINS-59291]
I will try to add a parameter to be able to restore the previous behaviour (a
parameter to be backward compatible :P )
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink pointing to the wrong
> file location. The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document
> the change and provide a configuration parameter to allow the legacy behavior.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MRESOURCES-237) Resource plugin's handling of symbolic links changed in 3.0.x, broke existing behavior
[
https://issues.apache.org/jira/browse/MRESOURCES-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy reassigned MRESOURCES-237:
---
Assignee: Olivier Lamy
> Resource plugin's handling of symbolic links changed in 3.0.x, broke existing
> behavior
> --
>
> Key: MRESOURCES-237
> URL: https://issues.apache.org/jira/browse/MRESOURCES-237
> Project: Maven Resources Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1, 3.0.2
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T11:41:47-05:00)
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.121-1.b14.fc25.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.9.11-200.fc25.x86_64", arch: "amd64", family:
> "unix"
>Reporter: Brian D. Johnson
>Assignee: Olivier Lamy
>Priority: Minor
>
> It looks like the handling of symbolic links in the
> {{maven-resources-plugin}} has changed in version 3.0.x. I'm submitting a
> JIRA because it breaks the previous behavior and I have not been able to find
> this documented anywhere as an intended change.
> *Use case:* Multi-module maven project. We have a custom log4j2
> configuration file we use during testing. Instead of maintaining this file
> in multiple {{src/test/resources}} directories, we instead maintain a single
> copy of the file at the project's root level and create symbolic links from
> each module's {{src/test/resources}} directory to the file using relative
> paths.
> *2.7 Behavior:* the symlink was evaluated and the target file was copied to
> {{target/test-classes/}}.
> *3.0.x Behavior:* the symlink is copied to {{target/test-classes/}} verbatim.
> The symlink's relative path results in the symlink pointing to the wrong
> file location. The log4j2 configuration is not found.
> *Requested Change:* Either revert to the original 2.7 behavior, or document
> the change and provide a configuration parameter to allow the legacy behavior.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1751) Surefire report shows flaky tests as failures
[
https://issues.apache.org/jira/browse/SUREFIRE-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036573#comment-17036573
]
Anu commented on SUREFIRE-1751:
---
Thanks [~tibordigana] for the response. I have attached Test.zip with the
ticket. Can you check if that helps?
The command I used to run the tests was
{code:java}
mvn surefire-report:report -Dsurefire.rerunFailingTestsCount=2
-Dtest=Flakes,Pass{code}
> Surefire report shows flaky tests as failures
> -
>
> Key: SUREFIRE-1751
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1751
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M4
>Reporter: Anu
>Priority: Critical
> Attachments: Test.zip, image-2020-02-13-11-41-03-906.png
>
>
> We have been using maven-surefire-plugin in 2.22.1 and Junit4.13 for our
> testing. Now we are trying to upgrade junit to junit5 and saw that the
> r{color:#6a8759}erunFailingTestsCount parameter isn't working with surefire
> plugin version. I upgraded surefire to 3.0.0.M4 and verified that the failing
> tests are now being retried. But the issue is flaky tests show up in the
> report as Failures.
> {color}
>
> {color:#6a8759}ie. the log shows
> {color}
> [WARNING] Tests run: 10455, Failures: 0, Errors: 0, Skipped: 993, Flakes: 10
>
> But the actual surefire report shows like below
> !image-2020-02-13-11-41-03-906.png!
>
> This is blocking our junit5 upgrade task. Can you please provide a fix for
> this at the earliest? Please let me know if you need anything else from me to
> help with the investigation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1751) Surefire report shows flaky tests as failures
[
https://issues.apache.org/jira/browse/SUREFIRE-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anu updated SUREFIRE-1751:
--
Attachment: Test.zip
> Surefire report shows flaky tests as failures
> -
>
> Key: SUREFIRE-1751
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1751
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M4
>Reporter: Anu
>Priority: Critical
> Attachments: Test.zip, image-2020-02-13-11-41-03-906.png
>
>
> We have been using maven-surefire-plugin in 2.22.1 and Junit4.13 for our
> testing. Now we are trying to upgrade junit to junit5 and saw that the
> r{color:#6a8759}erunFailingTestsCount parameter isn't working with surefire
> plugin version. I upgraded surefire to 3.0.0.M4 and verified that the failing
> tests are now being retried. But the issue is flaky tests show up in the
> report as Failures.
> {color}
>
> {color:#6a8759}ie. the log shows
> {color}
> [WARNING] Tests run: 10455, Failures: 0, Errors: 0, Skipped: 993, Flakes: 10
>
> But the actual surefire report shows like below
> !image-2020-02-13-11-41-03-906.png!
>
> This is blocking our junit5 upgrade task. Can you please provide a fix for
> this at the earliest? Please let me know if you need anything else from me to
> help with the investigation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MGPG-77) Make build Reproducible
[ https://issues.apache.org/jira/browse/MGPG-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MGPG-77. - Assignee: Herve Boutemy Resolution: Fixed done in https://gitbox.apache.org/repos/asf?p=maven-gpg-plugin.git=commit=6741146b839da82663a6e7b114ea198d9c23ae93 > Make build Reproducible > --- > > Key: MGPG-77 > URL: https://issues.apache.org/jira/browse/MGPG-77 > Project: Maven GPG Plugin > Issue Type: Improvement >Affects Versions: 1.6 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.0.0 > > > in addition to classical upgrade of parent pom to version 34 and > project.build.outputTimestamp property addition, seems that > maven-shade-plugin creates noise that will require work -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MGPG-77) Make build Reproducible
[ https://issues.apache.org/jira/browse/MGPG-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036530#comment-17036530 ] Hudson commented on MGPG-77: Build succeeded in Jenkins: Maven TLP » maven-gpg-plugin » master #35 See https://builds.apache.org/job/maven-box/job/maven-gpg-plugin/job/master/35/ > Make build Reproducible > --- > > Key: MGPG-77 > URL: https://issues.apache.org/jira/browse/MGPG-77 > Project: Maven GPG Plugin > Issue Type: Improvement >Affects Versions: 1.6 >Reporter: Herve Boutemy >Priority: Major > Fix For: 3.0.0 > > > in addition to classical upgrade of parent pom to version 34 and > project.build.outputTimestamp property addition, seems that > maven-shade-plugin creates noise that will require work -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MPOM-240) upgrade maven-shade-plugin to 3.2.2 to get Reproducible Builds for shaded artifacts
[ https://issues.apache.org/jira/browse/MPOM-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036524#comment-17036524 ] Hudson commented on MPOM-240: - Build succeeded in Jenkins: Maven TLP » maven-apache-parent » master #49 See https://builds.apache.org/job/maven-box/job/maven-apache-parent/job/master/49/ > upgrade maven-shade-plugin to 3.2.2 to get Reproducible Builds for shaded > artifacts > --- > > Key: MPOM-240 > URL: https://issues.apache.org/jira/browse/MPOM-240 > Project: Maven POMs > Issue Type: Improvement > Components: asf >Affects Versions: ASF-23 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: ASF-24 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (DOXIA-606) fix javadoc issues with JDK 8 when generating documentation
[
https://issues.apache.org/jira/browse/DOXIA-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated DOXIA-606:
Description:
when building Doxia documentation with JDK 8:
{noformat}mvn -Preporting site site:stage{noformat}
some javadoc issues make site generation failure
I had to build Doxia 1.9.1 release documentation with JDK 7, even if I built
the artifacts with JDK 8...
for next release, it would be nice to not hit this issue any more
was:
when building Doxia documentation with JDK 8: {{{mvn -Preporting site
site:stage}}}
some javadoc issues make site generation failure
I had to build Doxia 1.9.1 release documentation with JDK 7, even if I built
the artifacts with JDK 8...
for next release, it would be nice to not hit this issue any more
> fix javadoc issues with JDK 8 when generating documentation
> ---
>
> Key: DOXIA-606
> URL: https://issues.apache.org/jira/browse/DOXIA-606
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Documentation
>Affects Versions: 1.9.1
>Reporter: Herve Boutemy
>Priority: Major
> Labels: up-for-grabs
>
> when building Doxia documentation with JDK 8:
> {noformat}mvn -Preporting site site:stage{noformat}
> some javadoc issues make site generation failure
> I had to build Doxia 1.9.1 release documentation with JDK 7, even if I built
> the artifacts with JDK 8...
> for next release, it would be nice to not hit this issue any more
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (DOXIA-606) fix javadoc issues with JDK 8 when generating documentation
[
https://issues.apache.org/jira/browse/DOXIA-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated DOXIA-606:
Fix Version/s: 1.9.2
> fix javadoc issues with JDK 8 when generating documentation
> ---
>
> Key: DOXIA-606
> URL: https://issues.apache.org/jira/browse/DOXIA-606
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Documentation
>Affects Versions: 1.9.1
>Reporter: Herve Boutemy
>Priority: Major
> Labels: up-for-grabs
> Fix For: 1.9.2
>
>
> when building Doxia documentation with JDK 8:
> {noformat}mvn -Preporting site site:stage{noformat}
> some javadoc issues make site generation failure
> I had to build Doxia 1.9.1 release documentation with JDK 7, even if I built
> the artifacts with JDK 8...
> for next release, it would be nice to not hit this issue any more
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (DOXIA-606) fix javadoc issues with JDK 8 when generating documentation
Herve Boutemy created DOXIA-606:
---
Summary: fix javadoc issues with JDK 8 when generating
documentation
Key: DOXIA-606
URL: https://issues.apache.org/jira/browse/DOXIA-606
Project: Maven Doxia
Issue Type: Improvement
Components: Documentation
Affects Versions: 1.9.1
Reporter: Herve Boutemy
when building Doxia documentation with JDK 8: {{{mvn -Preporting site
site:stage}}}
some javadoc issues make site generation failure
I had to build Doxia 1.9.1 release documentation with JDK 7, even if I built
the artifacts with JDK 8...
for next release, it would be nice to not hit this issue any more
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MPOM-240) upgrade maven-shade-plugin to 3.2.2 to get Reproducible Builds for shaded artifacts
[ https://issues.apache.org/jira/browse/MPOM-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MPOM-240: --- Summary: upgrade maven-shade-plugin to 3.2.2 to get Reproducible Builds for shaded artifacts (was: upgrade maven-shade-plugin to 3.2.2 to get Reproducible Build) > upgrade maven-shade-plugin to 3.2.2 to get Reproducible Builds for shaded > artifacts > --- > > Key: MPOM-240 > URL: https://issues.apache.org/jira/browse/MPOM-240 > Project: Maven POMs > Issue Type: Improvement > Components: asf >Affects Versions: ASF-23 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: ASF-24 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MPOM-240) upgrade maven-shade-plugin to 3.2.2 to get Reproducible Build
[ https://issues.apache.org/jira/browse/MPOM-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036517#comment-17036517 ] Hudson commented on MPOM-240: - Build succeeded in Jenkins: Maven TLP » maven-apache-parent » master #48 See https://builds.apache.org/job/maven-box/job/maven-apache-parent/job/master/48/ > upgrade maven-shade-plugin to 3.2.2 to get Reproducible Build > - > > Key: MPOM-240 > URL: https://issues.apache.org/jira/browse/MPOM-240 > Project: Maven POMs > Issue Type: Improvement > Components: asf >Affects Versions: ASF-23 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: ASF-24 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MPOM-240) upgrade maven-shade-plugin to 3.2.2 to get Reproducible Build
[ https://issues.apache.org/jira/browse/MPOM-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MPOM-240. -- Resolution: Fixed fixed in https://gitbox.apache.org/repos/asf?p=maven-apache-parent.git=commit=fb20a9fab563ca4a8a55070bf6f90f55f8795117 > upgrade maven-shade-plugin to 3.2.2 to get Reproducible Build > - > > Key: MPOM-240 > URL: https://issues.apache.org/jira/browse/MPOM-240 > Project: Maven POMs > Issue Type: Improvement > Components: asf >Affects Versions: ASF-23 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: ASF-24 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1751) Surefire report shows flaky tests as failures
[
https://issues.apache.org/jira/browse/SUREFIRE-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036515#comment-17036515
]
Tibor Digana commented on SUREFIRE-1751:
Alternatively, use your XML report, write a unit test passing that XML report
to the {{SurefireReportParser}} and build the test on expected assertions
statements. Call the method {{SurefireReportParser.parseXMLReportFiles()}} and
you should see the same result in the chart.
> Surefire report shows flaky tests as failures
> -
>
> Key: SUREFIRE-1751
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1751
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M4
>Reporter: Anu
>Priority: Critical
> Attachments: image-2020-02-13-11-41-03-906.png
>
>
> We have been using maven-surefire-plugin in 2.22.1 and Junit4.13 for our
> testing. Now we are trying to upgrade junit to junit5 and saw that the
> r{color:#6a8759}erunFailingTestsCount parameter isn't working with surefire
> plugin version. I upgraded surefire to 3.0.0.M4 and verified that the failing
> tests are now being retried. But the issue is flaky tests show up in the
> report as Failures.
> {color}
>
> {color:#6a8759}ie. the log shows
> {color}
> [WARNING] Tests run: 10455, Failures: 0, Errors: 0, Skipped: 993, Flakes: 10
>
> But the actual surefire report shows like below
> !image-2020-02-13-11-41-03-906.png!
>
> This is blocking our junit5 upgrade task. Can you please provide a fix for
> this at the earliest? Please let me know if you need anything else from me to
> help with the investigation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MPOM-240) upgrade maven-shade-plugin to 3.2.2 to get Reproducible Build
Herve Boutemy created MPOM-240: -- Summary: upgrade maven-shade-plugin to 3.2.2 to get Reproducible Build Key: MPOM-240 URL: https://issues.apache.org/jira/browse/MPOM-240 Project: Maven POMs Issue Type: Improvement Components: asf Affects Versions: ASF-23 Reporter: Herve Boutemy Assignee: Herve Boutemy Fix For: ASF-24 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1751) Surefire report shows flaky tests as failures
[
https://issues.apache.org/jira/browse/SUREFIRE-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036498#comment-17036498
]
Tibor Digana commented on SUREFIRE-1751:
[~anujose]
Can you attach a minimum project with necessary sources in a zip file?
> Surefire report shows flaky tests as failures
> -
>
> Key: SUREFIRE-1751
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1751
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M4
>Reporter: Anu
>Priority: Critical
> Attachments: image-2020-02-13-11-41-03-906.png
>
>
> We have been using maven-surefire-plugin in 2.22.1 and Junit4.13 for our
> testing. Now we are trying to upgrade junit to junit5 and saw that the
> r{color:#6a8759}erunFailingTestsCount parameter isn't working with surefire
> plugin version. I upgraded surefire to 3.0.0.M4 and verified that the failing
> tests are now being retried. But the issue is flaky tests show up in the
> report as Failures.
> {color}
>
> {color:#6a8759}ie. the log shows
> {color}
> [WARNING] Tests run: 10455, Failures: 0, Errors: 0, Skipped: 993, Flakes: 10
>
> But the actual surefire report shows like below
> !image-2020-02-13-11-41-03-906.png!
>
> This is blocking our junit5 upgrade task. Can you please provide a fix for
> this at the earliest? Please let me know if you need anything else from me to
> help with the investigation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (DOXIA-540) Update/remove ancient information on Doxia site
[ https://issues.apache.org/jira/browse/DOXIA-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated DOXIA-540: Affects Version/s: (was: 1.7) > Update/remove ancient information on Doxia site > --- > > Key: DOXIA-540 > URL: https://issues.apache.org/jira/browse/DOXIA-540 > Project: Maven Doxia > Issue Type: Task > Components: Documentation >Reporter: Michael Osipov >Priority: Major > Labels: up-for-grabs > Time Spent: 10m > Remaining Estimate: 0h > > Tasks to perform: > * Remove [Developer Docs|http://maven.apache.org/doxia/] for ancient versions. > * Remove Doxia IDE intergration is there is none working > * Remove [Upgrading|http://maven.apache.org/doxia/upgrading.html], it is > overhauled. > * Check [FAQ|http://maven.apache.org/doxia/faq.html] for validity. > * Merge [Apt > Enhancements|http://maven.apache.org/doxia/references/doxia-apt.html] into > [main site|http://maven.apache.org/doxia/references/apt-format.html]. > * Check [Issues|http://maven.apache.org/doxia/issues/index.html] for > validity. > * Update [External Resources|http://maven.apache.org/doxia/resources.html]. > * Remove ancient information from [Sink > API|http://maven.apache.org/doxia/doxia/doxia-sink-api/index.html]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (DOXIA-521) Markdown: Allow using the standard "" for code blocks
[ https://issues.apache.org/jira/browse/DOXIA-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated DOXIA-521: Affects Version/s: 1.9 > Markdown: Allow using the standard "" for code blocks > > > Key: DOXIA-521 > URL: https://issues.apache.org/jira/browse/DOXIA-521 > Project: Maven Doxia > Issue Type: Improvement > Components: Module - Markdown >Affects Versions: 1.6, 1.9 >Reporter: Santiago M. Mola >Priority: Major > > Pegdown, as well as other Markdown parsers, translates code blocks to > . This is the standard as per the Markdown specifications and both > themes and tools (e.g. http://highlightjs.org/) rely on this syntax. > However, the doxia markdown module overrides this behaviour and uses " class="source">. It would be nice to revert the default behaviour to the > standard. If there are use cases for such an alternative syntax, it could be > provided as an option. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (DOXIA-571) Markdown does not support syntax highlighting any more
[
https://issues.apache.org/jira/browse/DOXIA-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed DOXIA-571.
---
Fix Version/s: 1.9.1
Assignee: Herve Boutemy (was: Sylwester Lachiewicz)
Resolution: Fixed
fixed in
https://github.com/apache/maven-doxia/commit/99f54508109723995c8587a1b574e0a9aa56ce09
> Markdown does not support syntax highlighting any more
> --
>
> Key: DOXIA-571
> URL: https://issues.apache.org/jira/browse/DOXIA-571
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 1.8
>Reporter: Richard Körber
>Assignee: Herve Boutemy
>Priority: Minor
> Fix For: 1.9.1
>
>
> Starting with version 1.8, doxia-module-markdown changed from Pegdown to
> Flexmark.
> However it seems that Flexmark does not support syntax highlighting.
> Example:
> {noformat}
> ```java
> System.out.println("Hello World!");
> ```
> {noformat}
> doxia-module-markdown < 1.8 applied Java syntax highlighting here.
> doxia-module-markdown 1.8 does not. As doxia-module-markdown is used mostly
> for technical documentation in maven, I think this is a major regression.
> Possible workaround: Use doxia-module-markdown 1.7.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (DOXIA-605) Inline code elements in Markdown disappear in output
[
https://issues.apache.org/jira/browse/DOXIA-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed DOXIA-605.
---
Fix Version/s: 1.9.1
Assignee: Herve Boutemy
Resolution: Duplicate
> Inline code elements in Markdown disappear in output
>
>
> Key: DOXIA-605
> URL: https://issues.apache.org/jira/browse/DOXIA-605
> Project: Maven Doxia
> Issue Type: Bug
> Components: Module - Markdown
>Affects Versions: 1.9
>Reporter: Robert Casties
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 1.9.1
>
>
> Markdown inline code elements marked by single or double ` (backquote) appear
> as normal text in the HTML output (no markup at all).
> Only code blocks with triple-backquote appear in HTML output.
> I created a public example in
> [https://github.com/robcast/doxia-markdown-code-test]
> I also tried to debug the processing using
> {{[saveProcessedContent|https://maven.apache.org/plugins/maven-site-plugin/site-mojo.html#saveProcessedContent]}}
> but no "processed" directory was created. Did I do it wrong?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MNG-6864) Malformed --> Invalid error message
Elliotte Rusty Harold created MNG-6864: -- Summary: Malformed --> Invalid error message Key: MNG-6864 URL: https://issues.apache.org/jira/browse/MNG-6864 Project: Maven Issue Type: Bug Reporter: Elliotte Rusty Harold Recently got this error messge: [INFO] Scanning for projects... [ERROR] [ERROR] Some problems were encountered while processing the POMs: [ERROR] Malformed POM /home/elharo/java-docs-samples/storage/space/debugstorage/pom.xml: Unrecognised tag: 'project' (position: START_TAG seen ...\n \n ... @33:14) @ /home/elharo/java-docs-samples/storage/space/debugstorage/pom.xml, line 33, column 14 The error message was mostly correct. I had some elements where they weren't supposed to be. However the POM was well-formed as all tags balanced. It was invalid–not malformed–because the tags weren't where they should be. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SUREFIRE-1751) Surefire report shows flaky tests as failures
Anu created SUREFIRE-1751:
-
Summary: Surefire report shows flaky tests as failures
Key: SUREFIRE-1751
URL: https://issues.apache.org/jira/browse/SUREFIRE-1751
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 3.0.0-M4
Reporter: Anu
Attachments: image-2020-02-13-11-41-03-906.png
We have been using maven-surefire-plugin in 2.22.1 and Junit4.13 for our
testing. Now we are trying to upgrade junit to junit5 and saw that the
r{color:#6a8759}erunFailingTestsCount parameter isn't working with surefire
plugin version. I upgraded surefire to 3.0.0.M4 and verified that the failing
tests are now being retried. But the issue is flaky tests show up in the report
as Failures.
{color}
{color:#6a8759}ie. the log shows
{color}
[WARNING] Tests run: 10455, Failures: 0, Errors: 0, Skipped: 993, Flakes: 10
But the actual surefire report shows like below
!image-2020-02-13-11-41-03-906.png!
This is blocking our junit5 upgrade task. Can you please provide a fix for this
at the earliest? Please let me know if you need anything else from me to help
with the investigation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-306) Log all duplicates, not only classes
[
https://issues.apache.org/jira/browse/MSHADE-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036072#comment-17036072
]
Piotr Zygielo commented on MSHADE-306:
--
[~romain.manni-bucau]-
{quote}did you try configuring includes/excludes in the filters of the shade
configuration [1] ?
{quote}
Not before. Now I tried. Yes, yes it works very, very fine. (A bit
verbose/explicit but workable result.)
Thank you! (*)
(ashamed), I should've read more...
> Log all duplicates, not only classes
>
>
> Key: MSHADE-306
> URL: https://issues.apache.org/jira/browse/MSHADE-306
> Project: Maven Shade Plugin
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 3.2.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Issue to silently swallow duplicated resources is that you don't see, even in
> debug, that there is a choice done by the plugin. This breaks the final app
> in a lot of cases (all SPI-like cases, OSGi for the MANIFEST.MF etc...). So
> let's log it as for classes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-306) Log all duplicates, not only classes
[ https://issues.apache.org/jira/browse/MSHADE-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036041#comment-17036041 ] Romain Manni-Bucau commented on MSHADE-306: --- Hi [~pzygielo], did you try configuring includes/excludes in the filters of the shade configuration [1] ? [1] [http://maven.apache.org/plugins/maven-shade-plugin/examples/includes-excludes.html] > Log all duplicates, not only classes > > > Key: MSHADE-306 > URL: https://issues.apache.org/jira/browse/MSHADE-306 > Project: Maven Shade Plugin > Issue Type: New Feature >Reporter: Romain Manni-Bucau >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 3.2.2 > > Time Spent: 20m > Remaining Estimate: 0h > > Issue to silently swallow duplicated resources is that you don't see, even in > debug, that there is a choice done by the plugin. This breaks the final app > in a lot of cases (all SPI-like cases, OSGi for the MANIFEST.MF etc...). So > let's log it as for classes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MSHADE-306) Log all duplicates, not only classes
[
https://issues.apache.org/jira/browse/MSHADE-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17035972#comment-17035972
]
Piotr Zygielo edited comment on MSHADE-306 at 2/13/20 8:47 AM:
---
On just released 3.2.2 - How can I not have warning for
{code:bash}
[WARNING] [... jars listed..] define 1 overlapping resources:
[WARNING] - META-INF/MANIFEST.MF
[WARNING] maven-shade-plugin has detected that some class files are
[WARNING] present in two or more JARs. When this happens, only one
[WARNING] single version of the class is copied to the uber jar.
[WARNING] Usually this is not harmful and you can skip these warnings,
[WARNING] otherwise try to manually exclude artifacts based on
[WARNING] mvn dependency:tree -Ddetail=true and the above output.
[WARNING] See [http://maven.apache.org/plugins/maven-shade-plugin/]
{code}
-Probably
[ManifestResourceTransformer|http://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html#ManifestResourceTransformer]
to help.-
-1. I'd expect that MANIFEST.MFs are present in several jars. Does is mean that
warning will be issued for almost every case of plugin usage?-
-I see in
[DefaultShaderTest.java#L123|https://github.com/apache/maven-shade-plugin/blob/5894a4d7ca4e34ed85a310f57e81fa2812e4f3af/src/test/java/org/apache/maven/plugins/shade/DefaultShaderTest.java#L123]
exactly that is tested. Is that really as intended?-
Hmm... Now I see - "so even this should be logged". So effectively - using
shade plugin - one will almost always end up with warning to be fixed.
2. I'd like the message to at least include 'or resources' in 'has detected
that some class files'.
—
I'm sorry for the noise (just confused by new warning appearing in log with
plugin upgrade).
was (Author: pzygielo):
-On just released 3.2.2 - How can I not have warning for-
{code:bash}
[WARNING] [... jars listed..] define 1 overlapping resources:
[WARNING] - META-INF/MANIFEST.MF
[WARNING] maven-shade-plugin has detected that some class files are
[WARNING] present in two or more JARs. When this happens, only one
[WARNING] single version of the class is copied to the uber jar.
[WARNING] Usually this is not harmful and you can skip these warnings,
[WARNING] otherwise try to manually exclude artifacts based on
[WARNING] mvn dependency:tree -Ddetail=true and the above output.
[WARNING] See [http://maven.apache.org/plugins/maven-shade-plugin/]
{code}
Probably
[ManifestResourceTransformer|http://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html#ManifestResourceTransformer]
to help.
-1. I'd expect that MANIFEST.MFs are present in several jars. Does is mean
that warning will be issued for almost every case of plugin usage?-
-I see in
[DefaultShaderTest.java#L123|https://github.com/apache/maven-shade-plugin/blob/5894a4d7ca4e34ed85a310f57e81fa2812e4f3af/src/test/java/org/apache/maven/plugins/shade/DefaultShaderTest.java#L123]
exactly that is tested. Is that really as intended?-
Hmm... Now I see - "so even this should be logged". So effectively - using
shade plugin - one will almost always end up with warning to be fixed.
2. I'd like the message to at least include 'or resources' in 'has detected
that some class files'.
---
I'm sorry for the noise (just confused by new warning appearing in log with
plugin upgrade).
> Log all duplicates, not only classes
>
>
> Key: MSHADE-306
> URL: https://issues.apache.org/jira/browse/MSHADE-306
> Project: Maven Shade Plugin
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: 3.2.2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Issue to silently swallow duplicated resources is that you don't see, even in
> debug, that there is a choice done by the plugin. This breaks the final app
> in a lot of cases (all SPI-like cases, OSGi for the MANIFEST.MF etc...). So
> let's log it as for classes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
