[GitHub] [maven-integration-testing] slawekjaranowski commented on pull request #164: Upgrade maven-verifier to 1.8.0
slawekjaranowski commented on PR #164: URL: https://github.com/apache/maven-integration-testing/pull/164#issuecomment-1131312675 When we create branch with the same name in Maven core build will be triggered 😄 https://github.com/apache/maven/actions?query=branch%3Amaven-verifier-1.8.0 -- 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
[GitHub] [maven-build-cache-extension] gnodet opened a new pull request, #18: Disable jdk 8 on jenkins
gnodet opened a new pull request, #18: URL: https://github.com/apache/maven-build-cache-extension/pull/18 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/MNG) 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 `[MNG-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MNG-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 [Core IT][core-its] successfully. 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). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- 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
[GitHub] [maven-build-cache-extension] cstamas commented on pull request #7: Broken Link: Usage of .md causes apache.org documentation 404
cstamas commented on PR #7: URL: https://github.com/apache/maven-build-cache-extension/pull/7#issuecomment-1131351521 -1 it should be `remote-cache.html` -- 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
[GitHub] [maven-build-cache-extension] gnodet opened a new pull request, #19: Add an IT for remote build cache using webdav
gnodet opened a new pull request, #19: URL: https://github.com/apache/maven-build-cache-extension/pull/19 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/MNG) 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 `[MNG-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MNG-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 [Core IT][core-its] successfully. 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). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- 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
[GitHub] [maven-build-cache-extension] gnodet merged pull request #18: Disable jdk 8 on jenkins
gnodet merged PR #18: URL: https://github.com/apache/maven-build-cache-extension/pull/18 -- 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-7480) Profile option doesn't activate selected profile
Yury Remishevsky created MNG-7480:
-
Summary: Profile option doesn't activate selected profile
Key: MNG-7480
URL: https://issues.apache.org/jira/browse/MNG-7480
Project: Maven
Issue Type: Bug
Components: Profiles
Affects Versions: 3.8.5
Reporter: Yury Remishevsky
Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
# Steps to reproduce
On project
[https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
# install maven 3.8.5
# mvn --version -> 3.8.5
# mvn clean package -P postgresql | grep usePersistence produces build with
out required dependencies ->
AddonsConfig{usePersistence={color:#FF}false{color}
On maven 3.8.1
# mvn clean package -P postgresql | grep usePersistence produces build with
expected dependencies -> AddonsConfig{usePersistence={color:#FF}true{color}
{color:#172b4d}# Expected behavior{color}
{color:#172b4d}Using mvn clean package -P profile explicitly activates profile
"profile" as stated in
[https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
{quote}Profiles can be explicitly specified using the {{-P}} command line flag.
This flag is followed by a comma-delimited list of profile IDs to use. The
profile(s) specified in the option are activated in addition to any profiles
which are activated by their activation configuration or the
{{}} section in {{{}settings.xml{}}}.
{quote}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-build-cache-extension] gnodet commented on pull request #7: Broken Link: Usage of .md causes apache.org documentation 404
gnodet commented on PR #7: URL: https://github.com/apache/maven-build-cache-extension/pull/7#issuecomment-1131365087 > Just change the extension from `md` to `html` You mean rename the files in the git repo ? -- 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-7480) Profile option doesn't activate selected profile
[
https://issues.apache.org/jira/browse/MNG-7480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Remishevsky updated MNG-7480:
--
Description:
Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
# Steps to reproduce
On project
[https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
# install maven 3.8.5
# mvn --version -> 3.8.5
# mvn clean package -P postgresql | grep usePersistence produces build with
out required dependencies ->
AddonsConfig{usePersistence={color:#ff}false{color}
For e.g. maven 3.8.1
# mvn clean package -P postgresql | grep usePersistence produces build with
expected dependencies -> AddonsConfig{usePersistence={color:#ff}true{color}
{color:#172b4d}# Expected behavior{color}
{color:#172b4d}Using mvn clean package -P profile explicitly activates profile
"profile" as stated in
[https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
{quote}Profiles can be explicitly specified using the {{-P}} command line flag.
This flag is followed by a comma-delimited list of profile IDs to use. The
profile(s) specified in the option are activated in addition to any profiles
which are activated by their activation configuration or the
{{}} section in {{{}settings.xml{}}}.
{quote}
was:
Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
# Steps to reproduce
On project
[https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
# install maven 3.8.5
# mvn --version -> 3.8.5
# mvn clean package -P postgresql | grep usePersistence produces build with
out required dependencies ->
AddonsConfig{usePersistence={color:#FF}false{color}
On maven 3.8.1
# mvn clean package -P postgresql | grep usePersistence produces build with
expected dependencies -> AddonsConfig{usePersistence={color:#FF}true{color}
{color:#172b4d}# Expected behavior{color}
{color:#172b4d}Using mvn clean package -P profile explicitly activates profile
"profile" as stated in
[https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
{quote}Profiles can be explicitly specified using the {{-P}} command line flag.
This flag is followed by a comma-delimited list of profile IDs to use. The
profile(s) specified in the option are activated in addition to any profiles
which are activated by their activation configuration or the
{{}} section in {{{}settings.xml{}}}.
{quote}
> Profile option doesn't activate selected profile
>
>
> Key: MNG-7480
> URL: https://issues.apache.org/jira/browse/MNG-7480
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.8.5
>Reporter: Yury Remishevsky
>Priority: Major
>
> Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
> # Steps to reproduce
> On project
> [https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
> # install maven 3.8.5
> # mvn --version -> 3.8.5
> # mvn clean package -P postgresql | grep usePersistence produces build with
> out required dependencies ->
> AddonsConfig{usePersistence={color:#ff}false{color}
> For e.g. maven 3.8.1
> # mvn clean package -P postgresql | grep usePersistence produces build with
> expected dependencies ->
> AddonsConfig{usePersistence={color:#ff}true{color}
> {color:#172b4d}# Expected behavior{color}
> {color:#172b4d}Using mvn clean package -P profile explicitly activates
> profile "profile" as stated in
> [https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
> {quote}Profiles can be explicitly specified using the {{-P}} command line
> flag.
> This flag is followed by a comma-delimited list of profile IDs to use. The
> profile(s) specified in the option are activated in addition to any profiles
> which are activated by their activation configuration or the
> {{}} section in {{{}settings.xml{}}}.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MNG-7480) Profile option doesn't activate selected profile
[
https://issues.apache.org/jira/browse/MNG-7480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Remishevsky updated MNG-7480:
--
Description:
Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
# Steps to reproduce
On project
[https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
# install maven 3.8.5
# mvn --version -> 3.8.5
# mvn clean package -P postgresql | grep usePersistence produces build with
out required dependencies ->
AddonsConfig{usePersistence={color:#ff}false{color}
For e.g. on maven 3.8.1
# mvn clean package -P postgresql | grep usePersistence produces build with
expected dependencies -> AddonsConfig{usePersistence={color:#ff}true{color}
{color:#172b4d}# Expected behavior{color}
{color:#172b4d}Using mvn clean package -P profile explicitly activates profile
"profile" as stated in
[https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
{quote}Profiles can be explicitly specified using the {{-P}} command line flag.
This flag is followed by a comma-delimited list of profile IDs to use. The
profile(s) specified in the option are activated in addition to any profiles
which are activated by their activation configuration or the
{{}} section in {{{}settings.xml{}}}.
{quote}
was:
Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
# Steps to reproduce
On project
[https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
# install maven 3.8.5
# mvn --version -> 3.8.5
# mvn clean package -P postgresql | grep usePersistence produces build with
out required dependencies ->
AddonsConfig{usePersistence={color:#ff}false{color}
For e.g. maven 3.8.1
# mvn clean package -P postgresql | grep usePersistence produces build with
expected dependencies -> AddonsConfig{usePersistence={color:#ff}true{color}
{color:#172b4d}# Expected behavior{color}
{color:#172b4d}Using mvn clean package -P profile explicitly activates profile
"profile" as stated in
[https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
{quote}Profiles can be explicitly specified using the {{-P}} command line flag.
This flag is followed by a comma-delimited list of profile IDs to use. The
profile(s) specified in the option are activated in addition to any profiles
which are activated by their activation configuration or the
{{}} section in {{{}settings.xml{}}}.
{quote}
> Profile option doesn't activate selected profile
>
>
> Key: MNG-7480
> URL: https://issues.apache.org/jira/browse/MNG-7480
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.8.5
>Reporter: Yury Remishevsky
>Priority: Major
>
> Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
> # Steps to reproduce
> On project
> [https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
> # install maven 3.8.5
> # mvn --version -> 3.8.5
> # mvn clean package -P postgresql | grep usePersistence produces build with
> out required dependencies ->
> AddonsConfig{usePersistence={color:#ff}false{color}
> For e.g. on maven 3.8.1
> # mvn clean package -P postgresql | grep usePersistence produces build with
> expected dependencies ->
> AddonsConfig{usePersistence={color:#ff}true{color}
> {color:#172b4d}# Expected behavior{color}
> {color:#172b4d}Using mvn clean package -P profile explicitly activates
> profile "profile" as stated in
> [https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
> {quote}Profiles can be explicitly specified using the {{-P}} command line
> flag.
> This flag is followed by a comma-delimited list of profile IDs to use. The
> profile(s) specified in the option are activated in addition to any profiles
> which are activated by their activation configuration or the
> {{}} section in {{{}settings.xml{}}}.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MNG-7480) Profile option doesn't activate selected profile
[
https://issues.apache.org/jira/browse/MNG-7480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Remishevsky updated MNG-7480:
--
Description:
Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
# Steps to reproduce
On project
[https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
# install maven 3.8.5
# mvn --version -> 3.8.5
# mvn clean package -P postgresql | grep usePersistence produces build with
out required dependencies ->
AddonsConfig{usePersistence={color:#ff}false{color}
For e.g. on maven 3.8.1
# mvn clean package -P postgresql | grep usePersistence produces build with
expected dependencies -> AddonsConfig{usePersistence={color:#ff}true{color}
{color:#172b4d}# Expected behavior{color}
{color:#172b4d}Using mvn clean package -P profile explicitly activates profile
"profile" as stated in
[https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
{quote}Profiles can be explicitly specified using the {{-P}} command line flag.
This flag is followed by a comma-delimited list of profile IDs to use. The
profile(s) specified in the option are activated in addition to any profiles
which are activated by their activation configuration or the
{{}} section in {{{}settings.xml{}}}.
{quote}
was:
Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
# Steps to reproduce
On project
[https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
# install maven 3.8.5
# mvn --version -> 3.8.5
# mvn clean package -P postgresql | grep usePersistence produces build with
out required dependencies ->
AddonsConfig{usePersistence={color:#ff}false{color}
For e.g. on maven 3.8.1
# mvn clean package -P postgresql | grep usePersistence produces build with
expected dependencies -> AddonsConfig{usePersistence={color:#ff}true{color}
{color:#172b4d}# Expected behavior{color}
{color:#172b4d}Using mvn clean package -P profile explicitly activates profile
"profile" as stated in
[https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
{quote}Profiles can be explicitly specified using the {{-P}} command line flag.
This flag is followed by a comma-delimited list of profile IDs to use. The
profile(s) specified in the option are activated in addition to any profiles
which are activated by their activation configuration or the
{{}} section in {{{}settings.xml{}}}.
{quote}
> Profile option doesn't activate selected profile
>
>
> Key: MNG-7480
> URL: https://issues.apache.org/jira/browse/MNG-7480
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.8.5
>Reporter: Yury Remishevsky
>Priority: Major
>
> Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
> # Steps to reproduce
> On project
> [https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
> # install maven 3.8.5
> # mvn --version -> 3.8.5
> # mvn clean package -P postgresql | grep usePersistence produces build with
> out required dependencies ->
> AddonsConfig{usePersistence={color:#ff}false{color}
> For e.g. on maven 3.8.1
> # mvn clean package -P postgresql | grep usePersistence produces build with
> expected dependencies ->
> AddonsConfig{usePersistence={color:#ff}true{color}
> {color:#172b4d}# Expected behavior{color}
> {color:#172b4d}Using mvn clean package -P profile explicitly activates
> profile "profile" as stated in
> [https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
> {quote}Profiles can be explicitly specified using the {{-P}} command line
> flag.
> This flag is followed by a comma-delimited list of profile IDs to use. The
> profile(s) specified in the option are activated in addition to any profiles
> which are activated by their activation configuration or the
> {{}} section in {{{}settings.xml{}}}.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MNG-7480) Profile option doesn't activate selected profile
[
https://issues.apache.org/jira/browse/MNG-7480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Remishevsky updated MNG-7480:
--
Description:
Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
*Steps to reproduce*
On project
[https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
# install maven 3.8.5
# mvn --version -> 3.8.5
# mvn clean package -P postgresql | grep usePersistence produces build with
out required dependencies ->
AddonsConfig{usePersistence={color:#ff}false{color}
For e.g. on maven 3.8.1
# mvn clean package -P postgresql | grep usePersistence produces build with
expected dependencies -> AddonsConfig{usePersistence={color:#ff}true{color}
*{color:#172b4d}Expected behavior{color}*
{color:#172b4d}Using mvn clean package -P profile explicitly activates profile
"profile" as stated in
[https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
{quote}Profiles can be explicitly specified using the {{-P}} command line flag.
This flag is followed by a comma-delimited list of profile IDs to use. The
profile(s) specified in the option are activated in addition to any profiles
which are activated by their activation configuration or the
{{}} section in {{{}settings.xml{}}}.
{quote}
was:
Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
# Steps to reproduce
On project
[https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
# install maven 3.8.5
# mvn --version -> 3.8.5
# mvn clean package -P postgresql | grep usePersistence produces build with
out required dependencies ->
AddonsConfig{usePersistence={color:#ff}false{color}
For e.g. on maven 3.8.1
# mvn clean package -P postgresql | grep usePersistence produces build with
expected dependencies -> AddonsConfig{usePersistence={color:#ff}true{color}
{color:#172b4d}# Expected behavior{color}
{color:#172b4d}Using mvn clean package -P profile explicitly activates profile
"profile" as stated in
[https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
{quote}Profiles can be explicitly specified using the {{-P}} command line flag.
This flag is followed by a comma-delimited list of profile IDs to use. The
profile(s) specified in the option are activated in addition to any profiles
which are activated by their activation configuration or the
{{}} section in {{{}settings.xml{}}}.
{quote}
> Profile option doesn't activate selected profile
>
>
> Key: MNG-7480
> URL: https://issues.apache.org/jira/browse/MNG-7480
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.8.5
>Reporter: Yury Remishevsky
>Priority: Major
>
> Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
> *Steps to reproduce*
> On project
> [https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
> # install maven 3.8.5
> # mvn --version -> 3.8.5
> # mvn clean package -P postgresql | grep usePersistence produces build with
> out required dependencies ->
> AddonsConfig{usePersistence={color:#ff}false{color}
> For e.g. on maven 3.8.1
> # mvn clean package -P postgresql | grep usePersistence produces build with
> expected dependencies ->
> AddonsConfig{usePersistence={color:#ff}true{color}
> *{color:#172b4d}Expected behavior{color}*
> {color:#172b4d}Using mvn clean package -P profile explicitly activates
> profile "profile" as stated in
> [https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
> {quote}Profiles can be explicitly specified using the {{-P}} command line
> flag.
> This flag is followed by a comma-delimited list of profile IDs to use. The
> profile(s) specified in the option are activated in addition to any profiles
> which are activated by their activation configuration or the
> {{}} section in {{{}settings.xml{}}}.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-build-cache-extension] gnodet merged pull request #17: Remove build warning
gnodet merged PR #17: URL: https://github.com/apache/maven-build-cache-extension/pull/17 -- 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-7480) Profile option doesn't activate selected profile
[
https://issues.apache.org/jira/browse/MNG-7480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Remishevsky updated MNG-7480:
--
Description:
Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
*Steps to reproduce*
On project
[https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
# install maven 3.8.5
# mvn --version -> 3.8.5
# mvn clean package -P postgresql | grep usePersistence produces build with
out required dependencies ->
AddonsConfig{usePersistence={color:#ff}false{color}
For e.g. on maven 3.8.1
# mvn clean package -P postgresql | grep usePersistence produces build with
expected dependencies -> AddonsConfig{usePersistence={color:#ff}true{color}
*{color:#172b4d}Expected behavior{color}*
{color:#172b4d}Using mvn clean package -P profile explicitly activates profile
"profile" as stated in
[https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
{quote}Profiles can be explicitly specified using the {{-P}} command line flag.
This flag is followed by a comma-delimited list of profile IDs to use. The
profile(s) specified in the option are activated in addition to any profiles
which are activated by their activation configuration or the
{{}} section in {{{}settings.xml{}}}.
{quote}
*System info*
[INFO] Detecting the operating system and CPU architecture
[INFO]
[INFO] os.detected.name: linux
[INFO] os.detected.arch: x86_64
[INFO] os.detected.version: 5.17
[INFO] os.detected.version.major: 5
[INFO] os.detected.version.minor: 17
[INFO] os.detected.release: fedora
[INFO] os.detected.release.version: 36
[INFO] os.detected.release.like.fedora: true
[INFO] os.detected.classifier: linux-x86_64
openjdk 18.0.1 2022-04-19
OpenJDK Runtime Environment Homebrew (build 18.0.1+0)
OpenJDK 64-Bit Server VM Homebrew (build 18.0.1+0, mixed mode, sharing)
was:
Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
*Steps to reproduce*
On project
[https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
# install maven 3.8.5
# mvn --version -> 3.8.5
# mvn clean package -P postgresql | grep usePersistence produces build with
out required dependencies ->
AddonsConfig{usePersistence={color:#ff}false{color}
For e.g. on maven 3.8.1
# mvn clean package -P postgresql | grep usePersistence produces build with
expected dependencies -> AddonsConfig{usePersistence={color:#ff}true{color}
*{color:#172b4d}Expected behavior{color}*
{color:#172b4d}Using mvn clean package -P profile explicitly activates profile
"profile" as stated in
[https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
{quote}Profiles can be explicitly specified using the {{-P}} command line flag.
This flag is followed by a comma-delimited list of profile IDs to use. The
profile(s) specified in the option are activated in addition to any profiles
which are activated by their activation configuration or the
{{}} section in {{{}settings.xml{}}}.
{quote}
> Profile option doesn't activate selected profile
>
>
> Key: MNG-7480
> URL: https://issues.apache.org/jira/browse/MNG-7480
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.8.5
>Reporter: Yury Remishevsky
>Priority: Major
>
> Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
> *Steps to reproduce*
> On project
> [https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
> # install maven 3.8.5
> # mvn --version -> 3.8.5
> # mvn clean package -P postgresql | grep usePersistence produces build with
> out required dependencies ->
> AddonsConfig{usePersistence={color:#ff}false{color}
> For e.g. on maven 3.8.1
> # mvn clean package -P postgresql | grep usePersistence produces build with
> expected dependencies ->
> AddonsConfig{usePersistence={color:#ff}true{color}
> *{color:#172b4d}Expected behavior{color}*
> {color:#172b4d}Using mvn clean package -P profile explicitly activates
> profile "profile" as stated in
> [https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
> {quote}Profiles can be explicitly specified using the {{-P}} command line
> flag.
> This flag is followed by a comma-delimited list of profile IDs to use. The
> profile(s) specified in the option are activated in addition to any profiles
> which are activated by their activation configuration or the
> {{}} section in {{{}settings.xml{}}}.
> {quote}
> *System info*
> [INFO] Detecting the operating system and CPU architecture
> [INFO]
>
> [INFO
[GitHub] [maven-build-cache-extension] gnodet merged pull request #16: Ability to specify the build cache location
gnodet merged PR #16: URL: https://github.com/apache/maven-build-cache-extension/pull/16 -- 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
[GitHub] [maven-build-cache-extension] dependabot[bot] opened a new pull request, #20: Bump commons-io from 1.3.2 to 2.7
dependabot[bot] opened a new pull request, #20: URL: https://github.com/apache/maven-build-cache-extension/pull/20 Bumps commons-io from 1.3.2 to 2.7. [](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 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) - `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language - `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language - `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language - `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/apache/maven-build-cache-extension/network/alerts). -- 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-7480) Profile option doesn't activate selected profile
[
https://issues.apache.org/jira/browse/MNG-7480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539391#comment-17539391
]
Slawomir Jaranowski commented on MNG-7480:
--
Please try, and show output:
{code:java}
mvn -V help:all-profiles -P postgresql
{code}
{code:java}
mvn -V help:active-profiles -P postgresql
{code}
> Profile option doesn't activate selected profile
>
>
> Key: MNG-7480
> URL: https://issues.apache.org/jira/browse/MNG-7480
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.8.5
>Reporter: Yury Remishevsky
>Priority: Major
>
> Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
> *Steps to reproduce*
> On project
> [https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
> # install maven 3.8.5
> # mvn --version -> 3.8.5
> # mvn clean package -P postgresql | grep usePersistence produces build with
> out required dependencies ->
> AddonsConfig{usePersistence={color:#ff}false{color}
> For e.g. on maven 3.8.1
> # mvn clean package -P postgresql | grep usePersistence produces build with
> expected dependencies ->
> AddonsConfig{usePersistence={color:#ff}true{color}
> *{color:#172b4d}Expected behavior{color}*
> {color:#172b4d}Using mvn clean package -P profile explicitly activates
> profile "profile" as stated in
> [https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
> {quote}Profiles can be explicitly specified using the {{-P}} command line
> flag.
> This flag is followed by a comma-delimited list of profile IDs to use. The
> profile(s) specified in the option are activated in addition to any profiles
> which are activated by their activation configuration or the
> {{}} section in {{{}settings.xml{}}}.
> {quote}
> *System info*
> [INFO] Detecting the operating system and CPU architecture
> [INFO]
>
> [INFO] os.detected.name: linux
> [INFO] os.detected.arch: x86_64
> [INFO] os.detected.version: 5.17
> [INFO] os.detected.version.major: 5
> [INFO] os.detected.version.minor: 17
> [INFO] os.detected.release: fedora
> [INFO] os.detected.release.version: 36
> [INFO] os.detected.release.like.fedora: true
> [INFO] os.detected.classifier: linux-x86_64
> openjdk 18.0.1 2022-04-19
> OpenJDK Runtime Environment Homebrew (build 18.0.1+0)
> OpenJDK 64-Bit Server VM Homebrew (build 18.0.1+0, mixed mode, sharing)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-7480) Profile option doesn't activate selected profile
[
https://issues.apache.org/jira/browse/MNG-7480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539395#comment-17539395
]
Yury Remishevsky commented on MNG-7480:
---
mvn -V help:all-profiles -P postgresql
[^log-all.log]
mvn -V help:active-profiles -P postgresql
[^log-active.log]
> Profile option doesn't activate selected profile
>
>
> Key: MNG-7480
> URL: https://issues.apache.org/jira/browse/MNG-7480
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.8.5
>Reporter: Yury Remishevsky
>Priority: Major
> Attachments: log-active.log, log-all.log
>
>
> Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
> *Steps to reproduce*
> On project
> [https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
> # install maven 3.8.5
> # mvn --version -> 3.8.5
> # mvn clean package -P postgresql | grep usePersistence produces build with
> out required dependencies ->
> AddonsConfig{usePersistence={color:#ff}false{color}
> For e.g. on maven 3.8.1
> # mvn clean package -P postgresql | grep usePersistence produces build with
> expected dependencies ->
> AddonsConfig{usePersistence={color:#ff}true{color}
> *{color:#172b4d}Expected behavior{color}*
> {color:#172b4d}Using mvn clean package -P profile explicitly activates
> profile "profile" as stated in
> [https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
> {quote}Profiles can be explicitly specified using the {{-P}} command line
> flag.
> This flag is followed by a comma-delimited list of profile IDs to use. The
> profile(s) specified in the option are activated in addition to any profiles
> which are activated by their activation configuration or the
> {{}} section in {{{}settings.xml{}}}.
> {quote}
> *System info*
> [INFO] Detecting the operating system and CPU architecture
> [INFO]
>
> [INFO] os.detected.name: linux
> [INFO] os.detected.arch: x86_64
> [INFO] os.detected.version: 5.17
> [INFO] os.detected.version.major: 5
> [INFO] os.detected.version.minor: 17
> [INFO] os.detected.release: fedora
> [INFO] os.detected.release.version: 36
> [INFO] os.detected.release.like.fedora: true
> [INFO] os.detected.classifier: linux-x86_64
> openjdk 18.0.1 2022-04-19
> OpenJDK Runtime Environment Homebrew (build 18.0.1+0)
> OpenJDK 64-Bit Server VM Homebrew (build 18.0.1+0, mixed mode, sharing)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MNG-7480) Profile option doesn't activate selected profile
[
https://issues.apache.org/jira/browse/MNG-7480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Remishevsky updated MNG-7480:
--
Attachment: log-all.log
> Profile option doesn't activate selected profile
>
>
> Key: MNG-7480
> URL: https://issues.apache.org/jira/browse/MNG-7480
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.8.5
>Reporter: Yury Remishevsky
>Priority: Major
> Attachments: log-active.log, log-all.log
>
>
> Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
> *Steps to reproduce*
> On project
> [https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
> # install maven 3.8.5
> # mvn --version -> 3.8.5
> # mvn clean package -P postgresql | grep usePersistence produces build with
> out required dependencies ->
> AddonsConfig{usePersistence={color:#ff}false{color}
> For e.g. on maven 3.8.1
> # mvn clean package -P postgresql | grep usePersistence produces build with
> expected dependencies ->
> AddonsConfig{usePersistence={color:#ff}true{color}
> *{color:#172b4d}Expected behavior{color}*
> {color:#172b4d}Using mvn clean package -P profile explicitly activates
> profile "profile" as stated in
> [https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
> {quote}Profiles can be explicitly specified using the {{-P}} command line
> flag.
> This flag is followed by a comma-delimited list of profile IDs to use. The
> profile(s) specified in the option are activated in addition to any profiles
> which are activated by their activation configuration or the
> {{}} section in {{{}settings.xml{}}}.
> {quote}
> *System info*
> [INFO] Detecting the operating system and CPU architecture
> [INFO]
>
> [INFO] os.detected.name: linux
> [INFO] os.detected.arch: x86_64
> [INFO] os.detected.version: 5.17
> [INFO] os.detected.version.major: 5
> [INFO] os.detected.version.minor: 17
> [INFO] os.detected.release: fedora
> [INFO] os.detected.release.version: 36
> [INFO] os.detected.release.like.fedora: true
> [INFO] os.detected.classifier: linux-x86_64
> openjdk 18.0.1 2022-04-19
> OpenJDK Runtime Environment Homebrew (build 18.0.1+0)
> OpenJDK 64-Bit Server VM Homebrew (build 18.0.1+0, mixed mode, sharing)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MNG-7480) Profile option doesn't activate selected profile
[
https://issues.apache.org/jira/browse/MNG-7480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Remishevsky updated MNG-7480:
--
Attachment: log-active.log
> Profile option doesn't activate selected profile
>
>
> Key: MNG-7480
> URL: https://issues.apache.org/jira/browse/MNG-7480
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.8.5
>Reporter: Yury Remishevsky
>Priority: Major
> Attachments: log-active.log, log-all.log
>
>
> Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
> *Steps to reproduce*
> On project
> [https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
> # install maven 3.8.5
> # mvn --version -> 3.8.5
> # mvn clean package -P postgresql | grep usePersistence produces build with
> out required dependencies ->
> AddonsConfig{usePersistence={color:#ff}false{color}
> For e.g. on maven 3.8.1
> # mvn clean package -P postgresql | grep usePersistence produces build with
> expected dependencies ->
> AddonsConfig{usePersistence={color:#ff}true{color}
> *{color:#172b4d}Expected behavior{color}*
> {color:#172b4d}Using mvn clean package -P profile explicitly activates
> profile "profile" as stated in
> [https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
> {quote}Profiles can be explicitly specified using the {{-P}} command line
> flag.
> This flag is followed by a comma-delimited list of profile IDs to use. The
> profile(s) specified in the option are activated in addition to any profiles
> which are activated by their activation configuration or the
> {{}} section in {{{}settings.xml{}}}.
> {quote}
> *System info*
> [INFO] Detecting the operating system and CPU architecture
> [INFO]
>
> [INFO] os.detected.name: linux
> [INFO] os.detected.arch: x86_64
> [INFO] os.detected.version: 5.17
> [INFO] os.detected.version.major: 5
> [INFO] os.detected.version.minor: 17
> [INFO] os.detected.release: fedora
> [INFO] os.detected.release.version: 36
> [INFO] os.detected.release.like.fedora: true
> [INFO] os.detected.classifier: linux-x86_64
> openjdk 18.0.1 2022-04-19
> OpenJDK Runtime Environment Homebrew (build 18.0.1+0)
> OpenJDK 64-Bit Server VM Homebrew (build 18.0.1+0, mixed mode, sharing)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (MNG-7480) Profile option doesn't activate selected profile
[
https://issues.apache.org/jira/browse/MNG-7480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539395#comment-17539395
]
Yury Remishevsky edited comment on MNG-7480 at 5/19/22 8:24 AM:
mvn -V help:all-profiles -P postgresql
[^log-all.log]
mvn -V help:active-profiles -P postgresql
[^log-active.log]
full build log
was (Author: yremishevsky):
mvn -V help:all-profiles -P postgresql
[^log-all.log]
mvn -V help:active-profiles -P postgresql
[^log-active.log]
> Profile option doesn't activate selected profile
>
>
> Key: MNG-7480
> URL: https://issues.apache.org/jira/browse/MNG-7480
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.8.5
>Reporter: Yury Remishevsky
>Priority: Major
> Attachments: log-active.log, log-all.log
>
>
> Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
> *Steps to reproduce*
> On project
> [https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
> # install maven 3.8.5
> # mvn --version -> 3.8.5
> # mvn clean package -P postgresql | grep usePersistence produces build with
> out required dependencies ->
> AddonsConfig{usePersistence={color:#ff}false{color}
> For e.g. on maven 3.8.1
> # mvn clean package -P postgresql | grep usePersistence produces build with
> expected dependencies ->
> AddonsConfig{usePersistence={color:#ff}true{color}
> *{color:#172b4d}Expected behavior{color}*
> {color:#172b4d}Using mvn clean package -P profile explicitly activates
> profile "profile" as stated in
> [https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
> {quote}Profiles can be explicitly specified using the {{-P}} command line
> flag.
> This flag is followed by a comma-delimited list of profile IDs to use. The
> profile(s) specified in the option are activated in addition to any profiles
> which are activated by their activation configuration or the
> {{}} section in {{{}settings.xml{}}}.
> {quote}
> *System info*
> [INFO] Detecting the operating system and CPU architecture
> [INFO]
>
> [INFO] os.detected.name: linux
> [INFO] os.detected.arch: x86_64
> [INFO] os.detected.version: 5.17
> [INFO] os.detected.version.major: 5
> [INFO] os.detected.version.minor: 17
> [INFO] os.detected.release: fedora
> [INFO] os.detected.release.version: 36
> [INFO] os.detected.release.like.fedora: true
> [INFO] os.detected.classifier: linux-x86_64
> openjdk 18.0.1 2022-04-19
> OpenJDK Runtime Environment Homebrew (build 18.0.1+0)
> OpenJDK 64-Bit Server VM Homebrew (build 18.0.1+0, mixed mode, sharing)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (MNG-7480) Profile option doesn't activate selected profile
[
https://issues.apache.org/jira/browse/MNG-7480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539395#comment-17539395
]
Yury Remishevsky edited comment on MNG-7480 at 5/19/22 8:25 AM:
mvn -V help:all-profiles -P postgresql
[^log-all.log]
mvn -V help:active-profiles -P postgresql
[^log-active.log]
full build log
[^build.log]
was (Author: yremishevsky):
mvn -V help:all-profiles -P postgresql
[^log-all.log]
mvn -V help:active-profiles -P postgresql
[^log-active.log]
full build log
> Profile option doesn't activate selected profile
>
>
> Key: MNG-7480
> URL: https://issues.apache.org/jira/browse/MNG-7480
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.8.5
>Reporter: Yury Remishevsky
>Priority: Major
> Attachments: build.log, log-active.log, log-all.log
>
>
> Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
> *Steps to reproduce*
> On project
> [https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
> # install maven 3.8.5
> # mvn --version -> 3.8.5
> # mvn clean package -P postgresql | grep usePersistence produces build with
> out required dependencies ->
> AddonsConfig{usePersistence={color:#ff}false{color}
> For e.g. on maven 3.8.1
> # mvn clean package -P postgresql | grep usePersistence produces build with
> expected dependencies ->
> AddonsConfig{usePersistence={color:#ff}true{color}
> *{color:#172b4d}Expected behavior{color}*
> {color:#172b4d}Using mvn clean package -P profile explicitly activates
> profile "profile" as stated in
> [https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
> {quote}Profiles can be explicitly specified using the {{-P}} command line
> flag.
> This flag is followed by a comma-delimited list of profile IDs to use. The
> profile(s) specified in the option are activated in addition to any profiles
> which are activated by their activation configuration or the
> {{}} section in {{{}settings.xml{}}}.
> {quote}
> *System info*
> [INFO] Detecting the operating system and CPU architecture
> [INFO]
>
> [INFO] os.detected.name: linux
> [INFO] os.detected.arch: x86_64
> [INFO] os.detected.version: 5.17
> [INFO] os.detected.version.major: 5
> [INFO] os.detected.version.minor: 17
> [INFO] os.detected.release: fedora
> [INFO] os.detected.release.version: 36
> [INFO] os.detected.release.like.fedora: true
> [INFO] os.detected.classifier: linux-x86_64
> openjdk 18.0.1 2022-04-19
> OpenJDK Runtime Environment Homebrew (build 18.0.1+0)
> OpenJDK 64-Bit Server VM Homebrew (build 18.0.1+0, mixed mode, sharing)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MNG-7480) Profile option doesn't activate selected profile
[
https://issues.apache.org/jira/browse/MNG-7480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Remishevsky updated MNG-7480:
--
Attachment: build.log
> Profile option doesn't activate selected profile
>
>
> Key: MNG-7480
> URL: https://issues.apache.org/jira/browse/MNG-7480
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.8.5
>Reporter: Yury Remishevsky
>Priority: Major
> Attachments: build.log, log-active.log, log-all.log
>
>
> Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
> *Steps to reproduce*
> On project
> [https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
> # install maven 3.8.5
> # mvn --version -> 3.8.5
> # mvn clean package -P postgresql | grep usePersistence produces build with
> out required dependencies ->
> AddonsConfig{usePersistence={color:#ff}false{color}
> For e.g. on maven 3.8.1
> # mvn clean package -P postgresql | grep usePersistence produces build with
> expected dependencies ->
> AddonsConfig{usePersistence={color:#ff}true{color}
> *{color:#172b4d}Expected behavior{color}*
> {color:#172b4d}Using mvn clean package -P profile explicitly activates
> profile "profile" as stated in
> [https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
> {quote}Profiles can be explicitly specified using the {{-P}} command line
> flag.
> This flag is followed by a comma-delimited list of profile IDs to use. The
> profile(s) specified in the option are activated in addition to any profiles
> which are activated by their activation configuration or the
> {{}} section in {{{}settings.xml{}}}.
> {quote}
> *System info*
> [INFO] Detecting the operating system and CPU architecture
> [INFO]
>
> [INFO] os.detected.name: linux
> [INFO] os.detected.arch: x86_64
> [INFO] os.detected.version: 5.17
> [INFO] os.detected.version.major: 5
> [INFO] os.detected.version.minor: 17
> [INFO] os.detected.release: fedora
> [INFO] os.detected.release.version: 36
> [INFO] os.detected.release.like.fedora: true
> [INFO] os.detected.classifier: linux-x86_64
> openjdk 18.0.1 2022-04-19
> OpenJDK Runtime Environment Homebrew (build 18.0.1+0)
> OpenJDK 64-Bit Server VM Homebrew (build 18.0.1+0, mixed mode, sharing)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MNG-7480) Profile option doesn't activate selected profile
[
https://issues.apache.org/jira/browse/MNG-7480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Remishevsky updated MNG-7480:
--
Attachment: debug.log
> Profile option doesn't activate selected profile
>
>
> Key: MNG-7480
> URL: https://issues.apache.org/jira/browse/MNG-7480
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.8.5
>Reporter: Yury Remishevsky
>Priority: Major
> Attachments: build.log, debug.log, log-active.log, log-all.log
>
>
> Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
> *Steps to reproduce*
> On project
> [https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
> # install maven 3.8.5
> # mvn --version -> 3.8.5
> # mvn clean package -P postgresql | grep usePersistence produces build with
> out required dependencies ->
> AddonsConfig{usePersistence={color:#ff}false{color}
> For e.g. on maven 3.8.1
> # mvn clean package -P postgresql | grep usePersistence produces build with
> expected dependencies ->
> AddonsConfig{usePersistence={color:#ff}true{color}
> *{color:#172b4d}Expected behavior{color}*
> {color:#172b4d}Using mvn clean package -P profile explicitly activates
> profile "profile" as stated in
> [https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
> {quote}Profiles can be explicitly specified using the {{-P}} command line
> flag.
> This flag is followed by a comma-delimited list of profile IDs to use. The
> profile(s) specified in the option are activated in addition to any profiles
> which are activated by their activation configuration or the
> {{}} section in {{{}settings.xml{}}}.
> {quote}
> *System info*
> [INFO] Detecting the operating system and CPU architecture
> [INFO]
>
> [INFO] os.detected.name: linux
> [INFO] os.detected.arch: x86_64
> [INFO] os.detected.version: 5.17
> [INFO] os.detected.version.major: 5
> [INFO] os.detected.version.minor: 17
> [INFO] os.detected.release: fedora
> [INFO] os.detected.release.version: 36
> [INFO] os.detected.release.like.fedora: true
> [INFO] os.detected.classifier: linux-x86_64
> openjdk 18.0.1 2022-04-19
> OpenJDK Runtime Environment Homebrew (build 18.0.1+0)
> OpenJDK 64-Bit Server VM Homebrew (build 18.0.1+0, mixed mode, sharing)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (MNG-7480) Profile option doesn't activate selected profile
[
https://issues.apache.org/jira/browse/MNG-7480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539395#comment-17539395
]
Yury Remishevsky edited comment on MNG-7480 at 5/19/22 8:30 AM:
mvn -V help:all-profiles -P postgresql
[^log-all.log]
mvn -V help:active-profiles -P postgresql
[^log-active.log]
full build log
[^build.log]
^debug log^
^[^debug.log]^
was (Author: yremishevsky):
mvn -V help:all-profiles -P postgresql
[^log-all.log]
mvn -V help:active-profiles -P postgresql
[^log-active.log]
full build log
[^build.log]
> Profile option doesn't activate selected profile
>
>
> Key: MNG-7480
> URL: https://issues.apache.org/jira/browse/MNG-7480
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.8.5
>Reporter: Yury Remishevsky
>Priority: Major
> Attachments: build.log, debug.log, log-active.log, log-all.log
>
>
> Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
> *Steps to reproduce*
> On project
> [https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
> # install maven 3.8.5
> # mvn --version -> 3.8.5
> # mvn clean package -P postgresql | grep usePersistence produces build with
> out required dependencies ->
> AddonsConfig{usePersistence={color:#ff}false{color}
> For e.g. on maven 3.8.1
> # mvn clean package -P postgresql | grep usePersistence produces build with
> expected dependencies ->
> AddonsConfig{usePersistence={color:#ff}true{color}
> *{color:#172b4d}Expected behavior{color}*
> {color:#172b4d}Using mvn clean package -P profile explicitly activates
> profile "profile" as stated in
> [https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
> {quote}Profiles can be explicitly specified using the {{-P}} command line
> flag.
> This flag is followed by a comma-delimited list of profile IDs to use. The
> profile(s) specified in the option are activated in addition to any profiles
> which are activated by their activation configuration or the
> {{}} section in {{{}settings.xml{}}}.
> {quote}
> *System info*
> [INFO] Detecting the operating system and CPU architecture
> [INFO]
>
> [INFO] os.detected.name: linux
> [INFO] os.detected.arch: x86_64
> [INFO] os.detected.version: 5.17
> [INFO] os.detected.version.major: 5
> [INFO] os.detected.version.minor: 17
> [INFO] os.detected.release: fedora
> [INFO] os.detected.release.version: 36
> [INFO] os.detected.release.like.fedora: true
> [INFO] os.detected.classifier: linux-x86_64
> openjdk 18.0.1 2022-04-19
> OpenJDK Runtime Environment Homebrew (build 18.0.1+0)
> OpenJDK 64-Bit Server VM Homebrew (build 18.0.1+0, mixed mode, sharing)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SCM-976) [GITEXE] Changelog does not work in if the user has defined a custom format.
[
https://issues.apache.org/jira/browse/SCM-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niels Basjes updated SCM-976:
-
Summary: [GITEXE] Changelog does not work in if the user has defined a
custom format. (was: [GITEXE] Changelog does not work in current versions of
git.)
> [GITEXE] Changelog does not work in if the user has defined a custom format.
>
>
> Key: SCM-976
> URL: https://issues.apache.org/jira/browse/SCM-976
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 2.0.0-M1
>Reporter: Niels Basjes
>Priority: Major
>
> Since a long time the headers for the output of "git whatchanged" have been
> changed, as a consequence there is no more output from this command.
> The reason is that the output of this command used to be something like this:
> {code}
> commit 2d22f2da71ef279c4759b1c09cdb8282b63f0cf6
> Author: Mark Struberg
> Date: 2007-11-24 01:10:06 +0100
> {code}
> yet currently it looks like this:
> {code}
> commit 4fc34cfa14f2e72506187b03a492ce55ed459d4c (HEAD -> master,
> origin/master, origin/HEAD)
> Author: Michael Osipov
> AuthorDate: 2022-01-08 21:02:12 +0100
> Commit: Michael Osipov
> CommitDate: 2022-01-08 21:02:12 +0100
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-scm] nielsbasjes commented on pull request #134: [SCM-976] GitExe Changelog works if the user has defined a custom format.
nielsbasjes commented on PR #134: URL: https://github.com/apache/maven-scm/pull/134#issuecomment-1131407062 @michael-o I agree, the title of the jira issue and the pull request were created at a moment I misunderstood the real problem at hand. Just now I have updated these titles to reflect what is really happening. Are you happy with what you see now? -- 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] (SCM-976) [GITEXE] Changelog does not work in if the user has defined a custom format.
[
https://issues.apache.org/jira/browse/SCM-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539408#comment-17539408
]
ASF GitHub Bot commented on SCM-976:
nielsbasjes commented on PR #134:
URL: https://github.com/apache/maven-scm/pull/134#issuecomment-1131407062
@michael-o I agree, the title of the jira issue and the pull request were
created at a moment I misunderstood the real problem at hand. Just now I have
updated these titles to reflect what is really happening. Are you happy with
what you see now?
> [GITEXE] Changelog does not work in if the user has defined a custom format.
>
>
> Key: SCM-976
> URL: https://issues.apache.org/jira/browse/SCM-976
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 2.0.0-M1
>Reporter: Niels Basjes
>Priority: Major
>
> Since a long time the headers for the output of "git whatchanged" have been
> changed, as a consequence there is no more output from this command.
> The reason is that the output of this command used to be something like this:
> {code}
> commit 2d22f2da71ef279c4759b1c09cdb8282b63f0cf6
> Author: Mark Struberg
> Date: 2007-11-24 01:10:06 +0100
> {code}
> yet currently it looks like this:
> {code}
> commit 4fc34cfa14f2e72506187b03a492ce55ed459d4c (HEAD -> master,
> origin/master, origin/HEAD)
> Author: Michael Osipov
> AuthorDate: 2022-01-08 21:02:12 +0100
> Commit: Michael Osipov
> CommitDate: 2022-01-08 21:02:12 +0100
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-7480) Profile option doesn't activate selected profile
[
https://issues.apache.org/jira/browse/MNG-7480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539409#comment-17539409
]
Slawomir Jaranowski commented on MNG-7480:
--
In your postgresql you have dependencies like:
{code}
io.quarkus
quarkus-reactive-pg-client
{code}
change to something unresolvable
{code}
io.quarkus
quarkus-reactive-pg-client-
{code}
and try:
{code}
mvn validate
mvn validate -P postgresql
{code}
> Profile option doesn't activate selected profile
>
>
> Key: MNG-7480
> URL: https://issues.apache.org/jira/browse/MNG-7480
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.8.5
>Reporter: Yury Remishevsky
>Priority: Major
> Attachments: build.log, debug.log, log-active.log, log-all.log
>
>
> Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
> *Steps to reproduce*
> On project
> [https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
> # install maven 3.8.5
> # mvn --version -> 3.8.5
> # mvn clean package -P postgresql | grep usePersistence produces build with
> out required dependencies ->
> AddonsConfig{usePersistence={color:#ff}false{color}
> For e.g. on maven 3.8.1
> # mvn clean package -P postgresql | grep usePersistence produces build with
> expected dependencies ->
> AddonsConfig{usePersistence={color:#ff}true{color}
> *{color:#172b4d}Expected behavior{color}*
> {color:#172b4d}Using mvn clean package -P profile explicitly activates
> profile "profile" as stated in
> [https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
> {quote}Profiles can be explicitly specified using the {{-P}} command line
> flag.
> This flag is followed by a comma-delimited list of profile IDs to use. The
> profile(s) specified in the option are activated in addition to any profiles
> which are activated by their activation configuration or the
> {{}} section in {{{}settings.xml{}}}.
> {quote}
> *System info*
> [INFO] Detecting the operating system and CPU architecture
> [INFO]
>
> [INFO] os.detected.name: linux
> [INFO] os.detected.arch: x86_64
> [INFO] os.detected.version: 5.17
> [INFO] os.detected.version.major: 5
> [INFO] os.detected.version.minor: 17
> [INFO] os.detected.release: fedora
> [INFO] os.detected.release.version: 36
> [INFO] os.detected.release.like.fedora: true
> [INFO] os.detected.classifier: linux-x86_64
> openjdk 18.0.1 2022-04-19
> OpenJDK Runtime Environment Homebrew (build 18.0.1+0)
> OpenJDK 64-Bit Server VM Homebrew (build 18.0.1+0, mixed mode, sharing)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (SCM-976) [GITEXE] Changelog does not work in if the user has defined a custom format.
[
https://issues.apache.org/jira/browse/SCM-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539414#comment-17539414
]
ASF GitHub Bot commented on SCM-976:
michael-o commented on PR #134:
URL: https://github.com/apache/maven-scm/pull/134#issuecomment-1131433420
Yes, I will move forward with this today
> [GITEXE] Changelog does not work in if the user has defined a custom format.
>
>
> Key: SCM-976
> URL: https://issues.apache.org/jira/browse/SCM-976
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 2.0.0-M1
>Reporter: Niels Basjes
>Priority: Major
>
> Since a long time the headers for the output of "git whatchanged" have been
> changed, as a consequence there is no more output from this command.
> The reason is that the output of this command used to be something like this:
> {code}
> commit 2d22f2da71ef279c4759b1c09cdb8282b63f0cf6
> Author: Mark Struberg
> Date: 2007-11-24 01:10:06 +0100
> {code}
> yet currently it looks like this:
> {code}
> commit 4fc34cfa14f2e72506187b03a492ce55ed459d4c (HEAD -> master,
> origin/master, origin/HEAD)
> Author: Michael Osipov
> AuthorDate: 2022-01-08 21:02:12 +0100
> Commit: Michael Osipov
> CommitDate: 2022-01-08 21:02:12 +0100
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-scm] michael-o commented on pull request #134: [SCM-976] GitExe Changelog works if the user has defined a custom format.
michael-o commented on PR #134: URL: https://github.com/apache/maven-scm/pull/134#issuecomment-1131433420 Yes, I will move forward with this today -- 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-7480) Profile option doesn't activate selected profile
[
https://issues.apache.org/jira/browse/MNG-7480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539416#comment-17539416
]
Yury Remishevsky commented on MNG-7480:
---
mvn validate -> success
mvn validate -P postgresql
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[ERROR] 'dependencies.dependency.version' for
org.kie.kogito:kogito-addons-quarkus-persistence-:jar is missing.
So it seems like -P works in maven and the problem lies elsewhere, for instance
in {color:#00}quarkus-maven-plugin{color}?
> Profile option doesn't activate selected profile
>
>
> Key: MNG-7480
> URL: https://issues.apache.org/jira/browse/MNG-7480
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.8.5
>Reporter: Yury Remishevsky
>Priority: Major
> Attachments: build.log, debug.log, log-active.log, log-all.log
>
>
> Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
> *Steps to reproduce*
> On project
> [https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
> # install maven 3.8.5
> # mvn --version -> 3.8.5
> # mvn clean package -P postgresql | grep usePersistence produces build with
> out required dependencies ->
> AddonsConfig{usePersistence={color:#ff}false{color}
> For e.g. on maven 3.8.1
> # mvn clean package -P postgresql | grep usePersistence produces build with
> expected dependencies ->
> AddonsConfig{usePersistence={color:#ff}true{color}
> *{color:#172b4d}Expected behavior{color}*
> {color:#172b4d}Using mvn clean package -P profile explicitly activates
> profile "profile" as stated in
> [https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
> {quote}Profiles can be explicitly specified using the {{-P}} command line
> flag.
> This flag is followed by a comma-delimited list of profile IDs to use. The
> profile(s) specified in the option are activated in addition to any profiles
> which are activated by their activation configuration or the
> {{}} section in {{{}settings.xml{}}}.
> {quote}
> *System info*
> [INFO] Detecting the operating system and CPU architecture
> [INFO]
>
> [INFO] os.detected.name: linux
> [INFO] os.detected.arch: x86_64
> [INFO] os.detected.version: 5.17
> [INFO] os.detected.version.major: 5
> [INFO] os.detected.version.minor: 17
> [INFO] os.detected.release: fedora
> [INFO] os.detected.release.version: 36
> [INFO] os.detected.release.like.fedora: true
> [INFO] os.detected.classifier: linux-x86_64
> openjdk 18.0.1 2022-04-19
> OpenJDK Runtime Environment Homebrew (build 18.0.1+0)
> OpenJDK 64-Bit Server VM Homebrew (build 18.0.1+0, mixed mode, sharing)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-mvnd] hboutemy opened a new issue, #653: mvnd goal execution id display inconsistent with Maven
hboutemy opened a new issue, #653: URL: https://github.com/apache/maven-mvnd/issues/653 in mvnd, a running mojo is displayed as "plugin:goal @ executionid": ``` :maven-compatmaven-surefire-plugin:test @ default-test ``` but in Maven, @ syntax is for artifactid, execution id is in parenthesis: ``` [INFO] --- maven-assembly-plugin:3.3.0:single (create-distro-packages) @ apache-maven --- ``` such inconsistency will create users confusion (particularly given mvnd also uses ANSI color for mvn's @ artifactId), it would be better to align mvnd with mvn (syntax and ANSI color): ``` :maven-compatmaven-surefire-plugin:test (default-test) ``` and eventually, the current module artifact id could use the same ANSI color as mvn's "@ artifactId" -- 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.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MJAVADOC-652) Dependencies on the patch-module path
[ https://issues.apache.org/jira/browse/MJAVADOC-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539464#comment-17539464 ] Phil commented on MJAVADOC-652: --- I agree, the parameter was a hack, really. I will try to get the sample project to break in the way I am seeing it. However, I still have the general question: Is putting these things on the patch-module path sensible? > Dependencies on the patch-module path > - > > Key: MJAVADOC-652 > URL: https://issues.apache.org/jira/browse/MJAVADOC-652 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0 >Reporter: Phil >Assignee: Robert Scholte >Priority: Major > Attachments: MJAVADOC-652-PATCHMODULE.zip, MJAVADOC-652.zip > > > When building with Java 11 (so >9) the Javadoc options argument is built > using the module-path and patch-module. Some of the dependencies I work with > are ending up in patch-module which generates an error on Javadoc creation - > class not found. > From what I can see from the code (3.2.0), the decision of which argument to > use is based on: > # If the dependency jar has a module-info.class, add to module-path > # If the dependency jar has a MANIFEST file with Automatic-Module-Name > defined, add to module-path. > # If neither of the above, add to patch-module. > The javax.servlet-API-3.1.0.jar, for example, has neither 1 nor 2, so gets > amended to the patch-module. This then prevents Javadoc generation because > Java is unable to link classes from the servlet API. If I put the servlet API > into the module-path manually it works fine. > From my understanding, patch-module is used to either override classes in a > module or augment contents of a module. In this case, it is its own 'module' > (I think) and should not be patched into my module. I do not see a reason to > put any of my dependencies into patch-module. > Is this a bug, or just an unfortunate consequence of having to deal with > non-modular dependencies when building under a Java version that supports > modules. For what it is worth, the project I work on does not use modules, > everything on -classpath works just fine. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-mvnd] gnodet commented on issue #653: mvnd goal execution id display inconsistent with Maven
gnodet commented on issue #653: URL: https://github.com/apache/maven-mvnd/issues/653#issuecomment-1131573845 Fwiw, the method that computes the line for a given project is: https://github.com/apache/maven-mvnd/blob/47c99e8b0e524ca1db3ace306542309f1adcacc9/common/src/main/java/org/mvndaemon/mvnd/common/logging/TerminalOutput.java#L763-L792 -- 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-7316) MavenProject.getAttachedArtifacts() regression with 3.8.1
[
https://issues.apache.org/jira/browse/MNG-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539501#comment-17539501
]
Christoph Läubrich commented on MNG-7316:
-
Just to add another use-case here, Tycho also was hit bit this problem, and yes
as written down here it is not documented that the attached artifacts list is
mutable.
We currently use the same workaround by reflectivly call the
setAttachedArtifacts
[https://github.com/eclipse/tycho/blob/48b0737c0710dec4331934a1b4ffec2813716f5b/tycho-p2/tycho-p2-plugin/src/main/java/org/eclipse/tycho/plugins/p2/BaselineValidator.java#L149-L167]
here.
The rationale here is, that we do a "baseline replace" that means we compare
the artifacts produced to a baseline version and if it is equal enough it gots
replaced by the baseline version so the final artifact is bit-by-bit equivalent
to the baseline.
So maybe the solution here could be to simply make _setAttachedArtifacts_
public?
> MavenProject.getAttachedArtifacts() regression with 3.8.1
> -
>
> Key: MNG-7316
> URL: https://issues.apache.org/jira/browse/MNG-7316
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.2, 3.8.3
>Reporter: Gary D. Gregory
>Priority: Critical
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> The method {{MavenProject.getAttachedArtifacts()}} as of 3.8.2 breaks
> releasing components for us at Apache Commons using our Maven Release plugin
> because the list returned is now immutable, we now get an exception when
> calling {{remove()}} on the collection returned by the API; see
> [https://github.com/apache/commons-release-plugin/blob/master/src/main/java/org/apache/commons/release/plugin/mojos/CommonsDistributionDetachmentMojo.java#L137]
> This worked fine in 3.8.1, may you please change it back for 3.8.4?
> We cannot use Maven 3.8.2 and 3.8.3 to release our components.
> ([~michael-o]: Ironically, I discovered this trying to create a release
> candidate for Apache Commons CLI.)
> The exception in 3.8.3:
> {quote}Caused by: java.lang.UnsupportedOperationException
> at java.util.Collections$UnmodifiableCollection.remove
> (Collections.java:1060)
> at
> org.apache.commons.release.plugin.mojos.CommonsDistributionDetachmentMojo.execute
> (CommonsDistributionDetachmentMojo.java:136)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (MNG-7316) MavenProject.getAttachedArtifacts() regression with 3.8.1
[
https://issues.apache.org/jira/browse/MNG-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539501#comment-17539501
]
Christoph Läubrich edited comment on MNG-7316 at 5/19/22 12:10 PM:
---
Just to add another use-case here, [Tycho also was hit bit this
problem|https://github.com/eclipse/tycho/issues/261], and yes as written down
here it is not documented that the attached artifacts list is mutable.
We currently use the same workaround by reflectivly call the
setAttachedArtifacts
[https://github.com/eclipse/tycho/blob/48b0737c0710dec4331934a1b4ffec2813716f5b/tycho-p2/tycho-p2-plugin/src/main/java/org/eclipse/tycho/plugins/p2/BaselineValidator.java#L149-L167]
here.
The rationale here is, that we do a "baseline replace" that means we compare
the artifacts produced to a baseline version and if it is equal enough it gots
replaced by the baseline version so the final artifact is bit-by-bit equivalent
to the baseline.
So maybe the solution here could be to simply make _setAttachedArtifacts_
public?
was (Author: laeubi):
Just to add another use-case here, Tycho also was hit bit this problem, and yes
as written down here it is not documented that the attached artifacts list is
mutable.
We currently use the same workaround by reflectivly call the
setAttachedArtifacts
[https://github.com/eclipse/tycho/blob/48b0737c0710dec4331934a1b4ffec2813716f5b/tycho-p2/tycho-p2-plugin/src/main/java/org/eclipse/tycho/plugins/p2/BaselineValidator.java#L149-L167]
here.
The rationale here is, that we do a "baseline replace" that means we compare
the artifacts produced to a baseline version and if it is equal enough it gots
replaced by the baseline version so the final artifact is bit-by-bit equivalent
to the baseline.
So maybe the solution here could be to simply make _setAttachedArtifacts_
public?
> MavenProject.getAttachedArtifacts() regression with 3.8.1
> -
>
> Key: MNG-7316
> URL: https://issues.apache.org/jira/browse/MNG-7316
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.2, 3.8.3
>Reporter: Gary D. Gregory
>Priority: Critical
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> The method {{MavenProject.getAttachedArtifacts()}} as of 3.8.2 breaks
> releasing components for us at Apache Commons using our Maven Release plugin
> because the list returned is now immutable, we now get an exception when
> calling {{remove()}} on the collection returned by the API; see
> [https://github.com/apache/commons-release-plugin/blob/master/src/main/java/org/apache/commons/release/plugin/mojos/CommonsDistributionDetachmentMojo.java#L137]
> This worked fine in 3.8.1, may you please change it back for 3.8.4?
> We cannot use Maven 3.8.2 and 3.8.3 to release our components.
> ([~michael-o]: Ironically, I discovered this trying to create a release
> candidate for Apache Commons CLI.)
> The exception in 3.8.3:
> {quote}Caused by: java.lang.UnsupportedOperationException
> at java.util.Collections$UnmodifiableCollection.remove
> (Collections.java:1060)
> at
> org.apache.commons.release.plugin.mojos.CommonsDistributionDetachmentMojo.execute
> (CommonsDistributionDetachmentMojo.java:136)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven] gnodet commented on pull request #743: [3.9.x] [MNG-7401] [MNG-7474] Keep a single maven session and fix session scope
gnodet commented on PR #743: URL: https://github.com/apache/maven/pull/743#issuecomment-1131622335 > We have TLS-based solutions in past releases and we had to revert. What makes this one different? It's not a new TLS, it's a move of the existing TLS from SessionScope to MavenSession. The problem I'm trying to solve is really MNG-7474 : the fact that session scoped beans are not singletons anymore, since the introduction of _multiple_ sessions when introducing the concurrent builds. This is what introduced the TLS in the SessionScope, thereby breaking its purpose, i.e. beans are not cached within the session scope. So there are several solutions to this problem, but I think the SessionScope is useless in the current form. So if we don't want to use a single session and keep things the way they are, I'd need to introduce a more global scope with a real singleton session object. We can't simply change the SessionScope, because beans are injected with the MavenSession, so if we want singletons, we need to have a consistent MavenSession object across mojo executions, which is not the case because of the multiple session clones. So the possibilities are: * revert the use of multiple sessions, i.e. use a single session throughout the whole build, which is what this PR is about. The possible drawback is breakages of code that would use `MavenSession.getCurrentProject()` from a different thread * introduce a new concept of singleton session + scope. if we want it immutable, it would basically be the MavenSession without the current project. The obvious drawback * do nothing to fix the problem: this is a possibility and I'd have to work around the problem in m-build-cache-e by keeping state inside the MavenSession, or most probably in the `RepositorySystemSession.getData()` structure. In such a case, I think it would be better to deprecate the `@SessionScope` and related classes. I think the cleaner state would be to fix the `@SessionScope` and use a singleton for `MavenSession` because that's semantically the most desirable state. Scopes are natural for DI, so it makes sense to use them, and the `MavenSession` cloning stuff has only been introduced to solve the `getCurrentProject()` problem. We should maybe also deprecate this method and suggest that plugins should have the project injected in a field. It would be difficult to get rid of it in the very short term, as that one is used a lot internally for the moment. We could also move it the `LegacySupport` along with the access to the current session. -- 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-7401) Make MavenSession#getCurrentProject() using a thread local
[ https://issues.apache.org/jira/browse/MNG-7401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539515#comment-17539515 ] ASF GitHub Bot commented on MNG-7401: - gnodet commented on PR #743: URL: https://github.com/apache/maven/pull/743#issuecomment-1131622335 > We have TLS-based solutions in past releases and we had to revert. What makes this one different? It's not a new TLS, it's a move of the existing TLS from SessionScope to MavenSession. The problem I'm trying to solve is really MNG-7474 : the fact that session scoped beans are not singletons anymore, since the introduction of _multiple_ sessions when introducing the concurrent builds. This is what introduced the TLS in the SessionScope, thereby breaking its purpose, i.e. beans are not cached within the session scope. So there are several solutions to this problem, but I think the SessionScope is useless in the current form. So if we don't want to use a single session and keep things the way they are, I'd need to introduce a more global scope with a real singleton session object. We can't simply change the SessionScope, because beans are injected with the MavenSession, so if we want singletons, we need to have a consistent MavenSession object across mojo executions, which is not the case because of the multiple session clones. So the possibilities are: * revert the use of multiple sessions, i.e. use a single session throughout the whole build, which is what this PR is about. The possible drawback is breakages of code that would use `MavenSession.getCurrentProject()` from a different thread * introduce a new concept of singleton session + scope. if we want it immutable, it would basically be the MavenSession without the current project. The obvious drawback * do nothing to fix the problem: this is a possibility and I'd have to work around the problem in m-build-cache-e by keeping state inside the MavenSession, or most probably in the `RepositorySystemSession.getData()` structure. In such a case, I think it would be better to deprecate the `@SessionScope` and related classes. I think the cleaner state would be to fix the `@SessionScope` and use a singleton for `MavenSession` because that's semantically the most desirable state. Scopes are natural for DI, so it makes sense to use them, and the `MavenSession` cloning stuff has only been introduced to solve the `getCurrentProject()` problem. We should maybe also deprecate this method and suggest that plugins should have the project injected in a field. It would be difficult to get rid of it in the very short term, as that one is used a lot internally for the moment. We could also move it the `LegacySupport` along with the access to the current session. > Make MavenSession#getCurrentProject() using a thread local > -- > > Key: MNG-7401 > URL: https://issues.apache.org/jira/browse/MNG-7401 > Project: Maven > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > Fix For: waiting-for-feedback > > > I noticed that a session is often cloned due to change the current project > for a while. > As this works for everyone passing down the session, consumers of the "upper > session" (e.g. a SessionScoped Component) would never see this if they are > (indirectly) called and e.g. use Session#getCurrentProject(). > I wonder if MavenSession could simply use a ThreadLocal for the > currentProject (that is shared accross all cloned sessions), that way one > would always get the correct value. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MJAVADOC-652) Dependencies on the patch-module path
[ https://issues.apache.org/jira/browse/MJAVADOC-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539538#comment-17539538 ] Robert Scholte commented on MJAVADOC-652: - The plugin tries to build up the most clean possible set of arguments. Adding jars to the patch module was never done just for fun or for the easy solution, but always because there was a case that shows that it is required. > Dependencies on the patch-module path > - > > Key: MJAVADOC-652 > URL: https://issues.apache.org/jira/browse/MJAVADOC-652 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0 >Reporter: Phil >Assignee: Robert Scholte >Priority: Major > Attachments: MJAVADOC-652-PATCHMODULE.zip, MJAVADOC-652.zip > > > When building with Java 11 (so >9) the Javadoc options argument is built > using the module-path and patch-module. Some of the dependencies I work with > are ending up in patch-module which generates an error on Javadoc creation - > class not found. > From what I can see from the code (3.2.0), the decision of which argument to > use is based on: > # If the dependency jar has a module-info.class, add to module-path > # If the dependency jar has a MANIFEST file with Automatic-Module-Name > defined, add to module-path. > # If neither of the above, add to patch-module. > The javax.servlet-API-3.1.0.jar, for example, has neither 1 nor 2, so gets > amended to the patch-module. This then prevents Javadoc generation because > Java is unable to link classes from the servlet API. If I put the servlet API > into the module-path manually it works fine. > From my understanding, patch-module is used to either override classes in a > module or augment contents of a module. In this case, it is its own 'module' > (I think) and should not be patched into my module. I do not see a reason to > put any of my dependencies into patch-module. > Is this a bug, or just an unfortunate consequence of having to deal with > non-modular dependencies when building under a Java version that supports > modules. For what it is worth, the project I work on does not use modules, > everything on -classpath works just fine. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven] laeubi commented on pull request #743: [3.9.x] [MNG-7401] [MNG-7474] Keep a single maven session and fix session scope
laeubi commented on PR #743: URL: https://github.com/apache/maven/pull/743#issuecomment-1131684537 > revert the use of multiple sessions, i.e. use a single session throughout the whole build, which is what this PR is about. The possible drawback is breakages of code that would use `MavenSession.getCurrentProject()` from a different thread I think this is (at least for the Tycho scope of the problem) the most noteable thing, and we use `LegacySupport` what effectivly *is* a Threadlocal, so from what I can tell, in almost all cases `MavenSession.getCurrentProject()` returning the current project "of the thread" would be sufficient and cloning the session seem to be effectively for that purpose. The problem with the cloning is, that if I have a sessionscoped componet I get the "rootsession" and thus calling `MavenSession.getCurrentProject()` most of the time returns `null` as the actual project is set on a cloned copy. -- 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-7401) Make MavenSession#getCurrentProject() using a thread local
[ https://issues.apache.org/jira/browse/MNG-7401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539551#comment-17539551 ] ASF GitHub Bot commented on MNG-7401: - laeubi commented on PR #743: URL: https://github.com/apache/maven/pull/743#issuecomment-1131684537 > revert the use of multiple sessions, i.e. use a single session throughout the whole build, which is what this PR is about. The possible drawback is breakages of code that would use `MavenSession.getCurrentProject()` from a different thread I think this is (at least for the Tycho scope of the problem) the most noteable thing, and we use `LegacySupport` what effectivly *is* a Threadlocal, so from what I can tell, in almost all cases `MavenSession.getCurrentProject()` returning the current project "of the thread" would be sufficient and cloning the session seem to be effectively for that purpose. The problem with the cloning is, that if I have a sessionscoped componet I get the "rootsession" and thus calling `MavenSession.getCurrentProject()` most of the time returns `null` as the actual project is set on a cloned copy. > Make MavenSession#getCurrentProject() using a thread local > -- > > Key: MNG-7401 > URL: https://issues.apache.org/jira/browse/MNG-7401 > Project: Maven > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > Fix For: waiting-for-feedback > > > I noticed that a session is often cloned due to change the current project > for a while. > As this works for everyone passing down the session, consumers of the "upper > session" (e.g. a SessionScoped Component) would never see this if they are > (indirectly) called and e.g. use Session#getCurrentProject(). > I wonder if MavenSession could simply use a ThreadLocal for the > currentProject (that is shared accross all cloned sessions), that way one > would always get the correct value. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-mvnd] ppalaga commented on issue #653: mvnd goal execution id display inconsistent with Maven
ppalaga commented on issue #653: URL: https://github.com/apache/maven-mvnd/issues/653#issuecomment-1131686489 The idea to use `@ executionId` is from me. I took it from how you can choose some specific execution from the CLI: `mvn groupId:artifactId:version@execution`. I did not think of how Maven reports the mojos in the console. I do not mind to change it to what @hboutemy proposes. -- 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
[GitHub] [maven] laeubi commented on pull request #743: [3.9.x] [MNG-7401] [MNG-7474] Keep a single maven session and fix session scope
laeubi commented on PR #743: URL: https://github.com/apache/maven/pull/743#issuecomment-1131687007 > We should maybe also deprecate this method and suggest that plugins should have the project injected in a field I think the problem is that we then need some kind of "ProjectScope", I think `MavenSession.set/getCurrentProject()` should simply become a ThreadLocal, we document that and if one needs to pass data to a different thread he first need to fetch the current project. -- 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-7401) Make MavenSession#getCurrentProject() using a thread local
[ https://issues.apache.org/jira/browse/MNG-7401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539554#comment-17539554 ] ASF GitHub Bot commented on MNG-7401: - laeubi commented on PR #743: URL: https://github.com/apache/maven/pull/743#issuecomment-1131687007 > We should maybe also deprecate this method and suggest that plugins should have the project injected in a field I think the problem is that we then need some kind of "ProjectScope", I think `MavenSession.set/getCurrentProject()` should simply become a ThreadLocal, we document that and if one needs to pass data to a different thread he first need to fetch the current project. > Make MavenSession#getCurrentProject() using a thread local > -- > > Key: MNG-7401 > URL: https://issues.apache.org/jira/browse/MNG-7401 > Project: Maven > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > Fix For: waiting-for-feedback > > > I noticed that a session is often cloned due to change the current project > for a while. > As this works for everyone passing down the session, consumers of the "upper > session" (e.g. a SessionScoped Component) would never see this if they are > (indirectly) called and e.g. use Session#getCurrentProject(). > I wonder if MavenSession could simply use a ThreadLocal for the > currentProject (that is shared accross all cloned sessions), that way one > would always get the correct value. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MJAVADOC-652) Dependencies on the patch-module path
[ https://issues.apache.org/jira/browse/MJAVADOC-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539561#comment-17539561 ] Phil commented on MJAVADOC-652: --- Sure, I am the first to admit I do not really understand the module system very well. In the sample project, however, the Servlet API is being added to the patch-module path (even though that version does not understand the module system) just because the root project itself is declaring an automatic-module-name (if it hadn't it just uses the classpath). I do not know what the Servlet API is 'patching'. And it breaks Javadoc for the stuff I work on. > Dependencies on the patch-module path > - > > Key: MJAVADOC-652 > URL: https://issues.apache.org/jira/browse/MJAVADOC-652 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0 >Reporter: Phil >Assignee: Robert Scholte >Priority: Major > Attachments: MJAVADOC-652-PATCHMODULE.zip, MJAVADOC-652.zip > > > When building with Java 11 (so >9) the Javadoc options argument is built > using the module-path and patch-module. Some of the dependencies I work with > are ending up in patch-module which generates an error on Javadoc creation - > class not found. > From what I can see from the code (3.2.0), the decision of which argument to > use is based on: > # If the dependency jar has a module-info.class, add to module-path > # If the dependency jar has a MANIFEST file with Automatic-Module-Name > defined, add to module-path. > # If neither of the above, add to patch-module. > The javax.servlet-API-3.1.0.jar, for example, has neither 1 nor 2, so gets > amended to the patch-module. This then prevents Javadoc generation because > Java is unable to link classes from the servlet API. If I put the servlet API > into the module-path manually it works fine. > From my understanding, patch-module is used to either override classes in a > module or augment contents of a module. In this case, it is its own 'module' > (I think) and should not be patched into my module. I do not see a reason to > put any of my dependencies into patch-module. > Is this a bug, or just an unfortunate consequence of having to deal with > non-modular dependencies when building under a Java version that supports > modules. For what it is worth, the project I work on does not use modules, > everything on -classpath works just fine. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (MJAVADOC-652) Dependencies on the patch-module path
[ https://issues.apache.org/jira/browse/MJAVADOC-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539561#comment-17539561 ] Phil edited comment on MJAVADOC-652 at 5/19/22 1:38 PM: Sure, the module stuff makes backward compatibility harder, I am the first to admit I do not really understand the module system very well. In the sample project, however, the Servlet API is being added to the patch-module path (even though that version does not understand the module system) just because the root project itself is declaring an automatic-module-name (if it hadn't it just uses the classpath). I do not know what the Servlet API is 'patching'. And it breaks Javadoc for the stuff I work on. was (Author: philsmart): Sure, I am the first to admit I do not really understand the module system very well. In the sample project, however, the Servlet API is being added to the patch-module path (even though that version does not understand the module system) just because the root project itself is declaring an automatic-module-name (if it hadn't it just uses the classpath). I do not know what the Servlet API is 'patching'. And it breaks Javadoc for the stuff I work on. > Dependencies on the patch-module path > - > > Key: MJAVADOC-652 > URL: https://issues.apache.org/jira/browse/MJAVADOC-652 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0 >Reporter: Phil >Assignee: Robert Scholte >Priority: Major > Attachments: MJAVADOC-652-PATCHMODULE.zip, MJAVADOC-652.zip > > > When building with Java 11 (so >9) the Javadoc options argument is built > using the module-path and patch-module. Some of the dependencies I work with > are ending up in patch-module which generates an error on Javadoc creation - > class not found. > From what I can see from the code (3.2.0), the decision of which argument to > use is based on: > # If the dependency jar has a module-info.class, add to module-path > # If the dependency jar has a MANIFEST file with Automatic-Module-Name > defined, add to module-path. > # If neither of the above, add to patch-module. > The javax.servlet-API-3.1.0.jar, for example, has neither 1 nor 2, so gets > amended to the patch-module. This then prevents Javadoc generation because > Java is unable to link classes from the servlet API. If I put the servlet API > into the module-path manually it works fine. > From my understanding, patch-module is used to either override classes in a > module or augment contents of a module. In this case, it is its own 'module' > (I think) and should not be patched into my module. I do not see a reason to > put any of my dependencies into patch-module. > Is this a bug, or just an unfortunate consequence of having to deal with > non-modular dependencies when building under a Java version that supports > modules. For what it is worth, the project I work on does not use modules, > everything on -classpath works just fine. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (MNG-7480) Profile option doesn't activate selected profile
[
https://issues.apache.org/jira/browse/MNG-7480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed MNG-7480.
Resolution: Not A Problem
> Profile option doesn't activate selected profile
>
>
> Key: MNG-7480
> URL: https://issues.apache.org/jira/browse/MNG-7480
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.8.5
>Reporter: Yury Remishevsky
>Priority: Major
> Attachments: build.log, debug.log, log-active.log, log-all.log
>
>
> Hi! On maven 3.8.5 using -P profile option doesn't activate selected profile.
> *Steps to reproduce*
> On project
> [https://github.com/StoneToken/workflow-engines-load-test/blob/master/kogito-bpmn-async]
> # install maven 3.8.5
> # mvn --version -> 3.8.5
> # mvn clean package -P postgresql | grep usePersistence produces build with
> out required dependencies ->
> AddonsConfig{usePersistence={color:#ff}false{color}
> For e.g. on maven 3.8.1
> # mvn clean package -P postgresql | grep usePersistence produces build with
> expected dependencies ->
> AddonsConfig{usePersistence={color:#ff}true{color}
> *{color:#172b4d}Expected behavior{color}*
> {color:#172b4d}Using mvn clean package -P profile explicitly activates
> profile "profile" as stated in
> [https://maven.apache.org/guides/introduction/introduction-to-profiles.html:]{color}
> {quote}Profiles can be explicitly specified using the {{-P}} command line
> flag.
> This flag is followed by a comma-delimited list of profile IDs to use. The
> profile(s) specified in the option are activated in addition to any profiles
> which are activated by their activation configuration or the
> {{}} section in {{{}settings.xml{}}}.
> {quote}
> *System info*
> [INFO] Detecting the operating system and CPU architecture
> [INFO]
>
> [INFO] os.detected.name: linux
> [INFO] os.detected.arch: x86_64
> [INFO] os.detected.version: 5.17
> [INFO] os.detected.version.major: 5
> [INFO] os.detected.version.minor: 17
> [INFO] os.detected.release: fedora
> [INFO] os.detected.release.version: 36
> [INFO] os.detected.release.like.fedora: true
> [INFO] os.detected.classifier: linux-x86_64
> openjdk 18.0.1 2022-04-19
> OpenJDK Runtime Environment Homebrew (build 18.0.1+0)
> OpenJDK 64-Bit Server VM Homebrew (build 18.0.1+0, mixed mode, sharing)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-integration-testing] slawekjaranowski merged pull request #164: Upgrade maven-verifier to 1.8.0
slawekjaranowski merged PR #164: URL: https://github.com/apache/maven-integration-testing/pull/164 -- 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
[GitHub] [maven-mvnd] gnodet commented on issue #649: Maven goal is sometimes skipped
gnodet commented on issue #649: URL: https://github.com/apache/maven-mvnd/issues/649#issuecomment-1131835457 @eforx any chance you could provide a way to reproduce the problem ? -- 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] (MJAVADOC-652) Dependencies on the patch-module path
[
https://issues.apache.org/jira/browse/MJAVADOC-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539602#comment-17539602
]
Robert Scholte commented on MJAVADOC-652:
-
Do the following steps:
- unpack your zip and run {{mvn verify -Ddebug}}
- go to target/apidocs and adjust the {{options}} file (e.g removing
servlet-api from the --patch-module argument)
- run from the target/apidocs directory {{javadoc}} and you'll see the errors.
And by the way adjusting the options is the perfect way to test your changes
before diving into the code.
The patch is required for sure. Again, try to make a reproducible project,
otherwise it is way to hard to figure out your specific problem.
> Dependencies on the patch-module path
> -
>
> Key: MJAVADOC-652
> URL: https://issues.apache.org/jira/browse/MJAVADOC-652
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0
>Reporter: Phil
>Assignee: Robert Scholte
>Priority: Major
> Attachments: MJAVADOC-652-PATCHMODULE.zip, MJAVADOC-652.zip
>
>
> When building with Java 11 (so >9) the Javadoc options argument is built
> using the module-path and patch-module. Some of the dependencies I work with
> are ending up in patch-module which generates an error on Javadoc creation -
> class not found.
> From what I can see from the code (3.2.0), the decision of which argument to
> use is based on:
> # If the dependency jar has a module-info.class, add to module-path
> # If the dependency jar has a MANIFEST file with Automatic-Module-Name
> defined, add to module-path.
> # If neither of the above, add to patch-module.
> The javax.servlet-API-3.1.0.jar, for example, has neither 1 nor 2, so gets
> amended to the patch-module. This then prevents Javadoc generation because
> Java is unable to link classes from the servlet API. If I put the servlet API
> into the module-path manually it works fine.
> From my understanding, patch-module is used to either override classes in a
> module or augment contents of a module. In this case, it is its own 'module'
> (I think) and should not be patched into my module. I do not see a reason to
> put any of my dependencies into patch-module.
> Is this a bug, or just an unfortunate consequence of having to deal with
> non-modular dependencies when building under a Java version that supports
> modules. For what it is worth, the project I work on does not use modules,
> everything on -classpath works just fine.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MJAVADOC-652) Dependencies on the patch-module path
[ https://issues.apache.org/jira/browse/MJAVADOC-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539609#comment-17539609 ] Phil commented on MJAVADOC-652: --- Thanks. Yeah. I see removing it from any path will kill it. I was experimenting by placing it on the module-path in my (failing) project (in the way you say with the options file) and it works fine if I moved it onto that. But I totally get I need to demonstrate this. So I will get back to you if I can update the sample project accordingly. > Dependencies on the patch-module path > - > > Key: MJAVADOC-652 > URL: https://issues.apache.org/jira/browse/MJAVADOC-652 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.2.0, 3.3.0, 3.3.1, 3.3.2, 3.4.0 >Reporter: Phil >Assignee: Robert Scholte >Priority: Major > Attachments: MJAVADOC-652-PATCHMODULE.zip, MJAVADOC-652.zip > > > When building with Java 11 (so >9) the Javadoc options argument is built > using the module-path and patch-module. Some of the dependencies I work with > are ending up in patch-module which generates an error on Javadoc creation - > class not found. > From what I can see from the code (3.2.0), the decision of which argument to > use is based on: > # If the dependency jar has a module-info.class, add to module-path > # If the dependency jar has a MANIFEST file with Automatic-Module-Name > defined, add to module-path. > # If neither of the above, add to patch-module. > The javax.servlet-API-3.1.0.jar, for example, has neither 1 nor 2, so gets > amended to the patch-module. This then prevents Javadoc generation because > Java is unable to link classes from the servlet API. If I put the servlet API > into the module-path manually it works fine. > From my understanding, patch-module is used to either override classes in a > module or augment contents of a module. In this case, it is its own 'module' > (I think) and should not be patched into my module. I do not see a reason to > put any of my dependencies into patch-module. > Is this a bug, or just an unfortunate consequence of having to deal with > non-modular dependencies when building under a Java version that supports > modules. For what it is worth, the project I work on does not use modules, > everything on -classpath works just fine. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MNG-7470) Add IT involving resolver transport
[ https://issues.apache.org/jira/browse/MNG-7470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539610#comment-17539610 ] Hudson commented on MNG-7470: - Build succeeded in Jenkins: Maven » Maven TLP » maven » maven-3.8.x #22 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.8.x/22/ > Add IT involving resolver transport > --- > > Key: MNG-7470 > URL: https://issues.apache.org/jira/browse/MNG-7470 > Project: Maven > Issue Type: Task > Components: Integration Tests >Reporter: Tamás Cservenák >Priority: Major > > Ideally just copy mvnd TypeDescriptionTest to maven ITs -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-mvnd] ppalaga commented on pull request #654: Make mvnd coloring more consistent with maven, fixes #653
ppalaga commented on PR #654: URL: https://github.com/apache/maven-mvnd/pull/654#issuecomment-1131860930 Could you please paste a screenshot what it looks like now? -- 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
[GitHub] [maven-mvnd] gnodet commented on pull request #654: Make mvnd coloring more consistent with maven, fixes #653
gnodet commented on PR #654: URL: https://github.com/apache/maven-mvnd/pull/654#issuecomment-1131879038 https://user-images.githubusercontent.com/84022/169337560-4e6b755a-286d-42c7-a1b3-9eb669acd2da.png";> -- 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] (SUREFIRE-2087) rerunFailingTestsCount incorrectly marks failed parametrized test as pass
Ramanan Rajendran created SUREFIRE-2087: --- Summary: rerunFailingTestsCount incorrectly marks failed parametrized test as pass Key: SUREFIRE-2087 URL: https://issues.apache.org/jira/browse/SUREFIRE-2087 Project: Maven Surefire Issue Type: Bug Reporter: Ramanan Rajendran rerunFailingTestsCount is not working as expected with junit5 `@ParameterizedTest` If 1st iteration of the test passes and the 2nd one fails, it still marks the test as flaky passed. Eg: In the following run, iteration 1 with input A passed but iteration 2 with input B failed. Iteration 2 was rerun 2 times and failed in all the attempts. Instead of failing TestA, it's marked as flaky giving an overall pass for the test suite. I believe it's using the Run 1 PASS as a gate to mark the whole test as a pass. [INFO] Run 1: PASS [ERROR] Run 2: TestA.iteration2:101 1 expectation failed. Expected status code <400> doesn't match actual status code <401>. [ERROR] Run 3: TestA.iteration2:101 1 expectation failed. Expected status code <400> doesn't match actual status code <401>. [ERROR] Run 4: TestA.iteration2:101 1 expectation failed. <400> doesn't match actual status code <401>. Tests run: 23, Failures: 0, Errors: 0, Skipped: 2, Flakes: 1 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (SUREFIRE-2087) rerunFailingTestsCount incorrectly marks failed parametrized test as pass
[ https://issues.apache.org/jira/browse/SUREFIRE-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramanan Rajendran updated SUREFIRE-2087: Affects Version/s: 3.0.0-M4 > rerunFailingTestsCount incorrectly marks failed parametrized test as pass > - > > Key: SUREFIRE-2087 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2087 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 3.0.0-M4 >Reporter: Ramanan Rajendran >Priority: Critical > > rerunFailingTestsCount is not working as expected with junit5 > `@ParameterizedTest` > If 1st iteration of the test passes and the 2nd one fails, it still marks the > test as flaky passed. > Eg: In the following run, iteration 1 with input A passed but iteration 2 > with input B failed. Iteration 2 was rerun 2 times and failed in all the > attempts. Instead of failing TestA, it's marked as flaky giving an overall > pass for the test suite. I believe it's using the Run 1 PASS as a gate to > mark the whole test as a pass. > > [INFO] Run 1: PASS > [ERROR] Run 2: TestA.iteration2:101 1 expectation failed. > Expected status code <400> doesn't match actual status code <401>. > [ERROR] Run 3: TestA.iteration2:101 1 expectation failed. > Expected status code <400> doesn't match actual status code <401>. > [ERROR] Run 4: TestA.iteration2:101 1 expectation failed. > <400> doesn't match actual status code <401>. > > Tests run: 23, Failures: 0, Errors: 0, Skipped: 2, Flakes: 1 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (MINVOKER-288) Failed setup job cause skip rest of jobs
[
https://issues.apache.org/jira/browse/MINVOKER-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MINVOKER-288:
-
Summary: Failed setup job cause skip rest of jobs (was: Failed setup jobs)
> Failed setup job cause skip rest of jobs
>
>
> Key: MINVOKER-288
> URL: https://issues.apache.org/jira/browse/MINVOKER-288
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> When {{setup}} jobs fail for whatever reason all rest of jobs should be
> skipped.
> {{Setup}} jobs should be added to build reports and verification of tests
> result should fail.
> When somebody define {{setup}} jobs probably expect the result of its in the
> rest of test.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-invoker-plugin] slawekjaranowski opened a new pull request, #122: [MINVOKER-288] Failed setup job cause skip rest of jobs
slawekjaranowski opened a new pull request, #122: URL: https://github.com/apache/maven-invoker-plugin/pull/122 Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MINVOKER) 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. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MINVOKER-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MINVOKER-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. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] 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. - [x] 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) - [x] 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] (MNG-7316) MavenProject.getAttachedArtifacts() regression with 3.8.1
[
https://issues.apache.org/jira/browse/MNG-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539659#comment-17539659
]
Michael Osipov commented on MNG-7316:
-
[~laeubi], I don't understand your usecase. So you basically can end up with
something you haven't even compiled within the reactor?
> MavenProject.getAttachedArtifacts() regression with 3.8.1
> -
>
> Key: MNG-7316
> URL: https://issues.apache.org/jira/browse/MNG-7316
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.2, 3.8.3
>Reporter: Gary D. Gregory
>Priority: Critical
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> The method {{MavenProject.getAttachedArtifacts()}} as of 3.8.2 breaks
> releasing components for us at Apache Commons using our Maven Release plugin
> because the list returned is now immutable, we now get an exception when
> calling {{remove()}} on the collection returned by the API; see
> [https://github.com/apache/commons-release-plugin/blob/master/src/main/java/org/apache/commons/release/plugin/mojos/CommonsDistributionDetachmentMojo.java#L137]
> This worked fine in 3.8.1, may you please change it back for 3.8.4?
> We cannot use Maven 3.8.2 and 3.8.3 to release our components.
> ([~michael-o]: Ironically, I discovered this trying to create a release
> candidate for Apache Commons CLI.)
> The exception in 3.8.3:
> {quote}Caused by: java.lang.UnsupportedOperationException
> at java.util.Collections$UnmodifiableCollection.remove
> (Collections.java:1060)
> at
> org.apache.commons.release.plugin.mojos.CommonsDistributionDetachmentMojo.execute
> (CommonsDistributionDetachmentMojo.java:136)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-scm] michael-o commented on pull request #134: [SCM-976] GitExe Changelog works if the user has defined a custom format.
michael-o commented on PR #134: URL: https://github.com/apache/maven-scm/pull/134#issuecomment-1131958861 Looking into now. @nielsbasjes Would you mind also to check other commands whether they are prone to this issue as well? -- 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] (SCM-976) [GITEXE] Changelog does not work in if the user has defined a custom format.
[
https://issues.apache.org/jira/browse/SCM-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539671#comment-17539671
]
ASF GitHub Bot commented on SCM-976:
michael-o commented on PR #134:
URL: https://github.com/apache/maven-scm/pull/134#issuecomment-1131958861
Looking into now. @nielsbasjes Would you mind also to check other commands
whether they are prone to this issue as well?
> [GITEXE] Changelog does not work in if the user has defined a custom format.
>
>
> Key: SCM-976
> URL: https://issues.apache.org/jira/browse/SCM-976
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 2.0.0-M1
>Reporter: Niels Basjes
>Priority: Major
>
> Since a long time the headers for the output of "git whatchanged" have been
> changed, as a consequence there is no more output from this command.
> The reason is that the output of this command used to be something like this:
> {code}
> commit 2d22f2da71ef279c4759b1c09cdb8282b63f0cf6
> Author: Mark Struberg
> Date: 2007-11-24 01:10:06 +0100
> {code}
> yet currently it looks like this:
> {code}
> commit 4fc34cfa14f2e72506187b03a492ce55ed459d4c (HEAD -> master,
> origin/master, origin/HEAD)
> Author: Michael Osipov
> AuthorDate: 2022-01-08 21:02:12 +0100
> Commit: Michael Osipov
> CommitDate: 2022-01-08 21:02:12 +0100
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (SCM-976) [GITEXE] Changelog does not work in if the user has defined a custom format.
[
https://issues.apache.org/jira/browse/SCM-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned SCM-976:
--
Assignee: Michael Osipov
> [GITEXE] Changelog does not work in if the user has defined a custom format.
>
>
> Key: SCM-976
> URL: https://issues.apache.org/jira/browse/SCM-976
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 2.0.0-M1
>Reporter: Niels Basjes
>Assignee: Michael Osipov
>Priority: Major
>
> Since a long time the headers for the output of "git whatchanged" have been
> changed, as a consequence there is no more output from this command.
> The reason is that the output of this command used to be something like this:
> {code}
> commit 2d22f2da71ef279c4759b1c09cdb8282b63f0cf6
> Author: Mark Struberg
> Date: 2007-11-24 01:10:06 +0100
> {code}
> yet currently it looks like this:
> {code}
> commit 4fc34cfa14f2e72506187b03a492ce55ed459d4c (HEAD -> master,
> origin/master, origin/HEAD)
> Author: Michael Osipov
> AuthorDate: 2022-01-08 21:02:12 +0100
> Commit: Michael Osipov
> CommitDate: 2022-01-08 21:02:12 +0100
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SCM-976) [GITEXE] Changelog does not work in if the user has defined a custom format.
[
https://issues.apache.org/jira/browse/SCM-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated SCM-976:
---
Fix Version/s: 2.0.0-M2
> [GITEXE] Changelog does not work in if the user has defined a custom format.
>
>
> Key: SCM-976
> URL: https://issues.apache.org/jira/browse/SCM-976
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 2.0.0-M1
>Reporter: Niels Basjes
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 2.0.0-M2
>
>
> Since a long time the headers for the output of "git whatchanged" have been
> changed, as a consequence there is no more output from this command.
> The reason is that the output of this command used to be something like this:
> {code}
> commit 2d22f2da71ef279c4759b1c09cdb8282b63f0cf6
> Author: Mark Struberg
> Date: 2007-11-24 01:10:06 +0100
> {code}
> yet currently it looks like this:
> {code}
> commit 4fc34cfa14f2e72506187b03a492ce55ed459d4c (HEAD -> master,
> origin/master, origin/HEAD)
> Author: Michael Osipov
> AuthorDate: 2022-01-08 21:02:12 +0100
> Commit: Michael Osipov
> CommitDate: 2022-01-08 21:02:12 +0100
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SCM-976) [GITEXE] Changelog does not work in if the user has defined a custom format.
[
https://issues.apache.org/jira/browse/SCM-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated SCM-976:
---
Fix Version/s: 1.x
> [GITEXE] Changelog does not work in if the user has defined a custom format.
>
>
> Key: SCM-976
> URL: https://issues.apache.org/jira/browse/SCM-976
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 2.0.0-M1
>Reporter: Niels Basjes
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.x, 2.0.0-M2
>
>
> Since a long time the headers for the output of "git whatchanged" have been
> changed, as a consequence there is no more output from this command.
> The reason is that the output of this command used to be something like this:
> {code}
> commit 2d22f2da71ef279c4759b1c09cdb8282b63f0cf6
> Author: Mark Struberg
> Date: 2007-11-24 01:10:06 +0100
> {code}
> yet currently it looks like this:
> {code}
> commit 4fc34cfa14f2e72506187b03a492ce55ed459d4c (HEAD -> master,
> origin/master, origin/HEAD)
> Author: Michael Osipov
> AuthorDate: 2022-01-08 21:02:12 +0100
> Commit: Michael Osipov
> CommitDate: 2022-01-08 21:02:12 +0100
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SCM-976) [GITEXE] Changelog does not work in if the user has defined a custom format
[
https://issues.apache.org/jira/browse/SCM-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated SCM-976:
---
Summary: [GITEXE] Changelog does not work in if the user has defined a
custom format (was: [GITEXE] Changelog does not work in if the user has
defined a custom format.)
> [GITEXE] Changelog does not work in if the user has defined a custom format
> ---
>
> Key: SCM-976
> URL: https://issues.apache.org/jira/browse/SCM-976
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 2.0.0-M1
>Reporter: Niels Basjes
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.x, 2.0.0-M2
>
>
> Since a long time the headers for the output of "git whatchanged" have been
> changed, as a consequence there is no more output from this command.
> The reason is that the output of this command used to be something like this:
> {code}
> commit 2d22f2da71ef279c4759b1c09cdb8282b63f0cf6
> Author: Mark Struberg
> Date: 2007-11-24 01:10:06 +0100
> {code}
> yet currently it looks like this:
> {code}
> commit 4fc34cfa14f2e72506187b03a492ce55ed459d4c (HEAD -> master,
> origin/master, origin/HEAD)
> Author: Michael Osipov
> AuthorDate: 2022-01-08 21:02:12 +0100
> Commit: Michael Osipov
> CommitDate: 2022-01-08 21:02:12 +0100
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-7316) MavenProject.getAttachedArtifacts() regression with 3.8.1
[
https://issues.apache.org/jira/browse/MNG-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539673#comment-17539673
]
Christoph Läubrich commented on MNG-7316:
-
No it is compiled, but the result is compared to the baseline, just think about
a jar where you have class files. Even if all class files have the same
content, it is possible that the jar has different bytes e.g. adding classes in
another order or choosing a different compression level.
> MavenProject.getAttachedArtifacts() regression with 3.8.1
> -
>
> Key: MNG-7316
> URL: https://issues.apache.org/jira/browse/MNG-7316
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.2, 3.8.3
>Reporter: Gary D. Gregory
>Priority: Critical
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> The method {{MavenProject.getAttachedArtifacts()}} as of 3.8.2 breaks
> releasing components for us at Apache Commons using our Maven Release plugin
> because the list returned is now immutable, we now get an exception when
> calling {{remove()}} on the collection returned by the API; see
> [https://github.com/apache/commons-release-plugin/blob/master/src/main/java/org/apache/commons/release/plugin/mojos/CommonsDistributionDetachmentMojo.java#L137]
> This worked fine in 3.8.1, may you please change it back for 3.8.4?
> We cannot use Maven 3.8.2 and 3.8.3 to release our components.
> ([~michael-o]: Ironically, I discovered this trying to create a release
> candidate for Apache Commons CLI.)
> The exception in 3.8.3:
> {quote}Caused by: java.lang.UnsupportedOperationException
> at java.util.Collections$UnmodifiableCollection.remove
> (Collections.java:1060)
> at
> org.apache.commons.release.plugin.mojos.CommonsDistributionDetachmentMojo.execute
> (CommonsDistributionDetachmentMojo.java:136)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> {quote}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (SCM-976) [GITEXE] Changelog does not work in if the user has defined a custom format
[
https://issues.apache.org/jira/browse/SCM-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539675#comment-17539675
]
Michael Osipov commented on SCM-976:
[~nielsbasjes], please change the issue description. I don't consider it to be
correct anymore.
> [GITEXE] Changelog does not work in if the user has defined a custom format
> ---
>
> Key: SCM-976
> URL: https://issues.apache.org/jira/browse/SCM-976
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 2.0.0-M1
>Reporter: Niels Basjes
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.x, 2.0.0-M2
>
>
> Since a long time the headers for the output of "git whatchanged" have been
> changed, as a consequence there is no more output from this command.
> The reason is that the output of this command used to be something like this:
> {code}
> commit 2d22f2da71ef279c4759b1c09cdb8282b63f0cf6
> Author: Mark Struberg
> Date: 2007-11-24 01:10:06 +0100
> {code}
> yet currently it looks like this:
> {code}
> commit 4fc34cfa14f2e72506187b03a492ce55ed459d4c (HEAD -> master,
> origin/master, origin/HEAD)
> Author: Michael Osipov
> AuthorDate: 2022-01-08 21:02:12 +0100
> Commit: Michael Osipov
> CommitDate: 2022-01-08 21:02:12 +0100
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SCM-976) GitExe changelog does not work in if the user has defined a custom format
[
https://issues.apache.org/jira/browse/SCM-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated SCM-976:
---
Summary: GitExe changelog does not work in if the user has defined a custom
format (was: [GITEXE] Changelog does not work in if the user has defined a
custom format)
> GitExe changelog does not work in if the user has defined a custom format
> -
>
> Key: SCM-976
> URL: https://issues.apache.org/jira/browse/SCM-976
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 2.0.0-M1
>Reporter: Niels Basjes
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.x, 2.0.0-M2
>
>
> Since a long time the headers for the output of "git whatchanged" have been
> changed, as a consequence there is no more output from this command.
> The reason is that the output of this command used to be something like this:
> {code}
> commit 2d22f2da71ef279c4759b1c09cdb8282b63f0cf6
> Author: Mark Struberg
> Date: 2007-11-24 01:10:06 +0100
> {code}
> yet currently it looks like this:
> {code}
> commit 4fc34cfa14f2e72506187b03a492ce55ed459d4c (HEAD -> master,
> origin/master, origin/HEAD)
> Author: Michael Osipov
> AuthorDate: 2022-01-08 21:02:12 +0100
> Commit: Michael Osipov
> CommitDate: 2022-01-08 21:02:12 +0100
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-scm] asfgit closed pull request #134: [SCM-976] GitExe Changelog works if the user has defined a custom format.
asfgit closed pull request #134: [SCM-976] GitExe Changelog works if the user has defined a custom format. URL: https://github.com/apache/maven-scm/pull/134 -- 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] (SCM-976) GitExe changelog does not work in if the user has defined a custom format
[
https://issues.apache.org/jira/browse/SCM-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed SCM-976.
--
Resolution: Fixed
Fixed with
[178b111bb9976caafd97bce174260f12f0faa8d6|https://gitbox.apache.org/repos/asf?p=maven-scm.git;a=commit;h=178b111bb9976caafd97bce174260f12f0faa8d6]
and with
[0f8b37580a08f3237b3939073ab49fb8c1070aa5|https://gitbox.apache.org/repos/asf?p=maven-scm.git;a=commit;h=0f8b37580a08f3237b3939073ab49fb8c1070aa5]
for {{maven-scm-1.x}} branch.
> GitExe changelog does not work in if the user has defined a custom format
> -
>
> Key: SCM-976
> URL: https://issues.apache.org/jira/browse/SCM-976
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 2.0.0-M1
>Reporter: Niels Basjes
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.x, 2.0.0-M2
>
>
> Since a long time the headers for the output of "git whatchanged" have been
> changed, as a consequence there is no more output from this command.
> The reason is that the output of this command used to be something like this:
> {code}
> commit 2d22f2da71ef279c4759b1c09cdb8282b63f0cf6
> Author: Mark Struberg
> Date: 2007-11-24 01:10:06 +0100
> {code}
> yet currently it looks like this:
> {code}
> commit 4fc34cfa14f2e72506187b03a492ce55ed459d4c (HEAD -> master,
> origin/master, origin/HEAD)
> Author: Michael Osipov
> AuthorDate: 2022-01-08 21:02:12 +0100
> Commit: Michael Osipov
> CommitDate: 2022-01-08 21:02:12 +0100
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (SCM-976) GitExe changelog does not work in if the user has defined a custom format
[
https://issues.apache.org/jira/browse/SCM-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539688#comment-17539688
]
ASF GitHub Bot commented on SCM-976:
asfgit closed pull request #134: [SCM-976] GitExe Changelog works if the user
has defined a custom format.
URL: https://github.com/apache/maven-scm/pull/134
> GitExe changelog does not work in if the user has defined a custom format
> -
>
> Key: SCM-976
> URL: https://issues.apache.org/jira/browse/SCM-976
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-gitexe
>Affects Versions: 2.0.0-M1
>Reporter: Niels Basjes
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.x, 2.0.0-M2
>
>
> Since a long time the headers for the output of "git whatchanged" have been
> changed, as a consequence there is no more output from this command.
> The reason is that the output of this command used to be something like this:
> {code}
> commit 2d22f2da71ef279c4759b1c09cdb8282b63f0cf6
> Author: Mark Struberg
> Date: 2007-11-24 01:10:06 +0100
> {code}
> yet currently it looks like this:
> {code}
> commit 4fc34cfa14f2e72506187b03a492ce55ed459d4c (HEAD -> master,
> origin/master, origin/HEAD)
> Author: Michael Osipov
> AuthorDate: 2022-01-08 21:02:12 +0100
> Commit: Michael Osipov
> CommitDate: 2022-01-08 21:02:12 +0100
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (MINDEXER-157) After import all groups and root groups are inverted in the IndexingContext
Matthias Bläsing created MINDEXER-157:
-
Summary: After import all groups and root groups are inverted in
the IndexingContext
Key: MINDEXER-157
URL: https://issues.apache.org/jira/browse/MINDEXER-157
Project: Maven Indexer
Issue Type: Improvement
Reporter: Matthias Bläsing
I investigated a regression introduced into the NetBeans codebase by the update
of maven indexer to 6.2.0 ([https://github.com/apache/netbeans/issues/4102)] It
turned out, that maven indexer after loading the index needs to explicitly
rebuild the group lists as they are not stored with the index any longer.
Rebuilding on demand is not an option for us, so a solution using a cached
version was tried.
The idea is, that after the index is updated, the current group lists will be
dumped into cache files and when the index is loaded from scratch, that cache
is used to initialize all groups and root groups. This seemed to work ok, but
the results were strange - only the root groups were returned. Debugging
showed, that the all groups list was very short (~950 groups for maven central)
while the root groups list was very long (~66.000 groups for maven central).
The opposite ratio was expected.
The issue can be traced into _DefaultIndexUpdater#loadIndexDirectory_ where
_IndexingContext#replace_ is called with the with the wrong order or
parameters. The declared method:
{code:java}
public interface IndexingContext {
void replace( Directory directory, Set allGroups, Set
rootGroups ) throws IOException;
}{code}
is called as:
{code:java}
private Date loadIndexDirectory( final IndexUpdateRequest updateRequest,
final ResourceFetcher fetcher,
final boolean merge, final String
remoteIndexFile )
throws IOException
{
// ...
updateRequest.getIndexingContext().replace( directory,
rootGroups, allGroups );
// ...
}
{code}
The last two parameters need to be reversed.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-indexer] matthiasblaesing opened a new pull request, #211: [MINDEXER-157] After import all groups and root groups are inverted in the IndexingContext
matthiasblaesing opened a new pull request, #211: URL: https://github.com/apache/maven-indexer/pull/211 The order or the last two arguments of the call to IndexingContext#replace should be "allGroups, rootGroups", but is called as "rootGroups, allGroups", leading to the wrong contents of the corresponding fields of the IndexingContext. -- 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] (SCM-978) Upgrade Maven prerequisite to 3.2.5
[ https://issues.apache.org/jira/browse/SCM-978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated SCM-978: --- Fix Version/s: 1.x > Upgrade Maven prerequisite to 3.2.5 > --- > > Key: SCM-978 > URL: https://issues.apache.org/jira/browse/SCM-978 > Project: Maven SCM > Issue Type: Dependency upgrade > Components: maven-plugin >Reporter: Michael Osipov >Assignee: Tamás Cservenák >Priority: Major > Fix For: 1.x, 2.0.0-M2 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (SCM-972) Deprecate SCM Logger in favor of SLF4J
[
https://issues.apache.org/jira/browse/SCM-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539717#comment-17539717
]
Michael Osipov commented on SCM-972:
Fixed with
[718bd036eb022c6af7e908ca972f937ec4a9df16|https://gitbox.apache.org/repos/asf?p=maven-scm.git;a=commit;h=718bd036eb022c6af7e908ca972f937ec4a9df16]
for {{maven-scm-1.x}} branch.
> Deprecate SCM Logger in favor of SLF4J
> --
>
> Key: SCM-972
> URL: https://issues.apache.org/jira/browse/SCM-972
> Project: Maven SCM
> Issue Type: Task
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.x, 2.0.0-M1
>
>
> We don't want to have our out logging facade. Lets deprecate for removal.
> Users shall move to SLF4J.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (SCM-978) Upgrade Maven prerequisite to 3.2.5
[
https://issues.apache.org/jira/browse/SCM-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539716#comment-17539716
]
Michael Osipov commented on SCM-978:
Fixed with
[35dcd5c717a0845f46f1350d947a50d82cfff83c|https://gitbox.apache.org/repos/asf?p=maven-scm.git;a=commit;h=35dcd5c717a0845f46f1350d947a50d82cfff83c]
for {{maven-scm-1.x}} branch.
> Upgrade Maven prerequisite to 3.2.5
> ---
>
> Key: SCM-978
> URL: https://issues.apache.org/jira/browse/SCM-978
> Project: Maven SCM
> Issue Type: Dependency upgrade
> Components: maven-plugin
>Reporter: Michael Osipov
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 1.x, 2.0.0-M2
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SCM-972) Deprecate SCM Logger in favor of SLF4J
[ https://issues.apache.org/jira/browse/SCM-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated SCM-972: --- Fix Version/s: 1.x > Deprecate SCM Logger in favor of SLF4J > -- > > Key: SCM-972 > URL: https://issues.apache.org/jira/browse/SCM-972 > Project: Maven SCM > Issue Type: Task >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 1.x, 2.0.0-M1 > > > We don't want to have our out logging facade. Lets deprecate for removal. > Users shall move to SLF4J. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (SCM-913) NPE on ChangeSet.toString() when no mergedRevisions are set
[ https://issues.apache.org/jira/browse/SCM-913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned SCM-913: -- Assignee: Michael Osipov > NPE on ChangeSet.toString() when no mergedRevisions are set > --- > > Key: SCM-913 > URL: https://issues.apache.org/jira/browse/SCM-913 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-api >Affects Versions: 1.11.1 >Reporter: Roli Jäger >Assignee: Michael Osipov >Priority: Major > Fix For: waiting-for-feedback > > > Calling toString() on ChangeSet will result in an NPE if neither > addMergedRevision () nor getMergedRevisions() was previously called. > The solution would be to access mergedRevisions by calling > getMergedRevisions() as done in the toXML() Method. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (SCM-913) NPE on ChangeSet.toString() when no mergedRevisions are set
[ https://issues.apache.org/jira/browse/SCM-913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated SCM-913: --- Fix Version/s: 1.13.0 2.0.0-M2 (was: waiting-for-feedback) > NPE on ChangeSet.toString() when no mergedRevisions are set > --- > > Key: SCM-913 > URL: https://issues.apache.org/jira/browse/SCM-913 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-api >Affects Versions: 1.11.1 >Reporter: Roli Jäger >Assignee: Michael Osipov >Priority: Major > Fix For: 1.13.0, 2.0.0-M2 > > > Calling toString() on ChangeSet will result in an NPE if neither > addMergedRevision () nor getMergedRevisions() was previously called. > The solution would be to access mergedRevisions by calling > getMergedRevisions() as done in the toXML() Method. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (MINDEXER-158) IndexSearcher doesn't return all sha1
Matteo Di Pierro created MINDEXER-158:
-
Summary: IndexSearcher doesn't return all sha1
Key: MINDEXER-158
URL: https://issues.apache.org/jira/browse/MINDEXER-158
Project: Maven Indexer
Issue Type: Bug
Reporter: Matteo Di Pierro
Attachments: mavensnippet.java
I'm following your example
[here|https://github.com/apache/maven-indexer/blob/master/indexer-examples/indexer-examples-basic/src/main/java/org/apache/maven/index/examples/BasicUsageExample.java]
and I am successfully able to download and open the index. However, I cannot
find the sha1 d62bd1ef6a9aee74557bd59fb96030fd52cf2fc1, while if I run
{code:java}
curl
https://search.maven.org/solrsearch/select?q="1:d62bd1ef6a9aee74557bd59fb96030fd52cf2fc1"{code}
I get
{code:java}
{"responseHeader":{"status":0,"QTime":0,"params":{"q":"1:d62bd1ef6a9aee74557bd59fb96030fd52cf2fc1","core":"","indent":"off","fl":"id,g,a,v,p,ec,timestamp,tags","start":"","sort":"score
desc,timestamp desc,g asc,a asc,v
desc","rows":"20","wt":"json","version":"2.2"}},"response":{"numFound":1,"start":0,"docs":[{"id":"org.springframework:spring-webmvc:5.3.17","g":"org.springframework","a":"spring-webmvc","v":"5.3.17","p":"jar","timestamp":1647516151000,"ec":[".module","-sources.jar",".pom","-javadoc.jar",".jar"],"tags":["spring"]}]}}
{code}
I am instead able to find inside the index the sha1
3f4de0db59b9085e41cc11c8c2914c427cc848e1 related to the same pkg, as shown here:
{code:java}
curl
https://search.maven.org/solrsearch/select?q="1:3f4de0db59b9085e41cc11c8c2914c427cc848e1";
{"responseHeader":{"status":0,"QTime":0,"params":{"q":"1:3f4de0db59b9085e41cc11c8c2914c427cc848e1","core":"","indent":"off","fl":"id,g,a,v,p,ec,timestamp,tags","start":"","sort":"score
desc,timestamp desc,g asc,a asc,v
desc","rows":"20","wt":"json","version":"2.2"}},"response":{"numFound":1,"start":0,"docs":[{"id":"org.springframework:spring-webmvc:5.3.17","g":"org.springframework","a":"spring-webmvc","v":"5.3.17","p":"jar","timestamp":1647516151000,"ec":[".module","-sources.jar",".pom","-javadoc.jar",".jar"],"tags":["spring"]}]}}{code}
Can you please help me to retrieve all the sha1 from the index?
I attach here the code I'm using [^mavensnippet.java].
Thank you very much
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MINVOKER-288) Failed setup job cause skip rest of jobs
[
https://issues.apache.org/jira/browse/MINVOKER-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MINVOKER-288:
-
Fix Version/s: 3.3.0
> Failed setup job cause skip rest of jobs
>
>
> Key: MINVOKER-288
> URL: https://issues.apache.org/jira/browse/MINVOKER-288
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.3.0
>
>
> When {{setup}} jobs fail for whatever reason all rest of jobs should be
> skipped.
> {{Setup}} jobs should be added to build reports and verification of tests
> result should fail.
> When somebody define {{setup}} jobs probably expect the result of its in the
> rest of test.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (SCM-913) NPE on ChangeSet.toString() when no mergedRevisions are set
[ https://issues.apache.org/jira/browse/SCM-913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed SCM-913. -- Resolution: Fixed 92a09124c9a0827a694dbf54a6e96370903bf658 > NPE on ChangeSet.toString() when no mergedRevisions are set > --- > > Key: SCM-913 > URL: https://issues.apache.org/jira/browse/SCM-913 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-api >Affects Versions: 1.11.1 >Reporter: Roli Jäger >Assignee: Michael Osipov >Priority: Major > Fix For: 1.13.0, 2.0.0-M2 > > > Calling toString() on ChangeSet will result in an NPE if neither > addMergedRevision () nor getMergedRevisions() was previously called. > The solution would be to access mergedRevisions by calling > getMergedRevisions() as done in the toXML() Method. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (SCM-913) NPE on ChangeSet.toString() when no mergedRevisions are set
[
https://issues.apache.org/jira/browse/SCM-913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539745#comment-17539745
]
Michael Osipov edited comment on SCM-913 at 5/19/22 6:57 PM:
-
Fixed with
[662b58a73d49ba2f7d728543ab6a10987b5324da|https://gitbox.apache.org/repos/asf?p=maven-scm.git;a=commit;h=662b58a73d49ba2f7d728543ab6a10987b5324da]
and with
[92a09124c9a0827a694dbf54a6e96370903bf658|https://gitbox.apache.org/repos/asf?p=maven-scm.git;a=commit;h=92a09124c9a0827a694dbf54a6e96370903bf658]
for {{maven-scm-1.x}} branch.
was (Author: michael-o):
92a09124c9a0827a694dbf54a6e96370903bf658
> NPE on ChangeSet.toString() when no mergedRevisions are set
> ---
>
> Key: SCM-913
> URL: https://issues.apache.org/jira/browse/SCM-913
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-api
>Affects Versions: 1.11.1
>Reporter: Roli Jäger
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.13.0, 2.0.0-M2
>
>
> Calling toString() on ChangeSet will result in an NPE if neither
> addMergedRevision () nor getMergedRevisions() was previously called.
> The solution would be to access mergedRevisions by calling
> getMergedRevisions() as done in the toXML() Method.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (SCM-979) Replace Plexus Container Default with Sisu Plexus Shim
Michael Osipov created SCM-979: -- Summary: Replace Plexus Container Default with Sisu Plexus Shim Key: SCM-979 URL: https://issues.apache.org/jira/browse/SCM-979 Project: Maven SCM Issue Type: Task Reporter: Michael Osipov Assignee: Tamás Cservenák Fix For: 2.0.0-M2 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-scm] michael-o commented on pull request #132: [SCM-925] Implement RemoveCommand in maven-scm-provider-jgit
michael-o commented on PR #132: URL: https://github.com/apache/maven-scm/pull/132#issuecomment-1132105508 @natami I am waiting for @G-Ork to move unrelated changes to separate PRs. -- 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] (SCM-925) RemoveCommand unsupported - maven-release-plugin:prepare-with-pom failing
[ https://issues.apache.org/jira/browse/SCM-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539753#comment-17539753 ] ASF GitHub Bot commented on SCM-925: michael-o commented on PR #132: URL: https://github.com/apache/maven-scm/pull/132#issuecomment-1132105508 @natami I am waiting for @G-Ork to move unrelated changes to separate PRs. > RemoveCommand unsupported - maven-release-plugin:prepare-with-pom failing > - > > Key: SCM-925 > URL: https://issues.apache.org/jira/browse/SCM-925 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-jgit >Affects Versions: 1.11.2 >Reporter: Georg Tsakumagos >Priority: Major > Attachments: maven-scm-provider-jgit.log > > Time Spent: 10m > Remaining Estimate: 0h > > The git scm plugins differs in support for the scm command _remove_. This > breaks the goal _prepare-with-pom_ of the _maven-release-plugin_ using the > _maven-scm-provider-jgit_. The method is not fully implemented and throws an > UnsupportedOperationException. > Referring to the ["Maven SCM Providers > Matrix"|https://maven.apache.org/scm/matrix.html] this feature is documented > as supported and should be implemented in the _jgit_ provider like in > maven-scm-provider-gitexe. > > ||Variant||remove supported||Source|| > |maven-scm-provider-gitexe|(/)|[Github - GitExeScmProvider.java - > getRemoveCommand()|https://github.com/apache/maven-scm/blob/a1f7e9857076940c878a370ff599b394df768d33/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/GitExeScmProvider.java#L97]| > |maven-scm-provider-jgit|(x)|[Github - JGitScmProvider.java - > getRemoveCommand()|https://github.com/apache/maven-scm/blob/a1f7e9857076940c878a370ff599b394df768d33/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-jgit/src/main/java/org/apache/maven/scm/provider/git/jgit/JGitScmProvider.java#L113]| > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (SCM-943) scm:check-local-modification does not support excludes
[
https://issues.apache.org/jira/browse/SCM-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated SCM-943:
---
Issue Type: Improvement (was: Bug)
> scm:check-local-modification does not support excludes
> --
>
> Key: SCM-943
> URL: https://issues.apache.org/jira/browse/SCM-943
> Project: Maven SCM
> Issue Type: Improvement
>Reporter: Michiel Kalkman
>Priority: Major
>
> It seems like scm:check-local-modification does not support the excludes and
> includes parameters. Which is annoying, because I want to exclude *.iml from
> Intellij from this check.
> Looking (but not yet testing) at CheckLocalModificationsMojo::execute(), it
> does:
> {code:java}
> result = getScmManager().status( repository, new ScmFileSet( baseDirectory )
> );
> {code}
> So it does not address neither includes, nor excludes parameter.
> My first though would be that something like this is the start of fix:
> {code:java}
> result = getScmManager().status( repository, new ScmFileSet(
> getWorkingDirectory(), getIncludes(), getExcludes() ) );
> {code}
> Is this something that has not yet been implemented, or is there a user error
> on my part?
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SCM-943) scm:check-local-modification does not support excludes
[
https://issues.apache.org/jira/browse/SCM-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated SCM-943:
---
Fix Version/s: 1.13.0
2.0.0-M2
> scm:check-local-modification does not support excludes
> --
>
> Key: SCM-943
> URL: https://issues.apache.org/jira/browse/SCM-943
> Project: Maven SCM
> Issue Type: Improvement
>Reporter: Michiel Kalkman
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.13.0, 2.0.0-M2
>
>
> It seems like scm:check-local-modification does not support the excludes and
> includes parameters. Which is annoying, because I want to exclude *.iml from
> Intellij from this check.
> Looking (but not yet testing) at CheckLocalModificationsMojo::execute(), it
> does:
> {code:java}
> result = getScmManager().status( repository, new ScmFileSet( baseDirectory )
> );
> {code}
> So it does not address neither includes, nor excludes parameter.
> My first though would be that something like this is the start of fix:
> {code:java}
> result = getScmManager().status( repository, new ScmFileSet(
> getWorkingDirectory(), getIncludes(), getExcludes() ) );
> {code}
> Is this something that has not yet been implemented, or is there a user error
> on my part?
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (SCM-943) scm:check-local-modification does not support excludes
[
https://issues.apache.org/jira/browse/SCM-943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned SCM-943:
--
Assignee: Michael Osipov
> scm:check-local-modification does not support excludes
> --
>
> Key: SCM-943
> URL: https://issues.apache.org/jira/browse/SCM-943
> Project: Maven SCM
> Issue Type: Improvement
>Reporter: Michiel Kalkman
>Assignee: Michael Osipov
>Priority: Major
>
> It seems like scm:check-local-modification does not support the excludes and
> includes parameters. Which is annoying, because I want to exclude *.iml from
> Intellij from this check.
> Looking (but not yet testing) at CheckLocalModificationsMojo::execute(), it
> does:
> {code:java}
> result = getScmManager().status( repository, new ScmFileSet( baseDirectory )
> );
> {code}
> So it does not address neither includes, nor excludes parameter.
> My first though would be that something like this is the start of fix:
> {code:java}
> result = getScmManager().status( repository, new ScmFileSet(
> getWorkingDirectory(), getIncludes(), getExcludes() ) );
> {code}
> Is this something that has not yet been implemented, or is there a user error
> on my part?
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (SCM-943) scm:check-local-modification does not support excludes
[
https://issues.apache.org/jira/browse/SCM-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539765#comment-17539765
]
Michael Osipov commented on SCM-943:
While the request ist valid, IDE files belong to the ignore config of your SCM.
> scm:check-local-modification does not support excludes
> --
>
> Key: SCM-943
> URL: https://issues.apache.org/jira/browse/SCM-943
> Project: Maven SCM
> Issue Type: Improvement
>Reporter: Michiel Kalkman
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.13.0, 2.0.0-M2
>
>
> It seems like scm:check-local-modification does not support the excludes and
> includes parameters. Which is annoying, because I want to exclude *.iml from
> Intellij from this check.
> Looking (but not yet testing) at CheckLocalModificationsMojo::execute(), it
> does:
> {code:java}
> result = getScmManager().status( repository, new ScmFileSet( baseDirectory )
> );
> {code}
> So it does not address neither includes, nor excludes parameter.
> My first though would be that something like this is the start of fix:
> {code:java}
> result = getScmManager().status( repository, new ScmFileSet(
> getWorkingDirectory(), getIncludes(), getExcludes() ) );
> {code}
> Is this something that has not yet been implemented, or is there a user error
> on my part?
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-release] asfgit closed pull request #123: [MRELEASE-1090] Drop usage of dead M2_HOME environment variable
asfgit closed pull request #123: [MRELEASE-1090] Drop usage of dead M2_HOME environment variable URL: https://github.com/apache/maven-release/pull/123 -- 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] (MRELEASE-1090) Drop usage of dead M2_HOME environment variable
[ https://issues.apache.org/jira/browse/MRELEASE-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MRELEASE-1090. Resolution: Fixed Fixed with [21786b61c6385ebfc663155025d9e1657f44cabc|https://gitbox.apache.org/repos/asf?p=maven-release.git;a=commit;h=21786b61c6385ebfc663155025d9e1657f44cabc]. > Drop usage of dead M2_HOME environment variable > --- > > Key: MRELEASE-1090 > URL: https://issues.apache.org/jira/browse/MRELEASE-1090 > Project: Maven Release Plugin > Issue Type: Task >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.0.0-M6 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (SCM-980) Remove code duplication in ListMojo
Michael Osipov created SCM-980:
--
Summary: Remove code duplication in ListMojo
Key: SCM-980
URL: https://issues.apache.org/jira/browse/SCM-980
Project: Maven SCM
Issue Type: Task
Components: maven-plugin
Affects Versions: 1.12.2
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: 1.13.0, 2.0.0-M2
The {{ListMojo}} has a {{getFileSet()}} method which is exactly the same as in
{{AbstractScmMojo.getFileSet()}}. This duplication shall be removed.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MRELEASE-1090) Drop usage of dead M2_HOME environment variable
[ https://issues.apache.org/jira/browse/MRELEASE-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539775#comment-17539775 ] Hudson commented on MRELEASE-1090: -- Build succeeded in Jenkins: Maven » Maven TLP » maven-release » master #35 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-release/job/master/35/ > Drop usage of dead M2_HOME environment variable > --- > > Key: MRELEASE-1090 > URL: https://issues.apache.org/jira/browse/MRELEASE-1090 > Project: Maven Release Plugin > Issue Type: Task >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.0.0-M6 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-mvnd] ppalaga commented on pull request #654: Make mvnd coloring more consistent with maven, fixes #653
ppalaga commented on PR #654: URL: https://github.com/apache/maven-mvnd/pull/654#issuecomment-1132170929 Thanks, for the images. I'd vote for not rendering the execution in bold. I do not think it is more important than other things in the UI and hence the highlighting is not necessary. WDYT @hboutemy ? -- 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
[GitHub] [maven-mvnd] ppalaga commented on pull request #654: Make mvnd coloring more consistent with maven, fixes #653
ppalaga commented on PR #654: URL: https://github.com/apache/maven-mvnd/pull/654#issuecomment-1132171541 Thanks, for the images. I'd vote for not rendering the execution in bold. I do not think it is more important than other things in the UI and hence the highlighting is not necessary. WDYT @hboutemy ? -- 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
[GitHub] [maven-mvnd] ppalaga closed pull request #654: Make mvnd coloring more consistent with maven, fixes #653
ppalaga closed pull request #654: Make mvnd coloring more consistent with maven, fixes #653 URL: https://github.com/apache/maven-mvnd/pull/654 -- 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
[GitHub] [maven-mvnd] ppalaga commented on pull request #654: Make mvnd coloring more consistent with maven, fixes #653
ppalaga commented on PR #654: URL: https://github.com/apache/maven-mvnd/pull/654#issuecomment-1132172017 Ups, sorry, I have hit a wrong button. -- 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
[GitHub] [maven-scm] michael-o commented on a diff in pull request #135: [SCM-977] Support for retrieving tags from the changelog
michael-o commented on code in PR #135:
URL: https://github.com/apache/maven-scm/pull/135#discussion_r877513964
##
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/test/java/org/apache/maven/scm/provider/git/gitexe/command/changelog/GitChangeLogConsumerTest.java:
##
@@ -172,4 +173,72 @@ public void testConsumer2()
assertTrue( cf.getRevision() != null && cf.getRevision().length() > 0
);
}
+public void testGitLogConsumer3()
+throws Exception
+{
+GitChangeLogConsumer consumer = new GitChangeLogConsumer( new
DefaultLog(), null );
+
+File f = getTestFile(
"/src/test/resources/git/changelog/gitlog3.gitlog" );
+
+ConsumerUtils.consumeFile( f, consumer );
+
+List modifications = consumer.getModifications();
+
+assertEquals( 10, modifications.size() );
+
+SimpleDateFormat sdf = new SimpleDateFormat( "-MM-dd HH:mm:ss Z" );
+sdf.setTimeZone( TimeZone.getTimeZone( "GMT" ) );
Review Comment:
This is error-prone and will likely fail. Git, unfortunately, stores
timestamp and offset. You never know in which offset the output will be because
it depends on the author's/committer's system offset. Ideally, the pattern
autorecognizes the offset.
WDYT?
##
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/test/java/org/apache/maven/scm/provider/git/gitexe/command/changelog/GitChangeLogConsumerTest.java:
##
@@ -172,4 +173,72 @@ public void testConsumer2()
assertTrue( cf.getRevision() != null && cf.getRevision().length() > 0
);
}
+public void testGitLogConsumer3()
+throws Exception
+{
+GitChangeLogConsumer consumer = new GitChangeLogConsumer( new
DefaultLog(), null );
+
+File f = getTestFile(
"/src/test/resources/git/changelog/gitlog3.gitlog" );
+
+ConsumerUtils.consumeFile( f, consumer );
+
+List modifications = consumer.getModifications();
+
+assertEquals( 10, modifications.size() );
+
+SimpleDateFormat sdf = new SimpleDateFormat( "-MM-dd HH:mm:ss Z" );
+sdf.setTimeZone( TimeZone.getTimeZone( "GMT" ) );
+
+ChangeSet first = modifications.get(0);
+assertEquals( "Michael Osipov ",
first.getAuthor() );
+assertEquals( "2022-01-08 20:02:12 +", sdf.format( first.getDate()
) );
+assertEquals( "[maven-release-plugin] prepare for next development
iteration", first.getComment() );
+assertEquals( "4fc34cfa14f2e72506187b03a492ce55ed459d4c",
first.getRevision() );
+assertEquals( Collections.emptyList(), first.getTags() );
+assertNotNull( first.getFiles() );
+assertFalse( first.getFiles().isEmpty() );
+
+ChangeSet second = modifications.get(1);
+assertEquals( "Michael Osipov ",
second.getAuthor() );
+assertEquals( "2022-01-08 20:02:01 +", sdf.format(
second.getDate() ) );
+assertEquals( "[maven-release-plugin] prepare release
maven-scm-2.0.0-M1", second.getComment() );
+assertEquals( "3a6d9817fe809c43eca588d7c0f4428254eae17c",
second.getRevision() );
+assertEquals( Collections.singletonList("maven-scm-2.0.0-M1"),
second.getTags() );
+assertNotNull( second.getFiles() );
+assertFalse( second.getFiles().isEmpty() );
+}
+
+public void testTagAndBranchConsumer() {
+String[] lines = {
+"commit a6d03ee7bcec7bfd6b0fc890a277f004a1c54077 (HEAD -> main,
tag: TestTag, origin/main, origin/HEAD)",
+"Author: Niels Basjes ",
+"Date: 2022-02-06 16:19:01 +0100",
+"",
+"This",
+"is",
+"a",
+"multiline",
+"comment",
+"",
+":100644 100644 2019174 808473f M\tdocumentation/pom.xml",
+""
+};
+GitChangeLogConsumer consumer = new GitChangeLogConsumer( new
DefaultLog(), null );
+
+for (String line : lines) {
+consumer.consumeLine(line);
Review Comment:
spaces missing
--
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] (SCM-977) Retrieve the tags on commits using the changelog command.
[
https://issues.apache.org/jira/browse/SCM-977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17539788#comment-17539788
]
ASF GitHub Bot commented on SCM-977:
michael-o commented on code in PR #135:
URL: https://github.com/apache/maven-scm/pull/135#discussion_r877513964
##
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/test/java/org/apache/maven/scm/provider/git/gitexe/command/changelog/GitChangeLogConsumerTest.java:
##
@@ -172,4 +173,72 @@ public void testConsumer2()
assertTrue( cf.getRevision() != null && cf.getRevision().length() > 0
);
}
+public void testGitLogConsumer3()
+throws Exception
+{
+GitChangeLogConsumer consumer = new GitChangeLogConsumer( new
DefaultLog(), null );
+
+File f = getTestFile(
"/src/test/resources/git/changelog/gitlog3.gitlog" );
+
+ConsumerUtils.consumeFile( f, consumer );
+
+List modifications = consumer.getModifications();
+
+assertEquals( 10, modifications.size() );
+
+SimpleDateFormat sdf = new SimpleDateFormat( "-MM-dd HH:mm:ss Z" );
+sdf.setTimeZone( TimeZone.getTimeZone( "GMT" ) );
Review Comment:
This is error-prone and will likely fail. Git, unfortunately, stores
timestamp and offset. You never know in which offset the output will be because
it depends on the author's/committer's system offset. Ideally, the pattern
autorecognizes the offset.
WDYT?
##
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/test/java/org/apache/maven/scm/provider/git/gitexe/command/changelog/GitChangeLogConsumerTest.java:
##
@@ -172,4 +173,72 @@ public void testConsumer2()
assertTrue( cf.getRevision() != null && cf.getRevision().length() > 0
);
}
+public void testGitLogConsumer3()
+throws Exception
+{
+GitChangeLogConsumer consumer = new GitChangeLogConsumer( new
DefaultLog(), null );
+
+File f = getTestFile(
"/src/test/resources/git/changelog/gitlog3.gitlog" );
+
+ConsumerUtils.consumeFile( f, consumer );
+
+List modifications = consumer.getModifications();
+
+assertEquals( 10, modifications.size() );
+
+SimpleDateFormat sdf = new SimpleDateFormat( "-MM-dd HH:mm:ss Z" );
+sdf.setTimeZone( TimeZone.getTimeZone( "GMT" ) );
+
+ChangeSet first = modifications.get(0);
+assertEquals( "Michael Osipov ",
first.getAuthor() );
+assertEquals( "2022-01-08 20:02:12 +", sdf.format( first.getDate()
) );
+assertEquals( "[maven-release-plugin] prepare for next development
iteration", first.getComment() );
+assertEquals( "4fc34cfa14f2e72506187b03a492ce55ed459d4c",
first.getRevision() );
+assertEquals( Collections.emptyList(), first.getTags() );
+assertNotNull( first.getFiles() );
+assertFalse( first.getFiles().isEmpty() );
+
+ChangeSet second = modifications.get(1);
+assertEquals( "Michael Osipov ",
second.getAuthor() );
+assertEquals( "2022-01-08 20:02:01 +", sdf.format(
second.getDate() ) );
+assertEquals( "[maven-release-plugin] prepare release
maven-scm-2.0.0-M1", second.getComment() );
+assertEquals( "3a6d9817fe809c43eca588d7c0f4428254eae17c",
second.getRevision() );
+assertEquals( Collections.singletonList("maven-scm-2.0.0-M1"),
second.getTags() );
+assertNotNull( second.getFiles() );
+assertFalse( second.getFiles().isEmpty() );
+}
+
+public void testTagAndBranchConsumer() {
+String[] lines = {
+"commit a6d03ee7bcec7bfd6b0fc890a277f004a1c54077 (HEAD -> main,
tag: TestTag, origin/main, origin/HEAD)",
+"Author: Niels Basjes ",
+"Date: 2022-02-06 16:19:01 +0100",
+"",
+"This",
+"is",
+"a",
+"multiline",
+"comment",
+"",
+":100644 100644 2019174 808473f M\tdocumentation/pom.xml",
+""
+};
+GitChangeLogConsumer consumer = new GitChangeLogConsumer( new
DefaultLog(), null );
+
+for (String line : lines) {
+consumer.consumeLine(line);
Review Comment:
spaces missing
> Retrieve the tags on commits using the changelog command.
> -
>
> Key: SCM-977
> URL: https://issues.apache.org/jira/browse/SCM-977
> Project: Maven SCM
> Issue Type: New Feature
> Components: maven-scm-api, maven-scm-provider-gitexe,
> maven-scm-provider-jgit, maven-scm-provider-mercurial (hg)
>Reporter: Niels Basjes
>Priority: Major
>
> My aim is to support having something like
> [https://www.conventionalcommits.org/] in the maven-release-plugin.
> This simp
