[jira] [Commented] (MNG-8258) activate Reproducible Builds by default
[
https://issues.apache.org/jira/browse/MNG-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888512#comment-17888512
]
ASF GitHub Bot commented on MNG-8258:
-
hboutemy merged PR #563:
URL: https://github.com/apache/maven-site/pull/563
> activate Reproducible Builds by default
> ---
>
> Key: MNG-8258
> URL: https://issues.apache.org/jira/browse/MNG-8258
> Project: Maven
> Issue Type: New Feature
> Components: Core
>Affects Versions: 3.9.9, 4.0.0-beta-4
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.9.x-candidate, 4.0.0-beta-5
>
>
> Reproducible Builds is a good practice that is easy to enable: it would be
> nice to enable it by default, and have projects
> - either disable it
> ({{x}}) if
> they really have a problem with the default Reproducible behaviour
> - or customize locally the value of the default Maven core-provided
> timestamp, to have a project-specific value
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8258) activate Reproducible Builds by default
[
https://issues.apache.org/jira/browse/MNG-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888511#comment-17888511
]
ASF GitHub Bot commented on MNG-8258:
-
hboutemy opened a new pull request, #563:
URL: https://github.com/apache/maven-site/pull/563
(no comment)
> activate Reproducible Builds by default
> ---
>
> Key: MNG-8258
> URL: https://issues.apache.org/jira/browse/MNG-8258
> Project: Maven
> Issue Type: New Feature
> Components: Core
>Affects Versions: 3.9.9, 4.0.0-beta-4
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.9.x-candidate, 4.0.0-beta-5
>
>
> Reproducible Builds is a good practice that is easy to enable: it would be
> nice to enable it by default, and have projects
> - either disable it
> ({{x}}) if
> they really have a problem with the default Reproducible behaviour
> - or customize locally the value of the default Maven core-provided
> timestamp, to have a project-specific value
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8258) activate Reproducible Builds by default
[
https://issues.apache.org/jira/browse/MNG-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-8258:
---
Fix Version/s: 3.9.x-candidate
> activate Reproducible Builds by default
> ---
>
> Key: MNG-8258
> URL: https://issues.apache.org/jira/browse/MNG-8258
> Project: Maven
> Issue Type: New Feature
> Components: Core
>Affects Versions: 3.9.9, 4.0.0-beta-4
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.9.x-candidate, 4.0.0-beta-5
>
>
> Reproducible Builds is a good practice that is easy to enable: it would be
> nice to enable it by default, and have projects
> - either disable it
> ({{x}}) if
> they really have a problem with the default Reproducible behaviour
> - or customize locally the value of the default Maven core-provided
> timestamp, to have a project-specific value
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-8258] Maven 4 beta 5 provides default inherited value [maven-site]
hboutemy merged PR #563: URL: https://github.com/apache/maven-site/pull/563 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] [MNG-8258] Maven 4 beta 5 provides default inherited value [maven-site]
hboutemy opened a new pull request, #563: URL: https://github.com/apache/maven-site/pull/563 (no comment) -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MSHARED-1438) Resolve Code Duplication for XRef Link generation
[ https://issues.apache.org/jira/browse/MSHARED-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888533#comment-17888533 ] ASF GitHub Bot commented on MSHARED-1438: - michael-o commented on PR #56: URL: https://github.com/apache/maven-reporting-impl/pull/56#issuecomment-2406661820 Misses docs and can be simplified. > Resolve Code Duplication for XRef Link generation > - > > Key: MSHARED-1438 > URL: https://issues.apache.org/jira/browse/MSHARED-1438 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-reporting-impl >Affects Versions: maven-reporting-impl-4.0.0-M15 >Reporter: Andreas Dangel >Assignee: Michael Osipov >Priority: Major > Fix For: maven-reporting-impl-4.0.0 > > > PMD, Checkstyle and Surefire all have the same code to determine the xref > code location for reporting and linking to the source code. > See MPMD-128 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHARED-1430) Use a predefined constant for project.build.outputTimestamp
[
https://issues.apache.org/jira/browse/MSHARED-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MSHARED-1430.
--
Resolution: Won't Fix
> Use a predefined constant for project.build.outputTimestamp
> ---
>
> Key: MSHARED-1430
> URL: https://issues.apache.org/jira/browse/MSHARED-1430
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Reporter: Sergey Ponomarev
>Priority: Minor
>
> The "Configuring for Reproducible Builds" guide shows and example how to
> specify a static outputTimestamp:
>
> 2023-01-01T00:00:00Z
> The date inside is really doesn't matter and I used the property as is but
> was afraid of being asked on a review why the 2023 year was used so used the
> current year.
> But still during a review I was asked:
> bq. these changes are likely going to confuse future developers ("This date
> shouldn't be static! Lets make it a variable!").
> The Gradle has an option preserveFileTimestamps = false that will just put 1
> Feb 1980 as a date. The 1 Jan 1980 is a minimal date in Zip archive but the 1
> Jan has some special treatment by Java that's why the Gradle team used the 1
> Feb.
> See more detailed description in CONSTANT_TIME_FOR_ZIP_ENTRIES
> https://github.com/gradle/gradle/blob/master/platforms/core-runtime/files/src/main/java/org/gradle/api/internal/file/archive/ZipEntryConstants.java#L39
> I don't think it worth to declare some new property e.g.
> true
> But we can simply make a special constant value like:
>
> REPRODUCIBLE_BUILD_STATIC_DATE
> Then the constant will be replaced with the same 1 Feb 1980 to be similar
> with Gradle produced artifacts.
> This constant should make it more clear intention of the outputTimestamp but
> also easier to find an explanation for this.
> The outputTimestamp parsing is performed in the maven-archiver but the
> maven-compiler-plugin and maven-jar-plugin would need to update a JavaDoc for
> the outputTimestamp config option
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1430) Use a predefined constant for project.build.outputTimestamp
[
https://issues.apache.org/jira/browse/MSHARED-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888508#comment-17888508
]
Herve Boutemy commented on MSHARED-1430:
thank you Sergey
if you are interested into Reproducible Builds, help welcome to
https://github.com/jvm-repo-rebuild/reproducible-central = checking success at
third-party rebuilding: a lot has been done with projects using Maven, still
need help on Gradle
> Use a predefined constant for project.build.outputTimestamp
> ---
>
> Key: MSHARED-1430
> URL: https://issues.apache.org/jira/browse/MSHARED-1430
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Reporter: Sergey Ponomarev
>Priority: Minor
>
> The "Configuring for Reproducible Builds" guide shows and example how to
> specify a static outputTimestamp:
>
> 2023-01-01T00:00:00Z
> The date inside is really doesn't matter and I used the property as is but
> was afraid of being asked on a review why the 2023 year was used so used the
> current year.
> But still during a review I was asked:
> bq. these changes are likely going to confuse future developers ("This date
> shouldn't be static! Lets make it a variable!").
> The Gradle has an option preserveFileTimestamps = false that will just put 1
> Feb 1980 as a date. The 1 Jan 1980 is a minimal date in Zip archive but the 1
> Jan has some special treatment by Java that's why the Gradle team used the 1
> Feb.
> See more detailed description in CONSTANT_TIME_FOR_ZIP_ENTRIES
> https://github.com/gradle/gradle/blob/master/platforms/core-runtime/files/src/main/java/org/gradle/api/internal/file/archive/ZipEntryConstants.java#L39
> I don't think it worth to declare some new property e.g.
> true
> But we can simply make a special constant value like:
>
> REPRODUCIBLE_BUILD_STATIC_DATE
> Then the constant will be replaced with the same 1 Feb 1980 to be similar
> with Gradle produced artifacts.
> This constant should make it more clear intention of the outputTimestamp but
> also easier to find an explanation for this.
> The outputTimestamp parsing is performed in the maven-archiver but the
> maven-compiler-plugin and maven-jar-plugin would need to update a JavaDoc for
> the outputTimestamp config option
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MJAR-314) Use a predefined constant for project.build.outputTimestamp
[
https://issues.apache.org/jira/browse/MJAR-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MJAR-314.
--
Resolution: Won't Fix
> Use a predefined constant for project.build.outputTimestamp
> ---
>
> Key: MJAR-314
> URL: https://issues.apache.org/jira/browse/MJAR-314
> Project: Maven JAR Plugin
> Issue Type: Improvement
>Reporter: Sergey Ponomarev
>Priority: Major
>
> The "Configuring for Reproducible Builds" guide shows and example how to
> specify a static outputTimestamp:
>
> 2023-01-01T00:00:00Z
> The date inside is really doesn't matter and I used the property as is but
> was afraid of being asked on a review why the 2023 year was used so used the
> current year.
> But still during a review I was asked:
> bq. these changes are likely going to confuse future developers ("This date
> shouldn't be static! Lets make it a variable!").
> The Gradle has an option preserveFileTimestamps = false that will just put 1
> Feb 1980 as a date. The 1 Jan 1980 is a minimal date in Zip archive but the 1
> Jan has some special treatment by Java that's why the Gradle team used the 1
> Feb.
> See more detailed description in CONSTANT_TIME_FOR_ZIP_ENTRIES
> https://github.com/gradle/gradle/blob/master/platforms/core-runtime/files/src/main/java/org/gradle/api/internal/file/archive/ZipEntryConstants.java#L39
> I don't think it worth to declare some new property e.g.
> true
> But we can simply make a special constant value like:
>
> REPRODUCIBLE_BUILD_STATIC_DATE
> Then the constant will be replaced with the same 1 Feb 1980 to be similar
> with Gradle produced artifacts.
> This constant should make it more clear intention of the outputTimestamp but
> also easier to find an explanation for this.
> The outputTimestamp parsing is performed in the maven-archiver but the
> maven-compiler-plugin and maven-jar-plugin would need to update a JavaDoc for
> the outputTimestamp config option
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MCOMPILER-600) Use a predefined constant for project.build.outputTimestamp
[
https://issues.apache.org/jira/browse/MCOMPILER-600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MCOMPILER-600.
---
Resolution: Won't Fix
> Use a predefined constant for project.build.outputTimestamp
> ---
>
> Key: MCOMPILER-600
> URL: https://issues.apache.org/jira/browse/MCOMPILER-600
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Sergey Ponomarev
>Priority: Minor
>
> The "Configuring for Reproducible Builds" guide shows and example how to
> specify a static outputTimestamp:
>
> 2023-01-01T00:00:00Z
> The date inside is really doesn't matter and I used the property as is but
> was afraid of being asked on a review why the 2023 year was used so used the
> current year.
> But still during a review I was asked:
> bq. these changes are likely going to confuse future developers ("This date
> shouldn't be static! Lets make it a variable!").
> The Gradle has an option preserveFileTimestamps = false that will just put 1
> Feb 1980 as a date. The 1 Jan 1980 is a minimal date in Zip archive but the 1
> Jan has some special treatment by Java that's why the Gradle team used the 1
> Feb.
> See more detailed description in CONSTANT_TIME_FOR_ZIP_ENTRIES
> https://github.com/gradle/gradle/blob/master/platforms/core-runtime/files/src/main/java/org/gradle/api/internal/file/archive/ZipEntryConstants.java#L39
> I don't think it worth to declare some new property e.g.
> true
> But we can simply make a special constant value like:
>
> REPRODUCIBLE_BUILD_STATIC_DATE
> Then the constant will be replaced with the same 1 Feb 1980 to be similar
> with Gradle produced artifacts.
> This constant should make it more clear intention of the outputTimestamp but
> also easier to find an explanation for this.
> The outputTimestamp parsing is performed in the maven-archiver but the
> maven-compiler-plugin and maven-jar-plugin would need to update a JavaDoc for
> the outputTimestamp config option
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [SUREFIRE-2276] - Fix for retries of JUnit TestTemplate tests [maven-surefire]
hubertgrzeskowiak commented on PR #788: URL: https://github.com/apache/maven-surefire/pull/788#issuecomment-2406519097 Sorry for the delay. I had some trouble with the `animal-sniffer` plugin locally, but it seems to be working now. Would you mind re-running CI? -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MNG-8300) [REGRESSION] colorized transfer messages broken
Herve Boutemy created MNG-8300: -- Summary: [REGRESSION] colorized transfer messages broken Key: MNG-8300 URL: https://issues.apache.org/jira/browse/MNG-8300 Project: Maven Issue Type: Bug Affects Versions: 4.0.0-beta-4, 4.0.0-alpha-12 Reporter: Herve Boutemy Fix For: 4.0.0-beta-5 colorized transfer messages implemented in Maven 4.0.0-alpha-8 in MNG-7875 but it seems MNG-7995 in Maven 4.0.0-alpha-11 broke it, and went unnoticed until now 4.0.0-beta-4 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump org.slf4j:slf4j-simple from 1.7.36 to 2.0.16 [maven-project-info-reports-plugin]
dependabot[bot] commented on PR #86: URL: https://github.com/apache/maven-project-info-reports-plugin/pull/86#issuecomment-2406613964 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.slf4j:slf4j-simple from 1.7.36 to 2.0.16 [maven-project-info-reports-plugin]
slachiewicz closed pull request #86: Bump org.slf4j:slf4j-simple from 1.7.36 to 2.0.16 URL: https://github.com/apache/maven-project-info-reports-plugin/pull/86 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] [SUREFIRE-2277] Fix bug in RunResult serialisation/deserialisation to (from) failsafe-summary.xml [maven-surefire]
bingx1 opened a new pull request, #790: URL: https://github.com/apache/maven-surefire/pull/790 This PR fixes the bug described in https://issues.apache.org/jira/browse/SUREFIRE-2277 **Problem** There is a bug in `RunResult.testAppendSerialization`. This test creates a `RunResult` object in-memory, serialises it, writes it to disk and then again deserialises the same file into a `RunResult` in-memory. I have run the test with the debugger and found that the final in-memory `RunResult` object is not the same as the initial one. It shouldn't be passing on master, but is due to a bug in the `RunResult.equals` method which is used in an assertion in the test. The source of the bug is that the value of `RunResult.flakes` isn't preserved during serialisation to and from `failsafe-summary.xml`. The bug is slipping through and the test passes because the `RunResult.equals` method doesn't consider the `RunResult.flakes` field. **Fix** I have modified the `failsafe-summary.xsd` to include an _optional_ `` element, which will allow `RunResult.flakes` to be persisted in the `failsafe-summary.xml` during serialisation. I have also changed the serialisation and deserialisation methods for `RunResult` to account for `flakes`. I have also added a test, `RunResultTest.testLegacyDeserialization` for backwards compatibility. It tests that deserialising a legacy `failsafe-summary.xml` still works. The behaviour is that when the `flakes` XML element is not present in the `failsafe-summary.xml`, the in-memory `RunResult` will have `RunResult.flakes` set to 0 after deserialisation. - 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/SUREFIRE) 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 `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-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 install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean install`). 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). Our company, Atlassian, has a corporate CLA signed, and we added our team to it. Contributors: Alex Courtis, Bing Xu and Hubert Grzeskowiak -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7875) colorize transfer messages
[
https://issues.apache.org/jira/browse/MNG-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888520#comment-17888520
]
Herve Boutemy commented on MNG-7875:
and for Maven 4
https://github.com/apache/maven/commit/25488f923131155de58a88fdf712871a500bdb90
> colorize transfer messages
> --
>
> Key: MNG-7875
> URL: https://issues.apache.org/jira/browse/MNG-7875
> Project: Maven
> Issue Type: Improvement
> Components: Embedding
>Affects Versions: 3.9.4
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.8.9, 3.9.5, 4.0.0-alpha-8, 4.0.0
>
> Attachments: MNG-7875_before_output.png,
> MNG-7875_colorized_output.png, MNG-7875_colorized_output_second.png
>
>
> transfer message are currently hard to read for many users
> {noformat}
> Downloading from apache.snapshots:
> https://repository.apache.org/snapshots/org/apache/maven/doxia/doxia-decoration-model/1.11.1/doxia-decoration-model-1.11.1.pom
> Downloading from central:
> https://repo.maven.apache.org/maven2/org/apache/maven/doxia/doxia-decoration-model/1.11.1/doxia-decoration-model-1.11.1.pom
> Downloaded from central:
> https://repo.maven.apache.org/maven2/org/apache/maven/doxia/doxia-decoration-model/1.11.1/doxia-decoration-model-1.11.1.pom
> (3.4 kB at 851 kB/s)
> D
> {noformat}
> - it's interweaved into normal build messages
> - users don't really see the difference between "Downloading" (transfert
> started, may eventually fail with 404) and "Downloaded" (done successfully)
> - repository id is not so visible in the middle of the message
> - the download url has much info in it to see: base url, groupId as
> directory, artifactId, version, and filename
> adding darker color to "hide" less important info will help output reading
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Moved] (MCHANGES-423) Rendering table in section from changes-report
[
https://issues.apache.org/jira/browse/MCHANGES-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov moved MSKINS-254 to MCHANGES-423:
Component/s: (was: Fluido Skin)
Key: MCHANGES-423 (was: MSKINS-254)
Affects Version/s: 2.12.1
(was: fluido-2.0.0-M9)
(was: fluido-2.0.0-M11)
Project: Maven Changes Plugin (was: Maven Skins)
> Rendering table in section from changes-report
> --
>
> Key: MCHANGES-423
> URL: https://issues.apache.org/jira/browse/MCHANGES-423
> Project: Maven Changes Plugin
> Issue Type: Bug
>Affects Versions: 2.12.1
>Reporter: Georg Kallidis
>Priority: Major
>
> When running in a project with src/changes/changes.xml
> {code:sh}
> mvn changes:changes-report
> {code}
> does generate correct html code
> {code:html}
>
>
>
> Release-Geschichte
>
>
> Version
> ..
> {code}
> but when running
> {code:sh}
> mvn site
> {code}
> the result is missing the table element after the section element.
> {code:html}
>
> ..
>
>
>
> Changes
> Release History
>
> Version
> Date
> Description
>
> ..
> ..
> {code}
> Though I only checked that in maven-fluido-skin resources/META-INF/site.vm
> *$bodyColumn* {*}already contains the wrong body content missing the table
> element{*}.
> I am currently unable to understand exactly the mechanism, where the
> transformation comes from doxia site tool and which template are used get
> this done.
> Is it a fluido skin ( 2.0.0-M9 or 2.0.0-M11 does makes no difference) or
> does it happen still more upstreams?
> It might be doxia tools ..
>
> Example changes.xml:
> {code:xml}
>
>
> Changes
>
>
>
> bar
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCHANGES-423) Rendering table in section from changes-report
[
https://issues.apache.org/jira/browse/MCHANGES-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888249#comment-17888249
]
Michael Osipov commented on MCHANGES-423:
-
Please read: https://lists.apache.org/thread/pgj1gd75hx1dhq9spnl3c70xxt07corx
You can fix it inline with the Maven Antrun Plugin for the time being.
[~ggregory]
> Rendering table in section from changes-report
> --
>
> Key: MCHANGES-423
> URL: https://issues.apache.org/jira/browse/MCHANGES-423
> Project: Maven Changes Plugin
> Issue Type: Bug
>Affects Versions: 2.12.1
>Reporter: Georg Kallidis
>Priority: Major
>
> When running in a project with src/changes/changes.xml
> {code:sh}
> mvn changes:changes-report
> {code}
> does generate correct html code
> {code:html}
>
>
>
> Release-Geschichte
>
>
> Version
> ..
> {code}
> but when running
> {code:sh}
> mvn site
> {code}
> the result is missing the table element after the section element.
> {code:html}
>
> ..
>
>
>
> Changes
> Release History
>
> Version
> Date
> Description
>
> ..
> ..
> {code}
> Though I only checked that in maven-fluido-skin resources/META-INF/site.vm
> *$bodyColumn* {*}already contains the wrong body content missing the table
> element{*}.
> I am currently unable to understand exactly the mechanism, where the
> transformation comes from doxia site tool and which template are used get
> this done.
> Is it a fluido skin ( 2.0.0-M9 or 2.0.0-M11 does makes no difference) or
> does it happen still more upstreams?
> It might be doxia tools ..
>
> Example changes.xml:
> {code:xml}
>
>
> Changes
>
>
>
> bar
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MDEPLOY-323) Same Bug as described in MINSTALL-160
[ https://issues.apache.org/jira/browse/MDEPLOY-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882629#comment-17882629 ] Claus Köll edited comment on MDEPLOY-323 at 10/10/24 11:39 AM: --- [~khmarbaise] We have tried with the neweset version but there is still the problem that it does not generate a own pom.xml file was (Author: c_koell): We have tried with the neweset version but there is still the problem that it does not take the own pom.xml file > Same Bug as described in MINSTALL-160 > - > > Key: MDEPLOY-323 > URL: https://issues.apache.org/jira/browse/MDEPLOY-323 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 3.0.0-M1 >Reporter: Claus Köll >Priority: Major > > We see the same problem as described in MINSTALL-160. > Is it possible that you fix it also in MDEPLOY please .. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8299) Maven 4 reverses custom lifecycle ordering
Stefan Oehme created MNG-8299:
-
Summary: Maven 4 reverses custom lifecycle ordering
Key: MNG-8299
URL: https://issues.apache.org/jira/browse/MNG-8299
Project: Maven
Issue Type: Bug
Components: Core
Affects Versions: 4.0.x-candidate
Reporter: Stefan Oehme
Following this tutorial:
[https://nextmetaphor.wordpress.com/2016/10/10/custom-maven-lifecycle/]
On Maven 3.x, if you run `mvn phase3` on the project, it correctly runs phase 1
and 2 first and outputs
{code:java}
[INFO] Doing Phase 1 stuff. {code}
On the 4.x nightlies, running the same command no longer runs phase 1 or 2. It
looks like the order of phases is reversed. This happened after
[https://github.com/apache/maven/pull/1448] was merged I think.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-8052] New lifecycle for Maven 4 [maven]
oehme commented on PR #1448: URL: https://github.com/apache/maven/pull/1448#issuecomment-2405069107 https://issues.apache.org/jira/browse/MNG-8299 Also opened two for other recent regressions: https://issues.apache.org/jira/browse/MNG-8297 https://issues.apache.org/jira/browse/MNG-8298 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump net.bytebuddy:byte-buddy from 1.14.18 to 1.15.3 [maven-plugin-tools]
dependabot[bot] commented on PR #329: URL: https://github.com/apache/maven-plugin-tools/pull/329#issuecomment-2405080083 Superseded by #331. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Bump net.bytebuddy:byte-buddy from 1.14.18 to 1.15.4 [maven-plugin-tools]
dependabot[bot] opened a new pull request, #331: URL: https://github.com/apache/maven-plugin-tools/pull/331 Bumps [net.bytebuddy:byte-buddy](https://github.com/raphw/byte-buddy) from 1.14.18 to 1.15.4. Release notes Sourced from https://github.com/raphw/byte-buddy/releases";>net.bytebuddy:byte-buddy's releases. Byte Buddy 1.15.4 Add non-experimental support for Java 24. Byte Buddy 1.15.3 Treat multi-release class files that are newer than the supported version as regular resources. Allow overriding the multi-release class file version from Maven and Gradle plugin. Correctly resolve multi-release class files in Android. Byte Buddy 1.15.2 Add support for multi-release JAR files in ClassFileLocators and Plugin.Engine.Default. Add Gradle task for transforming multiple jar files with ByteBuddyJarsTask. Avoid validation of JarFile when extracting individual entries. Rework discovery in ByteBuddyMojo. Byte Buddy 1.15.1 Revert default EntryPoint for Android Gradle plugin to use DECORATE unless explicitly specified due to many generic type errors in Kotlin classes. Byte Buddy 1.15.0 Introduce AsmClassWriter and AsmClassReader abstractions that allow for plugging different implementations of readers and writers. Add configuration extension to the Android Gradle plugin and make it behave like regular Gradle plugin with standard configuration. Throw TypeNotPresentException upon discovering undeclared type variables as it was recently fixed on the JVM. byte-buddy-1.14.19 Add Maven Mojo for transforming jars and for transforming dependencies folder. Better error handling for unresolved type variables. Allow loading arguments of the instrumented method in MemberSubstitution. Fix checks for method visibility. Changelog Sourced from https://github.com/raphw/byte-buddy/blob/master/release-notes.md";>net.bytebuddy:byte-buddy's changelog. 9. October 2024: version 1.15.4 Add non-experimental support for Java 24. 26. September 2024: version 1.15.3 Treat multi-release class files that are newer than the supported version as regular resources. Allow overriding the multi-release class file version from Maven and Gradle plugin. Correctly resolve multi-release class files in Android. 25. September 2024: version 1.15.2 Add support for multi-release JAR files in ClassFileLocators and Plugin.Engine.Default. Add Gradle task for transforming multiple jar files with ByteBuddyJarsTask. Avoid validation of JarFile when extracting individual entries. Rework discovery in ByteBuddyMojo. 29. August 2024: version 1.15.1 Revert default EntryPoint for Android Gradle plugin to use DECORATE unless explicitly specified due to many generic type errors in Kotlin classes. 23. August 2024: version 1.15.0 Introduce AsmClassWriter and AsmClassReader abstractions that allow for plugging different implementations of readers and writers. Add configuration extension to the Android Gradle plugin and make it behave like regular Gradle plugin with standard configuration. Throw TypeNotPresentException upon discovering undeclared type variables as it was recently fixed on the JVM. 16. August 2024: version 1.14.19 Add Maven Mojo for transforming jars and for transforming dependencies folder. Better error handling for unresolved type variables. Allow loading arguments of the instrumented method in MemberSubstitution. Fix checks for method visibility. Commits https://github.com/raphw/byte-buddy/commit/e57aaf7313e668dfd02d5b28eca43e29dfcfcf9f";>e57aaf7 [maven-release-plugin] prepare release byte-buddy-1.15.4 https://github.com/raphw/byte-buddy/commit/1e2e40f8b1fd2e4617b146281b6570092c11f0ab";>1e2e40f [release] Release new version https://github.com/raphw/byte-buddy/commit/2f604169e63a5a04c7190ef014108b4efc9d3188";>2f60416 Update OS configuration. https://github.com/raphw/byte-buddy/commit/1250fac23cb8ac82279a4cf8972a862801532344";>1250fac Add checksums. https://github.com/raphw/byte-buddy/commit/cb1e8d410e25f7b4bf152ed005736a00f89c7a37";>cb1e8d4 Update ASM version. https://github.com/raphw/byte-buddy/commit/fe56d6d69ca5c55f431e2901f059e7fd1e0419b0";>fe56d6d Update internal Byte Buddy and release notes. https://github.com/raphw/byte-buddy/commit/0591c26a0bc6160b6622aae0694460a77c26c71e";>0591c26 [maven-release-plugin] prepare for next development iteration https://github.com/raphw/byte-buddy/commit/2c7a781c96d22514365229f4d1f46a0eaab6d434";>2c7a781 [maven-release-plugin] prepare release byte-buddy-1.15.3 https://github.com/raphw/byte-buddy/commit/209b5952cc057b71f00c06c23d9a85c283156d92";>209b595 [release] Release new version https://github.com/raphw/byte-buddy/commit/799090cbc62e9521d0f25211c6c3c3148d1fbe22";>799090c
Re: [PR] Bump net.bytebuddy:byte-buddy from 1.14.18 to 1.15.3 [maven-plugin-tools]
dependabot[bot] closed pull request #329: Bump net.bytebuddy:byte-buddy from 1.14.18 to 1.15.3 URL: https://github.com/apache/maven-plugin-tools/pull/329 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Bump org.apache.maven.doxia:doxia-integration-tools from 2.0.0-M19 to 2.0.0 [maven-project-info-reports-plugin]
dependabot[bot] opened a new pull request, #87: URL: https://github.com/apache/maven-project-info-reports-plugin/pull/87 Bumps [org.apache.maven.doxia:doxia-integration-tools](https://github.com/apache/maven-doxia-sitetools) from 2.0.0-M19 to 2.0.0. Commits https://github.com/apache/maven-doxia-sitetools/commit/0f79ba1c1dad16d1b001a09fdc7eafd1049792d5";>0f79ba1 [maven-release-plugin] prepare release doxia-sitetools-2.0.0 https://github.com/apache/maven-doxia-sitetools/commit/4d455f7acc89362883b03e9cf8740560af098d45";>4d455f7 [DOXIASITETOOLS-354] Upgrade to Maven Reporting API 4.0.0 https://github.com/apache/maven-doxia-sitetools/commit/c9cb8e0d95c3f3b634d2f0bb77928df3994aec29";>c9cb8e0 [DOXIASITETOOLS-353] Upgrade to Plexus Velocity 2.2.0 https://github.com/apache/maven-doxia-sitetools/commit/a0a555b1c3a093e2aa5d25dcefa7701390ef1bce";>a0a555b Bump org.apache.velocity:velocity-engine-core from 2.3 to 2.4 https://github.com/apache/maven-doxia-sitetools/commit/9f6d9ec166c4539c5906903d9bbc041243c3fc2d";>9f6d9ec Bump org.junit:junit-bom from 5.11.1 to 5.11.2 https://github.com/apache/maven-doxia-sitetools/commit/ea6eb76daffa47b4b4fa276fc89b07213c9d7107";>ea6eb76 [DOXIASITETOOLS-351] Upgrade to Doxia 2.0.0 https://github.com/apache/maven-doxia-sitetools/commit/f3d0a6ad34f3e34d6eaa7e60899b7e56afe26429";>f3d0a6a Bump commons-io:commons-io from 2.16.1 to 2.17.0 https://github.com/apache/maven-doxia-sitetools/commit/238265871b1b7adff0281d413735cfeae84f5fbe";>2382658 Bump org.junit:junit-bom from 5.11.0 to 5.11.1 https://github.com/apache/maven-doxia-sitetools/commit/004b948e77cc8ed2e6aa74548ea259f1e2b6fa73";>004b948 [DOXIASITETOOLS-348] Allow to require a parent site descriptor (https://redirect.github.com/apache/maven-doxia-sitetools/issues/173";>#173) https://github.com/apache/maven-doxia-sitetools/commit/1de20e3899ddef54885b5a35f4bd40866e221276";>1de20e3 Disable JIRA comments from GitHub (https://redirect.github.com/apache/maven-doxia-sitetools/issues/175";>#175) Additional commits viewable in https://github.com/apache/maven-doxia-sitetools/compare/doxia-sitetools-2.0.0-M19...doxia-sitetools-2.0.0";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MNG-8297) Color output no longer possible on dumb terminals
Stefan Oehme created MNG-8297: - Summary: Color output no longer possible on dumb terminals Key: MNG-8297 URL: https://issues.apache.org/jira/browse/MNG-8297 Project: Maven Issue Type: Bug Components: Logging Affects Versions: 4.0.x-candidate Reporter: Stefan Oehme We have a couple of integration tests for how our tool captures Maven console output, including color. These tests capture Maven's output in a ByteArrayOutputStream, which results in a "dumb terminal". With Maven 3.x, we still get color output. With the latest 4.x nightlies, the output is no longer colored. I dug through the code a bit and it seems to be related to the change to JLine. I tried adding `-Djansi.mode=force` to the MAVEN_OPTS, but that didn't bring coloring back. You can try this yourself by doing `export TERM=dumb`, followed by any Maven command. The output is uncolored, even though Maven itself says `Message scheme: color` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8297) Color output no longer possible on dumb terminals
[ https://issues.apache.org/jira/browse/MNG-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Oehme updated MNG-8297: -- Description: We have a couple of integration tests for how our tool captures Maven console output, including color. These tests capture Maven's output in a ByteArrayOutputStream, which results in a "dumb terminal". With Maven 3.x, we still get color output. With the latest 4.x nightlies, the output is no longer colored. I dug through the code a bit and it seems to be related to the change to JLine. I tried adding `-Djansi.mode=force` to the MAVEN_OPTS, but that didn't bring coloring back. You can try this yourself by doing `export TERM=dumb`, followed by any Maven command. The output is uncolored, even though Maven itself says `Message scheme: color` To be clear, I think having no color on dumb terminals is the correct default, but there should be a switch to bring it back for testing purposes. If there already is, please let me know how. was: We have a couple of integration tests for how our tool captures Maven console output, including color. These tests capture Maven's output in a ByteArrayOutputStream, which results in a "dumb terminal". With Maven 3.x, we still get color output. With the latest 4.x nightlies, the output is no longer colored. I dug through the code a bit and it seems to be related to the change to JLine. I tried adding `-Djansi.mode=force` to the MAVEN_OPTS, but that didn't bring coloring back. You can try this yourself by doing `export TERM=dumb`, followed by any Maven command. The output is uncolored, even though Maven itself says `Message scheme: color` > Color output no longer possible on dumb terminals > - > > Key: MNG-8297 > URL: https://issues.apache.org/jira/browse/MNG-8297 > Project: Maven > Issue Type: Bug > Components: Logging >Affects Versions: 4.0.x-candidate >Reporter: Stefan Oehme >Priority: Major > > We have a couple of integration tests for how our tool captures Maven console > output, including color. These tests capture Maven's output in a > ByteArrayOutputStream, which results in a "dumb terminal". With Maven 3.x, we > still get color output. With the latest 4.x nightlies, the output is no > longer colored. I dug through the code a bit and it seems to be related to > the change to JLine. I tried adding `-Djansi.mode=force` to the MAVEN_OPTS, > but that didn't bring coloring back. > You can try this yourself by doing `export TERM=dumb`, followed by any Maven > command. The output is uncolored, even though Maven itself says `Message > scheme: color` > To be clear, I think having no color on dumb terminals is the correct > default, but there should be a switch to bring it back for testing purposes. > If there already is, please let me know how. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8298) 4.x nightly breaks maven-resources plugin (and possibly others)
Stefan Oehme created MNG-8298:
-
Summary: 4.x nightly breaks maven-resources plugin (and possibly
others)
Key: MNG-8298
URL: https://issues.apache.org/jira/browse/MNG-8298
Project: Maven
Issue Type: Bug
Components: Core
Affects Versions: 4.0.x-candidate
Reporter: Stefan Oehme
The latest Maven 4.x nightlies no longer work with the latest nightlies of core
Maven plugins like the maven-resources plugin. It looks like this was caused by
this classloading change: [https://github.com/apache/maven/pull/1336]
Example stacktrace when using the latest maven-resources-plugin:
{code:java}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-resources-plugin:4.0.0-beta-2-SNAPSHOT:resources
(default-resources) on project a: Execution default-resources of goal
org.apache.maven.plugins:maven-resources-plugin:4.0.0-beta-2-SNAPSHOT:resources
failed: Unable to lookup Mojo: Error while initializing binding
BindingToConstructor[@Named("org.apache.maven.plugins:maven-resources-plugin:4.0.0-beta-2-SNAPSHOT:resources")
ResourcesMojoFactory][]: Error while initializing binding
BindingToConstructor[@Named
DefaultMavenResourcesFiltering][Dependency[key=BuildContext, optional=false],
Dependency[key=MavenFileFilter, optional=false]]: Error while initializing
binding BindingToConstructor[@Named
DefaultMavenFileFilter][Dependency[key=BuildContext, optional=false]]: Failed
to call method static org.sonatype.plexus.build.incremental.BuildContext
org.apache.maven.plugins.resources.Providers.buildContext():
org/codehaus/plexus/logging/AbstractLogEnabled:
org.codehaus.plexus.logging.AbstractLogEnabled -> [Help 1]
{code}
Is there a timeline for getting these plugins working again? We'd love to run
our tests against the latest of everything to make sure our Maven extension
works correctly when 4.0 is released.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SUREFIRE-2277) The value of RunResult flakes field is lost during serialisation and deserialisation to and from failsafe-summary.xml
Bing Xu created SUREFIRE-2277: - Summary: The value of RunResult flakes field is lost during serialisation and deserialisation to and from failsafe-summary.xml Key: SUREFIRE-2277 URL: https://issues.apache.org/jira/browse/SUREFIRE-2277 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin, Maven Surefire Plugin Affects Versions: 3.5.1 Reporter: Bing Xu Hello from Atlassian, I have found a bug in `RunResult.testAppendSerialization`. I don't think it should be passing on master. This test creates a `RunResult` object in-memory, serialises it, writes it to disk and then again deserialises the same file into a `RunResult` in-memory. I have run the test with the debugger and found that the final in-memory `RunResult` object is not the same as the initial one. The test is only passing because the `RunResult.flakes` field is not being considered in the `RunResult.equals` method (and the RunResult.equals method is used in the assertion within the test `RunResult.testAppendSerialization`). This is due to a bug in how the RunResult is converted to a `failsafe-summary.xml`. In the function `FailsafeSummaryXmlUtils.fromRunResultToFile`, `RunResult.flakes` is not written to the xml. To fix this issue, I have modified the `failsafe-summary.xsd` to include , which will allow Flakes to be persisted in the `failsafe-summary.xml`. I have also changed the serialisation and deserialisation methods for `RunResult` to account for `flakes`. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2148) Build fails if retried test classes failed during setup
[
https://issues.apache.org/jira/browse/SUREFIRE-2148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888176#comment-17888176
]
Pavlo Shevchenko commented on SUREFIRE-2148:
Just stumbled over it again. It is a regression between 3.0.0-M4 and 3.0.0-M5.
As of 3.5.1, it is still not working
> Build fails if retried test classes failed during setup
> ---
>
> Key: SUREFIRE-2148
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2148
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M8
>Reporter: Pavlo Shevchenko
>Priority: Major
>
> *Summary*
> If a JUnit5 test class fails during setup and succeeds on retry, then the
> surefire test goal and entire build will fail. On the other hand, if the
> failure occurs in a test method which succeeds on retry, then the goal and
> the build will succeed.
>
> *Reproducer*
> _Test class with flaky setup:_
> {code:java}
> package example;
> import org.junit.jupiter.api.BeforeAll;
> import org.junit.jupiter.api.Test;
> import java.io.File;
> import java.io.IOException;
> import java.nio.file.Files;
> import java.nio.file.Paths;
> public class FlakyClassTest {
> @BeforeAll
> public static void setup() throws IOException {
> String testSetupMarkerFile = "testSetupMarker.txt";
> if (!new File(testSetupMarkerFile).exists()) {
> System.out.println("I'm failing!");
> Files.write(Paths.get(testSetupMarkerFile), "Hello".getBytes());
> throw new RuntimeException("I'm failing!");
> } else {
> System.out.println("I'm passing!");
> }
> }
> @Test
> public void test() {
> }
> } {code}
>
> _Test class with flaky method:_
> {code:java}
> package example;
> import org.junit.jupiter.api.Test;
> import java.io.File;
> import java.io.IOException;
> import java.nio.file.Files;
> import java.nio.file.Paths;
> public class FlakyMethodTest {
> @Test
> public void test() throws IOException {
> String testMethodMarkerFile = "testMethodMarker.txt";
> if (!new File(testMethodMarkerFile).exists()) {
> System.out.println("I'm failing!");
> Files.write(Paths.get(testMethodMarkerFile), "Hello".getBytes());
> throw new RuntimeException("I'm failing!");
> } else {
> System.out.println("I'm passing!");
> }
> }
> }
> {code}
> _Surefire config:_
> {code:java}
>
> maven-surefire-plugin
> 3.0.0-M8
>
> 1
>
> {code}
>
> *Actual behavior*
> 1. This execution succeds:
> {code:java}
> mvn test -Dtest=*FlakyMethod*{code}
> 2. This execution fails:
> {code:java}
> mvn test -Dtest=*FlakyClass*{code}
>
> *Expected behavior*
> 1. Both executions succeed
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MSKINS-254) Rendering tabel in section from changes-report
Georg Kallidis created MSKINS-254:
-
Summary: Rendering tabel in section from changes-report
Key: MSKINS-254
URL: https://issues.apache.org/jira/browse/MSKINS-254
Project: Maven Skins
Issue Type: Bug
Components: Fluido Skin
Affects Versions: fluido-2.0.0-M11, fluido-2.0.0-M9
Reporter: Georg Kallidis
When running in a project with src/changes/changes.xml
{code:sh}
mvn changes:changes-report
{code}
does generate correct html code
{code:html}
Release-Geschichte
Version
..
{code}
but when running
{code:sh}
mvn site
{code}
the result is missing the table element after the section element.
{code:html}
..
Changes
Release History
Version
Date
Description
..
..
{code}
Though I only checked that in maven-fluido-skin resources/META-INF/site.vm
*$bodyColumn* {*}already contains the wrong body content missing the table
element{*}.
I am currently unable to understand exactly the mechanism, where the
transformation comes from doxia site tool and which template are used get this
done.
Is it a fluido skin ( 2.0.0-M9 or 2.0.0-M11 does makes no difference) or does
it happen still more upstreams?
It might be doxia tools ..
Example changes.xml:
{code:xml}
Changes
bar
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MSKINS-254) Rendering table in section from changes-report
[
https://issues.apache.org/jira/browse/MSKINS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Georg Kallidis updated MSKINS-254:
--
Summary: Rendering table in section from changes-report (was: Rendering
tabel in section from changes-report)
> Rendering table in section from changes-report
> --
>
> Key: MSKINS-254
> URL: https://issues.apache.org/jira/browse/MSKINS-254
> Project: Maven Skins
> Issue Type: Bug
> Components: Fluido Skin
>Affects Versions: fluido-2.0.0-M9, fluido-2.0.0-M11
>Reporter: Georg Kallidis
>Priority: Major
>
> When running in a project with src/changes/changes.xml
> {code:sh}
> mvn changes:changes-report
> {code}
> does generate correct html code
> {code:html}
>
>
>
> Release-Geschichte
>
>
> Version
> ..
> {code}
> but when running
> {code:sh}
> mvn site
> {code}
> the result is missing the table element after the section element.
> {code:html}
>
> ..
>
>
>
> Changes
> Release History
>
> Version
> Date
> Description
>
> ..
> ..
> {code}
> Though I only checked that in maven-fluido-skin resources/META-INF/site.vm
> *$bodyColumn* {*}already contains the wrong body content missing the table
> element{*}.
> I am currently unable to understand exactly the mechanism, where the
> transformation comes from doxia site tool and which template are used get
> this done.
> Is it a fluido skin ( 2.0.0-M9 or 2.0.0-M11 does makes no difference) or
> does it happen still more upstreams?
> It might be doxia tools ..
>
> Example changes.xml:
> {code:xml}
>
>
> Changes
>
>
>
> bar
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MSHARED-1433) Upgrade to Parent 43
Michael Osipov created MSHARED-1433: --- Summary: Upgrade to Parent 43 Key: MSHARED-1433 URL: https://issues.apache.org/jira/browse/MSHARED-1433 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-reporting-impl Reporter: Michael Osipov Assignee: Michael Osipov Fix For: maven-reporting-impl-4.0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1434) Upgrade to Doxia 2.0.0
Michael Osipov created MSHARED-1434: --- Summary: Upgrade to Doxia 2.0.0 Key: MSHARED-1434 URL: https://issues.apache.org/jira/browse/MSHARED-1434 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-reporting-impl Reporter: Michael Osipov Assignee: Michael Osipov Fix For: maven-reporting-impl-4.0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHARED-1435) Upgrade to Maven Reporting API 4.0.0
Michael Osipov created MSHARED-1435: --- Summary: Upgrade to Maven Reporting API 4.0.0 Key: MSHARED-1435 URL: https://issues.apache.org/jira/browse/MSHARED-1435 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-reporting-impl Reporter: Michael Osipov Assignee: Michael Osipov Fix For: maven-reporting-impl-4.0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump org.apache.maven.shared:maven-shared-components from 42 to 43 [maven-reporting-impl]
asfgit merged PR #48: URL: https://github.com/apache/maven-reporting-impl/pull/48 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MSHARED-1436) Upgrade to Doxia Sitetools 2.0.0
Michael Osipov created MSHARED-1436: --- Summary: Upgrade to Doxia Sitetools 2.0.0 Key: MSHARED-1436 URL: https://issues.apache.org/jira/browse/MSHARED-1436 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-reporting-impl Reporter: Michael Osipov Assignee: Michael Osipov Fix For: maven-reporting-impl-4.0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHARED-1434) Upgrade to Doxia 2.0.0
[ https://issues.apache.org/jira/browse/MSHARED-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSHARED-1434. --- Resolution: Fixed Fixed with [a724ac8d8acfd4cedacaaa05b54710a7ec65c6eb|https://gitbox.apache.org/repos/asf?p=maven-reporting-impl.git;a=commit;h=a724ac8d8acfd4cedacaaa05b54710a7ec65c6eb] for maven-reporting-impl. > Upgrade to Doxia 2.0.0 > -- > > Key: MSHARED-1434 > URL: https://issues.apache.org/jira/browse/MSHARED-1434 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-reporting-impl >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: maven-reporting-impl-4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump doxiaVersion from 2.0.0-M12 to 2.0.0 [maven-reporting-impl]
michael-o commented on PR #52: URL: https://github.com/apache/maven-reporting-impl/pull/52#issuecomment-2405666211 @dependabot rebase -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump doxiaVersion from 2.0.0-M12 to 2.0.0 [maven-reporting-impl]
asfgit merged PR #52: URL: https://github.com/apache/maven-reporting-impl/pull/52 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump doxiaSitetoolsVersion from 2.0.0-M19 to 2.0.0 [maven-reporting-impl]
asfgit merged PR #55: URL: https://github.com/apache/maven-reporting-impl/pull/55 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.apache.maven.reporting:maven-reporting-api from 4.0.0-M12 to 4.0.0 [maven-reporting-impl]
asfgit merged PR #53: URL: https://github.com/apache/maven-reporting-impl/pull/53 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MSHARED-1437) Upgrade plugins and components (in ITs)
Michael Osipov created MSHARED-1437: --- Summary: Upgrade plugins and components (in ITs) Key: MSHARED-1437 URL: https://issues.apache.org/jira/browse/MSHARED-1437 Project: Maven Shared Components Issue Type: Dependency upgrade Components: maven-reporting-impl Reporter: Michael Osipov Assignee: Michael Osipov Fix For: maven-reporting-impl-4.0.0 * Upgrade to Maven Plugin Tools 3.15.0 * Upgrade to Maven Compiler Plugin 3.13.0 * Upgrade to Maven Install Plugin 3.1.3 * Upgrade to Maven Site Plugin 3.20.0 * Upgrade to Maven Project Info Reports Plugin 3.7.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHARED-1437) Upgrade plugins and components (in ITs)
[ https://issues.apache.org/jira/browse/MSHARED-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSHARED-1437. --- Resolution: Fixed Fixed with [a4d9b2ff9c031aa270b5366410c39bad2b0eb0ad|https://gitbox.apache.org/repos/asf?p=maven-reporting-impl.git;a=commit;h=a4d9b2ff9c031aa270b5366410c39bad2b0eb0ad]. > Upgrade plugins and components (in ITs) > --- > > Key: MSHARED-1437 > URL: https://issues.apache.org/jira/browse/MSHARED-1437 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-reporting-impl >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: maven-reporting-impl-4.0.0 > > > * Upgrade to Maven Plugin Tools 3.15.0 > * Upgrade to Maven Compiler Plugin 3.13.0 > * Upgrade to Maven Install Plugin 3.1.3 > * Upgrade to Maven Site Plugin 3.20.0 > * Upgrade to Maven Project Info Reports Plugin 3.7.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Moved] (MSHARED-1438) Resolve Code Duplication for XRef Link generation
[ https://issues.apache.org/jira/browse/MSHARED-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov moved MPMD-250 to MSHARED-1438: -- Key: MSHARED-1438 (was: MPMD-250) Issue Type: Improvement (was: Task) Project: Maven Shared Components (was: Maven PMD Plugin) > Resolve Code Duplication for XRef Link generation > - > > Key: MSHARED-1438 > URL: https://issues.apache.org/jira/browse/MSHARED-1438 > Project: Maven Shared Components > Issue Type: Improvement >Reporter: Andreas Dangel >Assignee: Michael Osipov >Priority: Major > > PMD, Checkstyle and Surefire all have the same code to determine the xref > code location for reporting and linking to the source code. > See MPMD-128 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHARED-1438) Resolve Code Duplication for XRef Link generation
[ https://issues.apache.org/jira/browse/MSHARED-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSHARED-1438: Component/s: maven-reporting-impl > Resolve Code Duplication for XRef Link generation > - > > Key: MSHARED-1438 > URL: https://issues.apache.org/jira/browse/MSHARED-1438 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-reporting-impl >Reporter: Andreas Dangel >Assignee: Michael Osipov >Priority: Major > > PMD, Checkstyle and Surefire all have the same code to determine the xref > code location for reporting and linking to the source code. > See MPMD-128 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHARED-1438) Resolve Code Duplication for XRef Link generation
[ https://issues.apache.org/jira/browse/MSHARED-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSHARED-1438: Fix Version/s: maven-reporting-impl-4.0.0 > Resolve Code Duplication for XRef Link generation > - > > Key: MSHARED-1438 > URL: https://issues.apache.org/jira/browse/MSHARED-1438 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-reporting-impl >Affects Versions: maven-reporting-impl-4.0.0-M15 >Reporter: Andreas Dangel >Assignee: Michael Osipov >Priority: Major > Fix For: maven-reporting-impl-4.0.0 > > > PMD, Checkstyle and Surefire all have the same code to determine the xref > code location for reporting and linking to the source code. > See MPMD-128 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSHARED-1438) Resolve Code Duplication for XRef Link generation
[ https://issues.apache.org/jira/browse/MSHARED-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSHARED-1438: Affects Version/s: maven-reporting-impl-4.0.0-M15 > Resolve Code Duplication for XRef Link generation > - > > Key: MSHARED-1438 > URL: https://issues.apache.org/jira/browse/MSHARED-1438 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-reporting-impl >Affects Versions: maven-reporting-impl-4.0.0-M15 >Reporter: Andreas Dangel >Assignee: Michael Osipov >Priority: Major > > PMD, Checkstyle and Surefire all have the same code to determine the xref > code location for reporting and linking to the source code. > See MPMD-128 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump org.apache.maven.shared:maven-shared-components from 42 to 43 [maven-reporting-impl]
michael-o commented on PR #48: URL: https://github.com/apache/maven-reporting-impl/pull/48#issuecomment-2405660143 @dependabot rebase -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.junit:junit-bom from 5.11.0 to 5.11.2 [maven-reporting-impl]
asfgit merged PR #54: URL: https://github.com/apache/maven-reporting-impl/pull/54 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.apache.maven.reporting:maven-reporting-api from 4.0.0-M12 to 4.0.0 [maven-reporting-impl]
michael-o commented on PR #53: URL: https://github.com/apache/maven-reporting-impl/pull/53#issuecomment-2405671574 @dependabot rebase -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (MSHARED-1434) Upgrade to Doxia 2.0.0
[ https://issues.apache.org/jira/browse/MSHARED-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888370#comment-17888370 ] Michael Osipov edited comment on MSHARED-1434 at 10/10/24 5:26 PM: --- Fixed with [a724ac8d8acfd4cedacaaa05b54710a7ec65c6eb|https://gitbox.apache.org/repos/asf?p=maven-reporting-impl.git;a=commit;h=a724ac8d8acfd4cedacaaa05b54710a7ec65c6eb]. was (Author: michael-o): Fixed with [a724ac8d8acfd4cedacaaa05b54710a7ec65c6eb|https://gitbox.apache.org/repos/asf?p=maven-reporting-impl.git;a=commit;h=a724ac8d8acfd4cedacaaa05b54710a7ec65c6eb] for maven-reporting-impl. > Upgrade to Doxia 2.0.0 > -- > > Key: MSHARED-1434 > URL: https://issues.apache.org/jira/browse/MSHARED-1434 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-reporting-impl >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: maven-reporting-impl-4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MSHARED-1433) Upgrade to Parent 43
[ https://issues.apache.org/jira/browse/MSHARED-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888368#comment-17888368 ] Michael Osipov edited comment on MSHARED-1433 at 10/10/24 5:26 PM: --- Fixed with [817d6b881c34771b90c3a884a06b4f6983069d4c|https://gitbox.apache.org/repos/asf?p=maven-reporting-impl.git;a=commit;h=817d6b881c34771b90c3a884a06b4f6983069d4c]. was (Author: michael-o): Fixed with [817d6b881c34771b90c3a884a06b4f6983069d4c|https://gitbox.apache.org/repos/asf?p=maven-reporting-impl.git;a=commit;h=817d6b881c34771b90c3a884a06b4f6983069d4c] for maven-reporting-impl. > Upgrade to Parent 43 > > > Key: MSHARED-1433 > URL: https://issues.apache.org/jira/browse/MSHARED-1433 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-reporting-impl >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: maven-reporting-impl-4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump org.junit:junit-bom from 5.11.0 to 5.11.2 [maven-reporting-impl]
dependabot[bot] commented on PR #54: URL: https://github.com/apache/maven-reporting-impl/pull/54#issuecomment-2405657744 Looks like this PR is already up-to-date with master! If you'd still like to recreate it from scratch, overwriting any edits, you can request `@dependabot recreate`. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.junit:junit-bom from 5.11.0 to 5.11.2 [maven-reporting-impl]
michael-o commented on PR #54: URL: https://github.com/apache/maven-reporting-impl/pull/54#issuecomment-2405657635 @dependabot rebase -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MSHARED-1433) Upgrade to Parent 43
[ https://issues.apache.org/jira/browse/MSHARED-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSHARED-1433. --- Resolution: Fixed Fixed with [817d6b881c34771b90c3a884a06b4f6983069d4c|https://gitbox.apache.org/repos/asf?p=maven-reporting-impl.git;a=commit;h=817d6b881c34771b90c3a884a06b4f6983069d4c] for maven-reporting-impl. > Upgrade to Parent 43 > > > Key: MSHARED-1433 > URL: https://issues.apache.org/jira/browse/MSHARED-1433 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-reporting-impl >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: maven-reporting-impl-4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHARED-1435) Upgrade to Maven Reporting API 4.0.0
[ https://issues.apache.org/jira/browse/MSHARED-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSHARED-1435. --- Resolution: Fixed Fixed with [24d3b4688ea82d757704c0acc55312725fbaad29|https://gitbox.apache.org/repos/asf?p=maven-reporting-impl.git;a=commit;h=24d3b4688ea82d757704c0acc55312725fbaad29]. > Upgrade to Maven Reporting API 4.0.0 > > > Key: MSHARED-1435 > URL: https://issues.apache.org/jira/browse/MSHARED-1435 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-reporting-impl >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: maven-reporting-impl-4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MSHARED-1436) Upgrade to Doxia Sitetools 2.0.0
[ https://issues.apache.org/jira/browse/MSHARED-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MSHARED-1436. --- Resolution: Fixed Fixed with [fc982d1dbe001806080e878599bcabb797174539|https://gitbox.apache.org/repos/asf?p=maven-reporting-impl.git;a=commit;h=fc982d1dbe001806080e878599bcabb797174539]. > Upgrade to Doxia Sitetools 2.0.0 > > > Key: MSHARED-1436 > URL: https://issues.apache.org/jira/browse/MSHARED-1436 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-reporting-impl >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: maven-reporting-impl-4.0.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1438) Resolve Code Duplication for XRef Link generation
[ https://issues.apache.org/jira/browse/MSHARED-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888389#comment-17888389 ] ASF GitHub Bot commented on MSHARED-1438: - michael-o opened a new pull request, #56: URL: https://github.com/apache/maven-reporting-impl/pull/56 This closes #56 > Resolve Code Duplication for XRef Link generation > - > > Key: MSHARED-1438 > URL: https://issues.apache.org/jira/browse/MSHARED-1438 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-reporting-impl >Affects Versions: maven-reporting-impl-4.0.0-M15 >Reporter: Andreas Dangel >Assignee: Michael Osipov >Priority: Major > Fix For: maven-reporting-impl-4.0.0 > > > PMD, Checkstyle and Surefire all have the same code to determine the xref > code location for reporting and linking to the source code. > See MPMD-128 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1438) Resolve Code Duplication for XRef Link generation
[ https://issues.apache.org/jira/browse/MSHARED-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888390#comment-17888390 ] ASF GitHub Bot commented on MSHARED-1438: - michael-o opened a new pull request, #172: URL: https://github.com/apache/maven-pmd-plugin/pull/172 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/MPMD) 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 `[MPMD-XXX] - Subject of the JIRA Ticket`, where you replace `MPMD-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` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean verify`). 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). > Resolve Code Duplication for XRef Link generation > - > > Key: MSHARED-1438 > URL: https://issues.apache.org/jira/browse/MSHARED-1438 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-reporting-impl >Affects Versions: maven-reporting-impl-4.0.0-M15 >Reporter: Andreas Dangel >Assignee: Michael Osipov >Priority: Major > Fix For: maven-reporting-impl-4.0.0 > > > PMD, Checkstyle and Surefire all have the same code to determine the xref > code location for reporting and linking to the source code. > See MPMD-128 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] Draft for MSHARED-1438 [maven-pmd-plugin]
michael-o opened a new pull request, #172: URL: https://github.com/apache/maven-pmd-plugin/pull/172 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/MPMD) 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 `[MPMD-XXX] - Subject of the JIRA Ticket`, where you replace `MPMD-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` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean verify`). 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MCHANGES-423) Rendering table in section from changes-report
[
https://issues.apache.org/jira/browse/MCHANGES-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888309#comment-17888309
]
Georg Kallidis commented on MCHANGES-423:
-
Thanks, I review this.
N.B: I had to apply the fix (antrun replaceregexp, adding missing table
elements) to jdepend reports as well.
> Rendering table in section from changes-report
> --
>
> Key: MCHANGES-423
> URL: https://issues.apache.org/jira/browse/MCHANGES-423
> Project: Maven Changes Plugin
> Issue Type: Bug
>Affects Versions: 2.12.1
>Reporter: Georg Kallidis
>Priority: Major
>
> When running in a project with src/changes/changes.xml
> {code:sh}
> mvn changes:changes-report
> {code}
> does generate correct html code
> {code:html}
>
>
>
> Release-Geschichte
>
>
> Version
> ..
> {code}
> but when running
> {code:sh}
> mvn site
> {code}
> the result is missing the table element after the section element.
> {code:html}
>
> ..
>
>
>
> Changes
> Release History
>
> Version
> Date
> Description
>
> ..
> ..
> {code}
> Though I only checked that in maven-fluido-skin resources/META-INF/site.vm
> *$bodyColumn* {*}already contains the wrong body content missing the table
> element{*}.
> I am currently unable to understand exactly the mechanism, where the
> transformation comes from doxia site tool and which template are used get
> this done.
> Is it a fluido skin ( 2.0.0-M9 or 2.0.0-M11 does makes no difference) or
> does it happen still more upstreams?
> It might be doxia tools ..
>
> Example changes.xml:
> {code:xml}
>
>
> Changes
>
>
>
> bar
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCHANGES-423) Rendering table in section from changes-report
[
https://issues.apache.org/jira/browse/MCHANGES-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888316#comment-17888316
]
Michael Osipov commented on MCHANGES-423:
-
That's the correct workaround for now. Please file an issue with the jdepend
plugin. I will have look how easy it is to lift for Doxia 2.0.0.
> Rendering table in section from changes-report
> --
>
> Key: MCHANGES-423
> URL: https://issues.apache.org/jira/browse/MCHANGES-423
> Project: Maven Changes Plugin
> Issue Type: Bug
>Affects Versions: 2.12.1
>Reporter: Georg Kallidis
>Priority: Major
>
> When running in a project with src/changes/changes.xml
> {code:sh}
> mvn changes:changes-report
> {code}
> does generate correct html code
> {code:html}
>
>
>
> Release-Geschichte
>
>
> Version
> ..
> {code}
> but when running
> {code:sh}
> mvn site
> {code}
> the result is missing the table element after the section element.
> {code:html}
>
> ..
>
>
>
> Changes
> Release History
>
> Version
> Date
> Description
>
> ..
> ..
> {code}
> Though I only checked that in maven-fluido-skin resources/META-INF/site.vm
> *$bodyColumn* {*}already contains the wrong body content missing the table
> element{*}.
> I am currently unable to understand exactly the mechanism, where the
> transformation comes from doxia site tool and which template are used get
> this done.
> Is it a fluido skin ( 2.0.0-M9 or 2.0.0-M11 does makes no difference) or
> does it happen still more upstreams?
> It might be doxia tools ..
>
> Example changes.xml:
> {code:xml}
>
>
> Changes
>
>
>
> bar
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8297) Color output no longer possible on dumb terminals
[
https://issues.apache.org/jira/browse/MNG-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888364#comment-17888364
]
Guillaume Nodet commented on MNG-8297:
--
Try adding the following system property
\{{-Dorg.jline.terminal.dumb.color=true}}
> Color output no longer possible on dumb terminals
> -
>
> Key: MNG-8297
> URL: https://issues.apache.org/jira/browse/MNG-8297
> Project: Maven
> Issue Type: Bug
> Components: Logging
>Affects Versions: 4.0.x-candidate
>Reporter: Stefan Oehme
>Priority: Major
>
> We have a couple of integration tests for how our tool captures Maven console
> output, including color. These tests capture Maven's output in a
> ByteArrayOutputStream, which results in a "dumb terminal". With Maven 3.x, we
> still get color output. With the latest 4.x nightlies, the output is no
> longer colored. I dug through the code a bit and it seems to be related to
> the change to JLine. I tried adding `-Djansi.mode=force` to the MAVEN_OPTS,
> but that didn't bring coloring back.
> You can try this yourself by doing `export TERM=dumb`, followed by any Maven
> command. The output is uncolored, even though Maven itself says `Message
> scheme: color`
> To be clear, I think having no color on dumb terminals is the correct
> default, but there should be a switch to bring it back for testing purposes.
> If there already is, please let me know how.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8298) 4.x nightly breaks maven-resources plugin (and possibly others)
[
https://issues.apache.org/jira/browse/MNG-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888365#comment-17888365
]
Guillaume Nodet commented on MNG-8298:
--
We're focusing on getting {{mvnd}} to work with {{beta-5}}.
Once that's done, I think we'll release both and then update plugins...
> 4.x nightly breaks maven-resources plugin (and possibly others)
> ---
>
> Key: MNG-8298
> URL: https://issues.apache.org/jira/browse/MNG-8298
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.x-candidate
>Reporter: Stefan Oehme
>Priority: Major
>
> The latest Maven 4.x nightlies no longer work with the latest nightlies of
> core Maven plugins like the maven-resources plugin. It looks like this was
> caused by this classloading change:
> [https://github.com/apache/maven/pull/1336]
> Example stacktrace when using the latest maven-resources-plugin:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-resources-plugin:4.0.0-beta-2-SNAPSHOT:resources
> (default-resources) on project a: Execution default-resources of goal
> org.apache.maven.plugins:maven-resources-plugin:4.0.0-beta-2-SNAPSHOT:resources
> failed: Unable to lookup Mojo: Error while initializing binding
> BindingToConstructor[@Named("org.apache.maven.plugins:maven-resources-plugin:4.0.0-beta-2-SNAPSHOT:resources")
> ResourcesMojoFactory][]: Error while initializing binding
> BindingToConstructor[@Named
> DefaultMavenResourcesFiltering][Dependency[key=BuildContext, optional=false],
> Dependency[key=MavenFileFilter, optional=false]]: Error while initializing
> binding BindingToConstructor[@Named
> DefaultMavenFileFilter][Dependency[key=BuildContext, optional=false]]: Failed
> to call method static org.sonatype.plexus.build.incremental.BuildContext
> org.apache.maven.plugins.resources.Providers.buildContext():
> org/codehaus/plexus/logging/AbstractLogEnabled:
> org.codehaus.plexus.logging.AbstractLogEnabled -> [Help 1]
> {code}
>
> Is there a timeline for getting these plugins working again? We'd love to run
> our tests against the latest of everything to make sure our Maven extension
> works correctly when 4.0 is released.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-8297) Color output no longer possible on dumb terminals
[ https://issues.apache.org/jira/browse/MNG-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned MNG-8297: Assignee: Guillaume Nodet > Color output no longer possible on dumb terminals > - > > Key: MNG-8297 > URL: https://issues.apache.org/jira/browse/MNG-8297 > Project: Maven > Issue Type: Bug > Components: Logging >Affects Versions: 4.0.x-candidate >Reporter: Stefan Oehme >Assignee: Guillaume Nodet >Priority: Major > > We have a couple of integration tests for how our tool captures Maven console > output, including color. These tests capture Maven's output in a > ByteArrayOutputStream, which results in a "dumb terminal". With Maven 3.x, we > still get color output. With the latest 4.x nightlies, the output is no > longer colored. I dug through the code a bit and it seems to be related to > the change to JLine. I tried adding `-Djansi.mode=force` to the MAVEN_OPTS, > but that didn't bring coloring back. > You can try this yourself by doing `export TERM=dumb`, followed by any Maven > command. The output is uncolored, even though Maven itself says `Message > scheme: color` > To be clear, I think having no color on dumb terminals is the correct > default, but there should be a switch to bring it back for testing purposes. > If there already is, please let me know how. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-8299) Maven 4 reverses custom lifecycle ordering
[
https://issues.apache.org/jira/browse/MNG-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned MNG-8299:
Assignee: Guillaume Nodet
> Maven 4 reverses custom lifecycle ordering
> --
>
> Key: MNG-8299
> URL: https://issues.apache.org/jira/browse/MNG-8299
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.x-candidate
>Reporter: Stefan Oehme
>Assignee: Guillaume Nodet
>Priority: Major
>
> Following this tutorial:
> [https://nextmetaphor.wordpress.com/2016/10/10/custom-maven-lifecycle/]
>
> On Maven 3.x, if you run `mvn phase3` on the project, it correctly runs phase
> 1 and 2 first and outputs
> {code:java}
> [INFO] Doing Phase 1 stuff. {code}
>
> On the 4.x nightlies, running the same command no longer runs phase 1 or 2.
> It looks like the order of phases is reversed. This happened after
> [https://github.com/apache/maven/pull/1448] was merged I think.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MJAR-314] Use the special constant value REPRODUCIBLE_BUILD_STATIC_DATE [maven-archiver]
hboutemy commented on PR #72: URL: https://github.com/apache/maven-archiver/pull/72#issuecomment-2405948345 -1 no already done in https://issues.apache.org/jira/browse/MNG-8258 in a way that is configurable by project doing that in this component does not make sense -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MJAR-314) Use a predefined constant for project.build.outputTimestamp
[
https://issues.apache.org/jira/browse/MJAR-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888418#comment-17888418
]
ASF GitHub Bot commented on MJAR-314:
-
hboutemy commented on PR #72:
URL: https://github.com/apache/maven-archiver/pull/72#issuecomment-2405948345
-1 no
already done in https://issues.apache.org/jira/browse/MNG-8258 in a way that
is configurable by project
doing that in this component does not make sense
> Use a predefined constant for project.build.outputTimestamp
> ---
>
> Key: MJAR-314
> URL: https://issues.apache.org/jira/browse/MJAR-314
> Project: Maven JAR Plugin
> Issue Type: Improvement
>Reporter: Sergey Ponomarev
>Priority: Major
>
> The "Configuring for Reproducible Builds" guide shows and example how to
> specify a static outputTimestamp:
>
> 2023-01-01T00:00:00Z
> The date inside is really doesn't matter and I used the property as is but
> was afraid of being asked on a review why the 2023 year was used so used the
> current year.
> But still during a review I was asked:
> bq. these changes are likely going to confuse future developers ("This date
> shouldn't be static! Lets make it a variable!").
> The Gradle has an option preserveFileTimestamps = false that will just put 1
> Feb 1980 as a date. The 1 Jan 1980 is a minimal date in Zip archive but the 1
> Jan has some special treatment by Java that's why the Gradle team used the 1
> Feb.
> See more detailed description in CONSTANT_TIME_FOR_ZIP_ENTRIES
> https://github.com/gradle/gradle/blob/master/platforms/core-runtime/files/src/main/java/org/gradle/api/internal/file/archive/ZipEntryConstants.java#L39
> I don't think it worth to declare some new property e.g.
> true
> But we can simply make a special constant value like:
>
> REPRODUCIBLE_BUILD_STATIC_DATE
> Then the constant will be replaced with the same 1 Feb 1980 to be similar
> with Gradle produced artifacts.
> This constant should make it more clear intention of the outputTimestamp but
> also easier to find an explanation for this.
> The outputTimestamp parsing is performed in the maven-archiver but the
> maven-compiler-plugin and maven-jar-plugin would need to update a JavaDoc for
> the outputTimestamp config option
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] Bump doxiaSitetoolsVersion from 2.0.0-M19 to 2.0.0 [maven-reporting-impl]
dependabot[bot] opened a new pull request, #55: URL: https://github.com/apache/maven-reporting-impl/pull/55 Bumps `doxiaSitetoolsVersion` from 2.0.0-M19 to 2.0.0. Updates `org.apache.maven.doxia:doxia-site-model` from 2.0.0-M19 to 2.0.0 Commits https://github.com/apache/maven-doxia-sitetools/commit/0f79ba1c1dad16d1b001a09fdc7eafd1049792d5";>0f79ba1 [maven-release-plugin] prepare release doxia-sitetools-2.0.0 https://github.com/apache/maven-doxia-sitetools/commit/4d455f7acc89362883b03e9cf8740560af098d45";>4d455f7 [DOXIASITETOOLS-354] Upgrade to Maven Reporting API 4.0.0 https://github.com/apache/maven-doxia-sitetools/commit/c9cb8e0d95c3f3b634d2f0bb77928df3994aec29";>c9cb8e0 [DOXIASITETOOLS-353] Upgrade to Plexus Velocity 2.2.0 https://github.com/apache/maven-doxia-sitetools/commit/a0a555b1c3a093e2aa5d25dcefa7701390ef1bce";>a0a555b Bump org.apache.velocity:velocity-engine-core from 2.3 to 2.4 https://github.com/apache/maven-doxia-sitetools/commit/9f6d9ec166c4539c5906903d9bbc041243c3fc2d";>9f6d9ec Bump org.junit:junit-bom from 5.11.1 to 5.11.2 https://github.com/apache/maven-doxia-sitetools/commit/ea6eb76daffa47b4b4fa276fc89b07213c9d7107";>ea6eb76 [DOXIASITETOOLS-351] Upgrade to Doxia 2.0.0 https://github.com/apache/maven-doxia-sitetools/commit/f3d0a6ad34f3e34d6eaa7e60899b7e56afe26429";>f3d0a6a Bump commons-io:commons-io from 2.16.1 to 2.17.0 https://github.com/apache/maven-doxia-sitetools/commit/238265871b1b7adff0281d413735cfeae84f5fbe";>2382658 Bump org.junit:junit-bom from 5.11.0 to 5.11.1 https://github.com/apache/maven-doxia-sitetools/commit/004b948e77cc8ed2e6aa74548ea259f1e2b6fa73";>004b948 [DOXIASITETOOLS-348] Allow to require a parent site descriptor (https://redirect.github.com/apache/maven-doxia-sitetools/issues/173";>#173) https://github.com/apache/maven-doxia-sitetools/commit/1de20e3899ddef54885b5a35f4bd40866e221276";>1de20e3 Disable JIRA comments from GitHub (https://redirect.github.com/apache/maven-doxia-sitetools/issues/175";>#175) Additional commits viewable in https://github.com/apache/maven-doxia-sitetools/compare/doxia-sitetools-2.0.0-M19...doxia-sitetools-2.0.0";>compare view Updates `org.apache.maven.doxia:doxia-integration-tools` from 2.0.0-M19 to 2.0.0 Commits https://github.com/apache/maven-doxia-sitetools/commit/0f79ba1c1dad16d1b001a09fdc7eafd1049792d5";>0f79ba1 [maven-release-plugin] prepare release doxia-sitetools-2.0.0 https://github.com/apache/maven-doxia-sitetools/commit/4d455f7acc89362883b03e9cf8740560af098d45";>4d455f7 [DOXIASITETOOLS-354] Upgrade to Maven Reporting API 4.0.0 https://github.com/apache/maven-doxia-sitetools/commit/c9cb8e0d95c3f3b634d2f0bb77928df3994aec29";>c9cb8e0 [DOXIASITETOOLS-353] Upgrade to Plexus Velocity 2.2.0 https://github.com/apache/maven-doxia-sitetools/commit/a0a555b1c3a093e2aa5d25dcefa7701390ef1bce";>a0a555b Bump org.apache.velocity:velocity-engine-core from 2.3 to 2.4 https://github.com/apache/maven-doxia-sitetools/commit/9f6d9ec166c4539c5906903d9bbc041243c3fc2d";>9f6d9ec Bump org.junit:junit-bom from 5.11.1 to 5.11.2 https://github.com/apache/maven-doxia-sitetools/commit/ea6eb76daffa47b4b4fa276fc89b07213c9d7107";>ea6eb76 [DOXIASITETOOLS-351] Upgrade to Doxia 2.0.0 https://github.com/apache/maven-doxia-sitetools/commit/f3d0a6ad34f3e34d6eaa7e60899b7e56afe26429";>f3d0a6a Bump commons-io:commons-io from 2.16.1 to 2.17.0 https://github.com/apache/maven-doxia-sitetools/commit/238265871b1b7adff0281d413735cfeae84f5fbe";>2382658 Bump org.junit:junit-bom from 5.11.0 to 5.11.1 https://github.com/apache/maven-doxia-sitetools/commit/004b948e77cc8ed2e6aa74548ea259f1e2b6fa73";>004b948 [DOXIASITETOOLS-348] Allow to require a parent site descriptor (https://redirect.github.com/apache/maven-doxia-sitetools/issues/173";>#173) https://github.com/apache/maven-doxia-sitetools/commit/1de20e3899ddef54885b5a35f4bd40866e221276";>1de20e3 Disable JIRA comments from GitHub (https://redirect.github.com/apache/maven-doxia-sitetools/issues/175";>#175) Additional commits viewable in https://github.com/apache/maven-doxia-sitetools/compare/doxia-sitetools-2.0.0-M19...doxia-sitetools-2.0.0";>compare view Updates `org.apache.maven.doxia:doxia-site-renderer` from 2.0.0-M19 to 2.0.0 Commits https://github.com/apache/maven-doxia-sitetools/commit/0f79ba1c1dad16d1b001a09fdc7eafd1049792d5";>0f79ba1 [maven-release-plugin] prepare release doxia-sitetools-2.0.0 https://github.com/apache/maven-doxia-sitetools/commit/4d455f7acc89362883b03e9cf8740560af098d45";>4d455f7 [DOXIASITETOOLS-354] Upgrade to Maven Reporting API 4.0.0 https://github.com/apache/maven-doxia-sitetools/commit/c9cb8e0d95c3f3b634d2f0bb77928df3994aec29";>c9cb8e0 [DOXIASITETOOLS-353] Upgrade to Plexus Velocity 2.2.0 https://github.com/apache/maven-doxia-sitetools/commit/a0a555b1c3a093e2aa5d25dcefa7701390ef1bce";>a0a555b Bump org.apache.velocity:vel
[jira] [Closed] (DOXIASITETOOLS-327) Support multi-language for menu "name"
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed DOXIASITETOOLS-327. - Fix Version/s: (was: waiting-for-feedback) Resolution: Information Provided > Support multi-language for menu "name" > -- > > Key: DOXIASITETOOLS-327 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-327 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site model >Affects Versions: 2.0.0-M16 >Reporter: Abel Salgado Romero >Priority: Minor > Attachments: image-2024-01-16-23-19-41-511.png > > > The new v2.0.x-MX added multi-lang / locale support to build pages, but seems > the `site.xml` does not allow to change the name of a menu element. > For example, a page with "en" and "es" versions and menu "Hello", will show > "Hello" in the Spanish site too, no way to specify "Hola". > > I peeked at the code and I see two options: > # Modify MenuItem to allow a sub name element like ` locale="es">Hola` > # Allow injection of language ResourceBundle properties in the current > element: `` > I like the second and will try to explore that, I saw the generated code > provides a transformer method for values, just need to find how to inject > custom logic there 🤔 > !image-2024-01-16-23-19-41-511.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-600) Use a predefined constant for project.build.outputTimestamp
[
https://issues.apache.org/jira/browse/MCOMPILER-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888432#comment-17888432
]
Sergey Ponomarev commented on MCOMPILER-600:
Since MNG-8258 the default date will be set by default for all projects that
use the Maven (including the Maven itself). The issue can be closed as WONTFIX
> Use a predefined constant for project.build.outputTimestamp
> ---
>
> Key: MCOMPILER-600
> URL: https://issues.apache.org/jira/browse/MCOMPILER-600
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Sergey Ponomarev
>Priority: Minor
>
> The "Configuring for Reproducible Builds" guide shows and example how to
> specify a static outputTimestamp:
>
> 2023-01-01T00:00:00Z
> The date inside is really doesn't matter and I used the property as is but
> was afraid of being asked on a review why the 2023 year was used so used the
> current year.
> But still during a review I was asked:
> bq. these changes are likely going to confuse future developers ("This date
> shouldn't be static! Lets make it a variable!").
> The Gradle has an option preserveFileTimestamps = false that will just put 1
> Feb 1980 as a date. The 1 Jan 1980 is a minimal date in Zip archive but the 1
> Jan has some special treatment by Java that's why the Gradle team used the 1
> Feb.
> See more detailed description in CONSTANT_TIME_FOR_ZIP_ENTRIES
> https://github.com/gradle/gradle/blob/master/platforms/core-runtime/files/src/main/java/org/gradle/api/internal/file/archive/ZipEntryConstants.java#L39
> I don't think it worth to declare some new property e.g.
> true
> But we can simply make a special constant value like:
>
> REPRODUCIBLE_BUILD_STATIC_DATE
> Then the constant will be replaced with the same 1 Feb 1980 to be similar
> with Gradle produced artifacts.
> This constant should make it more clear intention of the outputTimestamp but
> also easier to find an explanation for this.
> The outputTimestamp parsing is performed in the maven-archiver but the
> maven-compiler-plugin and maven-jar-plugin would need to update a JavaDoc for
> the outputTimestamp config option
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1430) Use a predefined constant for project.build.outputTimestamp
[
https://issues.apache.org/jira/browse/MSHARED-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888429#comment-17888429
]
Sergey Ponomarev commented on MSHARED-1430:
---
Since MNG-8258 the default date will be set by default for all projects that
use the Maven (including the Maven itself). The issue can be closed as WONTFIX
> Use a predefined constant for project.build.outputTimestamp
> ---
>
> Key: MSHARED-1430
> URL: https://issues.apache.org/jira/browse/MSHARED-1430
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Reporter: Sergey Ponomarev
>Priority: Minor
>
> The "Configuring for Reproducible Builds" guide shows and example how to
> specify a static outputTimestamp:
>
> 2023-01-01T00:00:00Z
> The date inside is really doesn't matter and I used the property as is but
> was afraid of being asked on a review why the 2023 year was used so used the
> current year.
> But still during a review I was asked:
> bq. these changes are likely going to confuse future developers ("This date
> shouldn't be static! Lets make it a variable!").
> The Gradle has an option preserveFileTimestamps = false that will just put 1
> Feb 1980 as a date. The 1 Jan 1980 is a minimal date in Zip archive but the 1
> Jan has some special treatment by Java that's why the Gradle team used the 1
> Feb.
> See more detailed description in CONSTANT_TIME_FOR_ZIP_ENTRIES
> https://github.com/gradle/gradle/blob/master/platforms/core-runtime/files/src/main/java/org/gradle/api/internal/file/archive/ZipEntryConstants.java#L39
> I don't think it worth to declare some new property e.g.
> true
> But we can simply make a special constant value like:
>
> REPRODUCIBLE_BUILD_STATIC_DATE
> Then the constant will be replaced with the same 1 Feb 1980 to be similar
> with Gradle produced artifacts.
> This constant should make it more clear intention of the outputTimestamp but
> also easier to find an explanation for this.
> The outputTimestamp parsing is performed in the maven-archiver but the
> maven-compiler-plugin and maven-jar-plugin would need to update a JavaDoc for
> the outputTimestamp config option
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MJAR-314] Use the special constant value REPRODUCIBLE_BUILD_STATIC_DATE [maven-jar-plugin]
stokito closed pull request #102: [MJAR-314] Use the special constant value REPRODUCIBLE_BUILD_STATIC_DATE URL: https://github.com/apache/maven-jar-plugin/pull/102 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MJAR-314) Use a predefined constant for project.build.outputTimestamp
[
https://issues.apache.org/jira/browse/MJAR-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888435#comment-17888435
]
ASF GitHub Bot commented on MJAR-314:
-
stokito closed pull request #102: [MJAR-314] Use the special constant value
REPRODUCIBLE_BUILD_STATIC_DATE
URL: https://github.com/apache/maven-jar-plugin/pull/102
> Use a predefined constant for project.build.outputTimestamp
> ---
>
> Key: MJAR-314
> URL: https://issues.apache.org/jira/browse/MJAR-314
> Project: Maven JAR Plugin
> Issue Type: Improvement
>Reporter: Sergey Ponomarev
>Priority: Major
>
> The "Configuring for Reproducible Builds" guide shows and example how to
> specify a static outputTimestamp:
>
> 2023-01-01T00:00:00Z
> The date inside is really doesn't matter and I used the property as is but
> was afraid of being asked on a review why the 2023 year was used so used the
> current year.
> But still during a review I was asked:
> bq. these changes are likely going to confuse future developers ("This date
> shouldn't be static! Lets make it a variable!").
> The Gradle has an option preserveFileTimestamps = false that will just put 1
> Feb 1980 as a date. The 1 Jan 1980 is a minimal date in Zip archive but the 1
> Jan has some special treatment by Java that's why the Gradle team used the 1
> Feb.
> See more detailed description in CONSTANT_TIME_FOR_ZIP_ENTRIES
> https://github.com/gradle/gradle/blob/master/platforms/core-runtime/files/src/main/java/org/gradle/api/internal/file/archive/ZipEntryConstants.java#L39
> I don't think it worth to declare some new property e.g.
> true
> But we can simply make a special constant value like:
>
> REPRODUCIBLE_BUILD_STATIC_DATE
> Then the constant will be replaced with the same 1 Feb 1980 to be similar
> with Gradle produced artifacts.
> This constant should make it more clear intention of the outputTimestamp but
> also easier to find an explanation for this.
> The outputTimestamp parsing is performed in the maven-archiver but the
> maven-compiler-plugin and maven-jar-plugin would need to update a JavaDoc for
> the outputTimestamp config option
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-600) Use a predefined constant for project.build.outputTimestamp
[
https://issues.apache.org/jira/browse/MCOMPILER-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888436#comment-17888436
]
ASF GitHub Bot commented on MCOMPILER-600:
--
stokito closed pull request #267: [MCOMPILER-600] Use the special constant
value REPRODUCIBLE_BUILD_STATIC_DATE
URL: https://github.com/apache/maven-compiler-plugin/pull/267
> Use a predefined constant for project.build.outputTimestamp
> ---
>
> Key: MCOMPILER-600
> URL: https://issues.apache.org/jira/browse/MCOMPILER-600
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Sergey Ponomarev
>Priority: Minor
>
> The "Configuring for Reproducible Builds" guide shows and example how to
> specify a static outputTimestamp:
>
> 2023-01-01T00:00:00Z
> The date inside is really doesn't matter and I used the property as is but
> was afraid of being asked on a review why the 2023 year was used so used the
> current year.
> But still during a review I was asked:
> bq. these changes are likely going to confuse future developers ("This date
> shouldn't be static! Lets make it a variable!").
> The Gradle has an option preserveFileTimestamps = false that will just put 1
> Feb 1980 as a date. The 1 Jan 1980 is a minimal date in Zip archive but the 1
> Jan has some special treatment by Java that's why the Gradle team used the 1
> Feb.
> See more detailed description in CONSTANT_TIME_FOR_ZIP_ENTRIES
> https://github.com/gradle/gradle/blob/master/platforms/core-runtime/files/src/main/java/org/gradle/api/internal/file/archive/ZipEntryConstants.java#L39
> I don't think it worth to declare some new property e.g.
> true
> But we can simply make a special constant value like:
>
> REPRODUCIBLE_BUILD_STATIC_DATE
> Then the constant will be replaced with the same 1 Feb 1980 to be similar
> with Gradle produced artifacts.
> This constant should make it more clear intention of the outputTimestamp but
> also easier to find an explanation for this.
> The outputTimestamp parsing is performed in the maven-archiver but the
> maven-compiler-plugin and maven-jar-plugin would need to update a JavaDoc for
> the outputTimestamp config option
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MCOMPILER-600] Use the special constant value REPRODUCIBLE_BUILD_STATIC_DATE [maven-compiler-plugin]
stokito closed pull request #267: [MCOMPILER-600] Use the special constant value REPRODUCIBLE_BUILD_STATIC_DATE URL: https://github.com/apache/maven-compiler-plugin/pull/267 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-8299) Maven 4 reverses custom lifecycle ordering
[
https://issues.apache.org/jira/browse/MNG-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-8299:
-
Fix Version/s: 4.0.0-beta-5
> Maven 4 reverses custom lifecycle ordering
> --
>
> Key: MNG-8299
> URL: https://issues.apache.org/jira/browse/MNG-8299
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.x-candidate
>Reporter: Stefan Oehme
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-beta-5
>
>
> Following this tutorial:
> [https://nextmetaphor.wordpress.com/2016/10/10/custom-maven-lifecycle/]
>
> On Maven 3.x, if you run `mvn phase3` on the project, it correctly runs phase
> 1 and 2 first and outputs
> {code:java}
> [INFO] Doing Phase 1 stuff. {code}
>
> On the 4.x nightlies, running the same command no longer runs phase 1 or 2.
> It looks like the order of phases is reversed. This happened after
> [https://github.com/apache/maven/pull/1448] was merged I think.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MJAR-314] Use the special constant value REPRODUCIBLE_BUILD_STATIC_DATE [maven-archiver]
stokito commented on PR #72: URL: https://github.com/apache/maven-archiver/pull/72#issuecomment-2406007149 Oh I see, so this will be enabled not just for the Maven itself but by default for all projects that use the Maven (including the Maven itself). Then yes, the PR is not needed. The only thing worth to be changed is the default static time. It would be better to use same date as Gradle use 1 Feb 1980. This was already discussed and while the Maven 4 is in beta it's good time to change it. I'll try the Maven 4 later, maybe I don't need to change anything in a project to get reproducible build. -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MJAR-314) Use a predefined constant for project.build.outputTimestamp
[
https://issues.apache.org/jira/browse/MJAR-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888427#comment-17888427
]
ASF GitHub Bot commented on MJAR-314:
-
stokito commented on PR #72:
URL: https://github.com/apache/maven-archiver/pull/72#issuecomment-2406007149
Oh I see, so this will be enabled not just for the Maven itself but by
default for all projects that use the Maven (including the Maven itself).
Then yes, the PR is not needed. The only thing worth to be changed is the
default static time. It would be better to use same date as Gradle use 1 Feb
1980. This was already discussed and while the Maven 4 is in beta it's good
time to change it. I'll try the Maven 4 later, maybe I don't need to change
anything in a project to get reproducible build.
> Use a predefined constant for project.build.outputTimestamp
> ---
>
> Key: MJAR-314
> URL: https://issues.apache.org/jira/browse/MJAR-314
> Project: Maven JAR Plugin
> Issue Type: Improvement
>Reporter: Sergey Ponomarev
>Priority: Major
>
> The "Configuring for Reproducible Builds" guide shows and example how to
> specify a static outputTimestamp:
>
> 2023-01-01T00:00:00Z
> The date inside is really doesn't matter and I used the property as is but
> was afraid of being asked on a review why the 2023 year was used so used the
> current year.
> But still during a review I was asked:
> bq. these changes are likely going to confuse future developers ("This date
> shouldn't be static! Lets make it a variable!").
> The Gradle has an option preserveFileTimestamps = false that will just put 1
> Feb 1980 as a date. The 1 Jan 1980 is a minimal date in Zip archive but the 1
> Jan has some special treatment by Java that's why the Gradle team used the 1
> Feb.
> See more detailed description in CONSTANT_TIME_FOR_ZIP_ENTRIES
> https://github.com/gradle/gradle/blob/master/platforms/core-runtime/files/src/main/java/org/gradle/api/internal/file/archive/ZipEntryConstants.java#L39
> I don't think it worth to declare some new property e.g.
> true
> But we can simply make a special constant value like:
>
> REPRODUCIBLE_BUILD_STATIC_DATE
> Then the constant will be replaced with the same 1 Feb 1980 to be similar
> with Gradle produced artifacts.
> This constant should make it more clear intention of the outputTimestamp but
> also easier to find an explanation for this.
> The outputTimestamp parsing is performed in the maven-archiver but the
> maven-compiler-plugin and maven-jar-plugin would need to update a JavaDoc for
> the outputTimestamp config option
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAR-314) Use a predefined constant for project.build.outputTimestamp
[
https://issues.apache.org/jira/browse/MJAR-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888428#comment-17888428
]
ASF GitHub Bot commented on MJAR-314:
-
stokito closed pull request #72: [MJAR-314] Use the special constant value
REPRODUCIBLE_BUILD_STATIC_DATE
URL: https://github.com/apache/maven-archiver/pull/72
> Use a predefined constant for project.build.outputTimestamp
> ---
>
> Key: MJAR-314
> URL: https://issues.apache.org/jira/browse/MJAR-314
> Project: Maven JAR Plugin
> Issue Type: Improvement
>Reporter: Sergey Ponomarev
>Priority: Major
>
> The "Configuring for Reproducible Builds" guide shows and example how to
> specify a static outputTimestamp:
>
> 2023-01-01T00:00:00Z
> The date inside is really doesn't matter and I used the property as is but
> was afraid of being asked on a review why the 2023 year was used so used the
> current year.
> But still during a review I was asked:
> bq. these changes are likely going to confuse future developers ("This date
> shouldn't be static! Lets make it a variable!").
> The Gradle has an option preserveFileTimestamps = false that will just put 1
> Feb 1980 as a date. The 1 Jan 1980 is a minimal date in Zip archive but the 1
> Jan has some special treatment by Java that's why the Gradle team used the 1
> Feb.
> See more detailed description in CONSTANT_TIME_FOR_ZIP_ENTRIES
> https://github.com/gradle/gradle/blob/master/platforms/core-runtime/files/src/main/java/org/gradle/api/internal/file/archive/ZipEntryConstants.java#L39
> I don't think it worth to declare some new property e.g.
> true
> But we can simply make a special constant value like:
>
> REPRODUCIBLE_BUILD_STATIC_DATE
> Then the constant will be replaced with the same 1 Feb 1980 to be similar
> with Gradle produced artifacts.
> This constant should make it more clear intention of the outputTimestamp but
> also easier to find an explanation for this.
> The outputTimestamp parsing is performed in the maven-archiver but the
> maven-compiler-plugin and maven-jar-plugin would need to update a JavaDoc for
> the outputTimestamp config option
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MJAR-314] Use the special constant value REPRODUCIBLE_BUILD_STATIC_DATE [maven-archiver]
stokito closed pull request #72: [MJAR-314] Use the special constant value REPRODUCIBLE_BUILD_STATIC_DATE URL: https://github.com/apache/maven-archiver/pull/72 -- 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MJAR-314) Use a predefined constant for project.build.outputTimestamp
[
https://issues.apache.org/jira/browse/MJAR-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888430#comment-17888430
]
Sergey Ponomarev commented on MJAR-314:
---
The issue can be closed as WONTFIX
> Use a predefined constant for project.build.outputTimestamp
> ---
>
> Key: MJAR-314
> URL: https://issues.apache.org/jira/browse/MJAR-314
> Project: Maven JAR Plugin
> Issue Type: Improvement
>Reporter: Sergey Ponomarev
>Priority: Major
>
> The "Configuring for Reproducible Builds" guide shows and example how to
> specify a static outputTimestamp:
>
> 2023-01-01T00:00:00Z
> The date inside is really doesn't matter and I used the property as is but
> was afraid of being asked on a review why the 2023 year was used so used the
> current year.
> But still during a review I was asked:
> bq. these changes are likely going to confuse future developers ("This date
> shouldn't be static! Lets make it a variable!").
> The Gradle has an option preserveFileTimestamps = false that will just put 1
> Feb 1980 as a date. The 1 Jan 1980 is a minimal date in Zip archive but the 1
> Jan has some special treatment by Java that's why the Gradle team used the 1
> Feb.
> See more detailed description in CONSTANT_TIME_FOR_ZIP_ENTRIES
> https://github.com/gradle/gradle/blob/master/platforms/core-runtime/files/src/main/java/org/gradle/api/internal/file/archive/ZipEntryConstants.java#L39
> I don't think it worth to declare some new property e.g.
> true
> But we can simply make a special constant value like:
>
> REPRODUCIBLE_BUILD_STATIC_DATE
> Then the constant will be replaced with the same 1 Feb 1980 to be similar
> with Gradle produced artifacts.
> This constant should make it more clear intention of the outputTimestamp but
> also easier to find an explanation for this.
> The outputTimestamp parsing is performed in the maven-archiver but the
> maven-compiler-plugin and maven-jar-plugin would need to update a JavaDoc for
> the outputTimestamp config option
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
