[jira] [Comment Edited] (SUREFIRE-2004) Empty report for single-module project with 'aggregate=true'
[
https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516425#comment-17516425
]
Alexander Kriegisch edited comment on SUREFIRE-2004 at 4/3/22 4:53 AM:
---
[~tibordigana], I understand [~gzm55]'s question, because Surefire release
cycles are quite long. I quickly checked on Maven Central: The first Surefire 3
milestone was released in November 2018, i.e. ~3.5 years ago. The current
milestone 5 was released in June 2020, almost 2 years ago. I myself have been
using self-built releases since M5, because bugs were either not fixed or after
being fixed there was no non-snapshot release.
I fully understand that everyone involved in Surefire is doing their best,
working for free and in their spare time. But from a user perspective, these
"milestones" take longer than major or at least minor releases in some other
projects. Even a giant like Java has a 6 month release cadence. Would you mind
taking this topic into your next meeting or written exchange with your
co-developers and explore options to release more often? Even small bugfix or
feature releases would take some pressure off of both the dev team and the user
community.
was (Author: kriegaex):
[~tibordigana], I understand [~gzm55]'s question, because Surefire release
cycles are quite long. I quickly checked on Maven Central: The first Surefire 3
milestone was released in November 2018, i.e. ~3.5 years ago. The current
milestone 5 was released in June 2020, almost 2 years ago. I myself have been
using self-built releases since M5, because bugs were either not fixed or after
being fixed there was no non-snapshot release.
I fully understand that everyone involved in Surefire is doing their best,
working for free and in their sparetime. But from a user perspective, these
"milestones" take longer than major or at least minor releases in some other
projects. Even a giant like Java has a 6 month release cadence. Would you mind
taking this topic into your next meeting or written exchange with your
co-developers and explore options to release more often? Even small bugfix or
feature releases would take some pressure off of both the dev team and the user
community.
> Empty report for single-module project with 'aggregate=true'
>
>
> Key: SUREFIRE-2004
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2004
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.4, 3.0.0-M5
>Reporter: Alexander Kriegisch
>Priority: Major
> Fix For: waiting-for-apache-feedback
>
>
> Using either {{-Daggregate=true}} on CLI or {{true}}
> in the plugin configuration leads to an empty report (i.e. zero tests
> reported) when e.g. executing
> {code:none}
> mvn -Dmaven.test.failure.ignore=true -Daggregate=true clean verify
> surefire-report:report-only
> {code}
> in the context of a single-module project. As soon as I make the root module
> pom-packaged and move the tests to into a child module, the aggregate report
> works.
> FYI, if I do not define the plugin and its version in my POM at all, the
> default version 2.4 used by Maven on my workstation has the same problem, so
> this does not seem to be a 3.0.0-M5 issue only.
>
> Background info about how and why I actually stumbled across this problem: I
> have an OSS multi-module project with lots of expensive UI tests. The full
> build can take 2.5 hours. I wanted to test a few CLI settings before creating
> an additional GitHub CI build workflow which can be run on demand and always
> runs all tests in all modules (ignoring errors and failures), no matter what.
> In the end, it is supposed to create a single-file aggregate HTML report
> which can easily be attached to the build and later is available for
> download, if the user so chooses in order to analyse failing tests
> comfortable and without having to scroll through build logs. You get the
> picture, I guess. In the original project, there is a pom-packaged root POM,
> so the problem described in this issue does not occur there. I simply created
> a single-module dummy project in order to verify the effect of certain build
> options quickly and not having to wait for the slow original build to finish.
> Eventually, I noticed the issue described above.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (SUREFIRE-2004) Empty report for single-module project with 'aggregate=true'
[
https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516425#comment-17516425
]
Alexander Kriegisch edited comment on SUREFIRE-2004 at 4/3/22 3:16 AM:
---
[~tibordigana], I understand [~gzm55]'s question, because Surefire release
cycles are quite long. I quickly checked on Maven Central: The first Surefire 3
milestone was released in November 2018, i.e. ~3.5 years ago. The current
milestone 5 was released in June 2020, almost 2 years ago. I myself have been
using self-built releases since M5, because bugs were either not fixed or after
being fixed there was no non-snapshot release.
I fully understand that everyone involved in Surefire is doing their best,
working for free and in their sparetime. But from a user perspective, these
"milestones" take longer than major or at least minor releases in some other
projects. Even a giant like Java has a 6 month release cadence. Would you mind
taking this topic into your next meeting or written exchange with your
co-developers and explore options to release more often? Even small bugfix or
feature releases would take some pressure off of both the dev team and the user
community.
was (Author: kriegaex):
[~tibordigana], I understand [~gzm55]'s question, because Surefire release
cycles are quite long. I quickly checked on Maven Central: The first Surefire 3
milestone was released in November 2018, i.e. ~3.5 years ago. The current
milestone 5 was released in June 2020, almost 2 years ago. I myself have been
using self-built releases since M5, because bugs were either not fixed or after
being fixed there was not non-snapshot release.
I fully understand that everyone involved in Surefire is doing their best,
working for free and in their sparetime. But from a user perspective, these
"milestones" take longer than major or at least minor releases in some other
projects. Even a giant like Java has a 6 month release cadence. Would you mind
taking this topic into your next meeting or written exchange with your
co-developers and explore options to release more often? Even small bugfix or
feature releases would take some pressure off of both the dev team and the user
community.
> Empty report for single-module project with 'aggregate=true'
>
>
> Key: SUREFIRE-2004
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2004
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.4, 3.0.0-M5
>Reporter: Alexander Kriegisch
>Priority: Major
> Fix For: waiting-for-apache-feedback
>
>
> Using either {{-Daggregate=true}} on CLI or {{true}}
> in the plugin configuration leads to an empty report (i.e. zero tests
> reported) when e.g. executing
> {code:none}
> mvn -Dmaven.test.failure.ignore=true -Daggregate=true clean verify
> surefire-report:report-only
> {code}
> in the context of a single-module project. As soon as I make the root module
> pom-packaged and move the tests to into a child module, the aggregate report
> works.
> FYI, if I do not define the plugin and its version in my POM at all, the
> default version 2.4 used by Maven on my workstation has the same problem, so
> this does not seem to be a 3.0.0-M5 issue only.
>
> Background info about how and why I actually stumbled across this problem: I
> have an OSS multi-module project with lots of expensive UI tests. The full
> build can take 2.5 hours. I wanted to test a few CLI settings before creating
> an additional GitHub CI build workflow which can be run on demand and always
> runs all tests in all modules (ignoring errors and failures), no matter what.
> In the end, it is supposed to create a single-file aggregate HTML report
> which can easily be attached to the build and later is available for
> download, if the user so chooses in order to analyse failing tests
> comfortable and without having to scroll through build logs. You get the
> picture, I guess. In the original project, there is a pom-packaged root POM,
> so the problem described in this issue does not occur there. I simply created
> a single-module dummy project in order to verify the effect of certain build
> options quickly and not having to wait for the slow original build to finish.
> Eventually, I noticed the issue described above.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2004) Empty report for single-module project with 'aggregate=true'
[
https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516425#comment-17516425
]
Alexander Kriegisch commented on SUREFIRE-2004:
---
[~tibordigana], I understand [~gzm55]'s question, because Surefire release
cycles are quite long. I quickly checked on Maven Central: The first Surefire 3
milestone was released in November 2018, i.e. ~3.5 years ago. The current
milestone 5 was released in June 2020, almost 2 years ago. I myself have been
using self-built releases since M5, because bugs were either not fixed or after
being fixed there was not non-snapshot release.
I fully understand that everyone involved in Surefire is doing their best,
working for free and in their sparetime. But from a user perspective, these
"milestones" take longer than major or at least minor releases in some other
projects. Even a giant like Java has a 6 month release cadence. Would you mind
taking this topic into your next meeting or written exchange with your
co-developers and explore options to release more often? Even small bugfix or
feature releases would take some pressure off of both the dev team and the user
community.
> Empty report for single-module project with 'aggregate=true'
>
>
> Key: SUREFIRE-2004
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2004
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.4, 3.0.0-M5
>Reporter: Alexander Kriegisch
>Priority: Major
> Fix For: waiting-for-apache-feedback
>
>
> Using either {{-Daggregate=true}} on CLI or {{true}}
> in the plugin configuration leads to an empty report (i.e. zero tests
> reported) when e.g. executing
> {code:none}
> mvn -Dmaven.test.failure.ignore=true -Daggregate=true clean verify
> surefire-report:report-only
> {code}
> in the context of a single-module project. As soon as I make the root module
> pom-packaged and move the tests to into a child module, the aggregate report
> works.
> FYI, if I do not define the plugin and its version in my POM at all, the
> default version 2.4 used by Maven on my workstation has the same problem, so
> this does not seem to be a 3.0.0-M5 issue only.
>
> Background info about how and why I actually stumbled across this problem: I
> have an OSS multi-module project with lots of expensive UI tests. The full
> build can take 2.5 hours. I wanted to test a few CLI settings before creating
> an additional GitHub CI build workflow which can be run on demand and always
> runs all tests in all modules (ignoring errors and failures), no matter what.
> In the end, it is supposed to create a single-file aggregate HTML report
> which can easily be attached to the build and later is available for
> download, if the user so chooses in order to analyse failing tests
> comfortable and without having to scroll through build logs. You get the
> picture, I guess. In the original project, there is a pom-packaged root POM,
> so the problem described in this issue does not occur there. I simply created
> a single-module dummy project in order to verify the effect of certain build
> options quickly and not having to wait for the slow original build to finish.
> Eventually, I noticed the issue described above.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
question about Maven Surefire Plugin
We are using testng for testing, and I added a new class using powermockito (the test class extends PowerMockTestCase) However we got an exception with another class that uses powermocks's WhiteboxImpl.invokeMethod(). The exception is "Cannot cast org.powermock.api.mockito.mockmaker.PowerMockMaker to org.mockito.plugins.MockMaker" In order to avoid that exception with one class, my workaround (which may not be best solution but all I could find) was to add "extends TestCase" which assigned that class to run with Junit4 instead of TestNG like all the others. The problem now becomes that during a static analysis Jenkins phase, it looks for but can't find the surefire files in target/surefire-reports/junitreports like they were before. Because after the change mentioned above (forcing JUNIT by extending TestCase) the surefire files are now divided into 2 subdirectories: testng-native-results and testng-junit-results. This is causing the problem Is there a way to prevent surefire tests from being divided between the 2 directories?
[jira] [Commented] (MARTIFACT-31) wrong comparison results when buildinfo has been published to Central
[ https://issues.apache.org/jira/browse/MARTIFACT-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516401#comment-17516401 ] Hudson commented on MARTIFACT-31: - Build succeeded in Jenkins: Maven » Maven TLP » maven-artifact-plugin » master #4 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-artifact-plugin/job/master/4/ > wrong comparison results when buildinfo has been published to Central > - > > Key: MARTIFACT-31 > URL: https://issues.apache.org/jira/browse/MARTIFACT-31 > Project: Maven Artifact Plugin > Issue Type: Bug > Components: artifact:compare >Affects Versions: 3.2.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.3.0 > > > trying to rebuild OWASP Dependency Check 6.5.0 on Reproducible Central leads > to many false differences found -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MARTIFACT-31) wrong comparison results when buildinfo has been published to Central
[ https://issues.apache.org/jira/browse/MARTIFACT-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MARTIFACT-31. -- Resolution: Fixed fixed in https://github.com/apache/maven-artifact-plugin/commit/4baa2a8ab0a83391511f573ab98c21b6b5905b7f > wrong comparison results when buildinfo has been published to Central > - > > Key: MARTIFACT-31 > URL: https://issues.apache.org/jira/browse/MARTIFACT-31 > Project: Maven Artifact Plugin > Issue Type: Bug > Components: artifact:compare >Affects Versions: 3.2.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.3.0 > > > trying to rebuild OWASP Dependency Check 6.5.0 on Reproducible Central leads > to many false differences found -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MARTIFACT-31) wrong comparison results when buildinfo has been published to Central
[ https://issues.apache.org/jira/browse/MARTIFACT-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516397#comment-17516397 ] Herve Boutemy commented on MARTIFACT-31: after deep dive, root cause is that Dependency Check has published a buildinfo generated with maven-artifact-plugin 3.1.0 while rebuilding on Reproducible Central uses maven-artifact-plugin 3.2.0: this releases checks poms that were not checked before, then buildinfo does not have contain same files identifiers... we can't use downloaded reference buildinfo to automatically check against actual buildinfo... > wrong comparison results when buildinfo has been published to Central > - > > Key: MARTIFACT-31 > URL: https://issues.apache.org/jira/browse/MARTIFACT-31 > Project: Maven Artifact Plugin > Issue Type: Bug > Components: artifact:compare >Affects Versions: 3.2.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.3.0 > > > trying to rebuild OWASP Dependency Check 6.5.0 on Reproducible Central leads > to many false differences found -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MARTIFACT-31) wrong comparison results when buildinfo has been published to Central
Herve Boutemy created MARTIFACT-31: -- Summary: wrong comparison results when buildinfo has been published to Central Key: MARTIFACT-31 URL: https://issues.apache.org/jira/browse/MARTIFACT-31 Project: Maven Artifact Plugin Issue Type: Bug Components: artifact:compare Affects Versions: 3.2.0 Reporter: Herve Boutemy Assignee: Herve Boutemy Fix For: 3.3.0 trying to rebuild OWASP Dependency Check 6.5.0 on Reproducible Central leads to many false differences found -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2033) Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
[
https://issues.apache.org/jira/browse/SUREFIRE-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516382#comment-17516382
]
Robert James Oxspring commented on SUREFIRE-2033:
-
If the {{junit-platform-runner}} is a compile time dependency of the project,
it cannot be deleted from the POM.
> Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
> ---
>
> Key: SUREFIRE-2033
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2033
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Robert James Oxspring
>Priority: Major
> Attachments: example.zip
>
>
> 3.0.0-M5 misidentifies a clearly JUnit 5 configuration and attempts to run
> using JUnit 4.
> In particular the attached project only has JUnit 5 dependencies:
> {code:java}
>
>
> org.junit.jupiter
> junit-jupiter-engine
> 5.6.2
> test
>
>
> org.junit.platform
> junit-platform-runner
> 1.6.2
> test
>
> {code}
> and a JUnit 5 test:
> {code:java}
> package pkg;
> import org.junit.jupiter.api.Test;
> class JUnit5Test {
> @Test
> public void test() {
> }
> }{code}
> When the project is run with with older version (as far back as 2.22.0) the
> test is found and run, but 3.0.0-M5 fails to run any test:
> {code:java}
> % mvn test -Dsurefire.version=2.22.0 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.337 s
> [INFO] Finished at: 2022-03-03T09:42:27Z
> [INFO]
>
> {code}
>
> {code:java}
> % mvn test -Dsurefire.version=3.0.0-M1 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.708 s
> [INFO] Finished at: 2022-03-03T09:34:58Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M2 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.701 s
> [INFO] Finished at: 2022-03-03T09:36:26Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M3 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.612 s
> [INFO] Finished at: 2022-03-03T09:37:02Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M4 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.619 s
> [INFO] Finished at: 2022-03-03T09:37:37Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M5 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.344 s
> [INFO] Finished at: 2022-03-03T09:38:01Z
> [INFO]
> {code}
> Note the final run above using 3.0.0-M5 and logging: {{Tests run: 0}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MSHADE-378) Shade plugin changes the compression level of nested jar entries
[ https://issues.apache.org/jira/browse/MSHADE-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MSHADE-378. Fix Version/s: 3.3.0 Assignee: Romain Manni-Bucau Resolution: Fixed PR merged in https://github.com/apache/maven-shade-plugin/commit/c798d01138e9fecdd6422a2a8acce22ca8987924 > Shade plugin changes the compression level of nested jar entries > > > Key: MSHADE-378 > URL: https://issues.apache.org/jira/browse/MSHADE-378 > Project: Maven Shade Plugin > Issue Type: Bug >Reporter: jeremy yu >Assignee: Romain Manni-Bucau >Priority: Major > Fix For: 3.3.0 > > > I'm trying to shade a part of dependencies from a flat jar which contains > many nested jars. However, after shading, the nested jars can't be loaded in > JVM and an exception is thrown: "Exception in thread "main" > java.lang.IllegalStateException: Unable to open nested entry > 'xxx/x.jar'.It has been compressed and nested jar files must be stored > without compression. Please check the mechanism used to create your > executable jar file" > The reseaon of the above case is that shade plugin loses the meta information > of orignal jar entries when copying nested jar (see DefaultShade#addResource > method). > I am happy to submit a fix for this, but I am not so sure about my solution. > I would appreciate if someone can review my fix and give me guidance. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MSHADE-417) Nul bytes appended to small files by maven-shade-plugin
[
https://issues.apache.org/jira/browse/MSHADE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516370#comment-17516370
]
Romain Manni-Bucau commented on MSHADE-417:
---
Yep please close as fixed. I used romain.manni-bucau since a bit more for most
asf project, only openejb used rmannibucau before switching, not sure where the
assumption the same name is used on both systems comes from but happy to fix it
if it is a missed update sby can point out.
> Nul bytes appended to small files by maven-shade-plugin
> ---
>
> Key: MSHADE-417
> URL: https://issues.apache.org/jira/browse/MSHADE-417
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Max Zerzouri
>Priority: Major
> Attachments: original-shadetest-0.0.0.jar, pom.xml,
> shadetest-0.0.0.jar, test.txt
>
>
> Version 3.3.0 of maven shade plugin seems to append "\x00" bytes to a file if
> it's less than 4 bytes:
> {code:sh}
> $ echo -n a > src/main/resources/test.txt
> $ mvn clean install
> ...
> $ bsdtar -xOf target/original-shadetest-0.0.0.jar test.txt | xxd
> : 61 a
> $ bsdtar -xOf target/shadetest-0.0.0.jar test.txt | xxd
> : 6100 a...
> {code}
> I've attached a basic {{pom.xml}} that triggers this. This doesn't occur in
> the previous version, 3.2.4.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2033) Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
[
https://issues.apache.org/jira/browse/SUREFIRE-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516363#comment-17516363
]
Tibor Digana commented on SUREFIRE-2033:
If previous versions executed junit5 tests without platform-runner's annotation
then it means that the {{junit-platform-runner}} can be freely deleted in POM
dependencies.
> Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
> ---
>
> Key: SUREFIRE-2033
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2033
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Robert James Oxspring
>Priority: Major
> Attachments: example.zip
>
>
> 3.0.0-M5 misidentifies a clearly JUnit 5 configuration and attempts to run
> using JUnit 4.
> In particular the attached project only has JUnit 5 dependencies:
> {code:java}
>
>
> org.junit.jupiter
> junit-jupiter-engine
> 5.6.2
> test
>
>
> org.junit.platform
> junit-platform-runner
> 1.6.2
> test
>
> {code}
> and a JUnit 5 test:
> {code:java}
> package pkg;
> import org.junit.jupiter.api.Test;
> class JUnit5Test {
> @Test
> public void test() {
> }
> }{code}
> When the project is run with with older version (as far back as 2.22.0) the
> test is found and run, but 3.0.0-M5 fails to run any test:
> {code:java}
> % mvn test -Dsurefire.version=2.22.0 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.337 s
> [INFO] Finished at: 2022-03-03T09:42:27Z
> [INFO]
>
> {code}
>
> {code:java}
> % mvn test -Dsurefire.version=3.0.0-M1 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.708 s
> [INFO] Finished at: 2022-03-03T09:34:58Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M2 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.701 s
> [INFO] Finished at: 2022-03-03T09:36:26Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M3 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.612 s
> [INFO] Finished at: 2022-03-03T09:37:02Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M4 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.619 s
> [INFO] Finished at: 2022-03-03T09:37:37Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M5 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.344 s
> [INFO] Finished at: 2022-03-03T09:38:01Z
> [INFO]
> {code}
> Note the final run above using 3.0.0-M5 and logging: {{Tests run: 0}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MSHADE-417) Nul bytes appended to small files by maven-shade-plugin
[
https://issues.apache.org/jira/browse/MSHADE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516361#comment-17516361
]
Herve Boutemy commented on MSHADE-417:
--
I don't know where "on Slack" it has been reported, but merging a PR and not
asking others help for the Jira part is not really a good move: IIUC, I should
close MSHADE-378 as fixed in 3.3.0?
then on you not having perms: I see there are 2 profiles
* the profile that is member of maven, but also members and a few other ones
is [https://issues.apache.org/jira/secure/ViewProfile.jspa?name=rmannibucau]
that you used until 2015, and matches your Apache id
* you seem to be now using
[https://issues.apache.org/jira/secure/ViewProfile.jspa?name=romain.manni-bucau]
which is an external user
You should define if you recover your initial account that matches your Apache
id or really want to switch to the new one
then if you want to switch, you'll need to ask INFRA about it
(all that does not really have to do anything with Maven...)
> Nul bytes appended to small files by maven-shade-plugin
> ---
>
> Key: MSHADE-417
> URL: https://issues.apache.org/jira/browse/MSHADE-417
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Max Zerzouri
>Priority: Major
> Attachments: original-shadetest-0.0.0.jar, pom.xml,
> shadetest-0.0.0.jar, test.txt
>
>
> Version 3.3.0 of maven shade plugin seems to append "\x00" bytes to a file if
> it's less than 4 bytes:
> {code:sh}
> $ echo -n a > src/main/resources/test.txt
> $ mvn clean install
> ...
> $ bsdtar -xOf target/original-shadetest-0.0.0.jar test.txt | xxd
> : 61 a
> $ bsdtar -xOf target/shadetest-0.0.0.jar test.txt | xxd
> : 6100 a...
> {code}
> I've attached a basic {{pom.xml}} that triggers this. This doesn't occur in
> the previous version, 3.2.4.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MRELEASE-1077) Support for prepare specific profiles
[
https://issues.apache.org/jira/browse/MRELEASE-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516355#comment-17516355
]
Karl Heinz Marbaise commented on MRELEASE-1077:
---
During the {{prepare phase}} only the SCM/pom parts are changed and checked and
later commited. During the {{release:perform}} part the real artifacts etc. are
being generated (build) so to achieve your goal there are two options possible.
* You can use a profile during the {{perform}} (goal) which does already
exists:
[releaseProfile|https://maven.apache.org/maven-release/maven-release-plugin/perform-mojo.html#releaseProfiles]
which can be set to be activated during the release generation.
* You can also activate a profile via {{arguments}} property like:
{code:xml}
org.apache.maven.plugins
maven-release-plugin
-PactiveProfile
{code}
* A question is comming to my mind: Why not using filtering via
[maven-resources-plugin|https://maven.apache.org/plugins/maven-resources-plugin/]
to set the versions in some locations?
> Support for prepare specific profiles
> -
>
> Key: MRELEASE-1077
> URL: https://issues.apache.org/jira/browse/MRELEASE-1077
> Project: Maven Release Plugin
> Issue Type: New Feature
> Components: prepare
>Affects Versions: 3.0.0-M5
>Reporter: Niels Basjes
>Priority: Minor
>
> In my projects I like to have the latest released version of the software
> shown on the website (which is also in the source tree). I do this using the
> exec plugin which runs a script to write the project version in a few places.
> For this purpose I propose having the option to allow specifying one or more
> profiles that are activated during the prepare phase.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MPOM-305) Set minimum enforced Maven version to 3.2.5
[ https://issues.apache.org/jira/browse/MPOM-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MPOM-305: - Issue Type: Task (was: Dependency upgrade) > Set minimum enforced Maven version to 3.2.5 > --- > > Key: MPOM-305 > URL: https://issues.apache.org/jira/browse/MPOM-305 > Project: Maven POMs > Issue Type: Task > Components: asf >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: ASF-26 > > > Used plugins required Maven 3.2.5 > - maven-compiler-plugin from 3.9.0 > - maven-plugin-plugin from 3.6.4 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JXR-169) Use of deprecated velocity configuration keys
[
https://issues.apache.org/jira/browse/JXR-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516354#comment-17516354
]
Slawomir Jaranowski commented on JXR-169:
-
I confirm, can be observed during {{jxr-plugin}} executing.
I didn't investigate if should be fixed in {{jxr}} or in
{{doxia-site-renderer,}} both use {{velocity}} ... in different versions :-)
> Use of deprecated velocity configuration keys
> --
>
> Key: JXR-169
> URL: https://issues.apache.org/jira/browse/JXR-169
> Project: Maven JXR
> Issue Type: Improvement
> Components: maven2 jxr plugin
>Affects Versions: 3.2.0
>Reporter: Dave Wichers
>Priority: Minor
>
> When I run: mvn site, using my project's pom:
> [https://github.com/nahsra/antisamy/blob/main/pom.xml]
> I'm seeing the following warnings. I think this means these jxr-plugins are
> using old resource names. Unless I'm doing something wrong in my pom. But I
> can't find any references to these resources in my project, so I'm assuming
> its a problem in your project. Can you confirm this is an issue in maven-jxr
> and you can fix it? Or is it my fault?
> The velocity configuration key changes are described here:
> https://velocity.apache.org/engine/devel/configuration-property-changes-in-2.1.html
> [*INFO*] Generating "{*}Source Xref{*}" report *---*
> maven-jxr-plugin:3.2.0:jxr
> [*WARNING*] configuration key 'resource.loader' has been deprecated in favor
> of 'resource.loaders'
> [*WARNING*] configuration key 'classpath.resource.loader.class' has been
> deprecated in favor of 'resource.loader.classpath.class'
> [*WARNING*] configuration key 'velocimacro.library' has been deprecated in
> favor of 'velocimacro.library.path'
> [*INFO*] Generating "{*}Test Source Xref{*}" report *---*
> maven-jxr-plugin:3.2.0:test-jxr
> [*WARNING*] configuration key 'resource.loader' has been deprecated in favor
> of 'resource.loaders'
> [*WARNING*] configuration key 'classpath.resource.loader.class' has been
> deprecated in favor of 'resource.loader.classpath.class'
> [*WARNING*] configuration key 'velocimacro.library' has been deprecated in
> favor of 'velocimacro.library.path'
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (JXR-169) Use of deprecated velocity configuration keys
[
https://issues.apache.org/jira/browse/JXR-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Wichers updated JXR-169:
-
Description:
When I run: mvn site, using my project's pom:
[https://github.com/nahsra/antisamy/blob/main/pom.xml]
I'm seeing the following warnings. I think this means these jxr-plugins are
using old resource names. Unless I'm doing something wrong in my pom. But I
can't find any references to these resources in my project, so I'm assuming its
a problem in your project. Can you confirm this is an issue in maven-jxr and
you can fix it? Or is it my fault?
The velocity configuration key changes are described here:
https://velocity.apache.org/engine/devel/configuration-property-changes-in-2.1.html
[*INFO*] Generating "{*}Source Xref{*}" report *---*
maven-jxr-plugin:3.2.0:jxr
[*WARNING*] configuration key 'resource.loader' has been deprecated in favor of
'resource.loaders'
[*WARNING*] configuration key 'classpath.resource.loader.class' has been
deprecated in favor of 'resource.loader.classpath.class'
[*WARNING*] configuration key 'velocimacro.library' has been deprecated in
favor of 'velocimacro.library.path'
[*INFO*] Generating "{*}Test Source Xref{*}" report *---*
maven-jxr-plugin:3.2.0:test-jxr
[*WARNING*] configuration key 'resource.loader' has been deprecated in favor of
'resource.loaders'
[*WARNING*] configuration key 'classpath.resource.loader.class' has been
deprecated in favor of 'resource.loader.classpath.class'
[*WARNING*] configuration key 'velocimacro.library' has been deprecated in
favor of 'velocimacro.library.path'
was:
When I run: mvn site, using my project's pom:
https://github.com/nahsra/antisamy/blob/main/pom.xml
I'm seeing the following warnings. I think this means these jxr-plugins are
using old resource names. Unless I'm doing something wrong in my pom. But I
can't find any references to these resources in my project, so I'm assuming its
a problem in your project. Can you confirm this is an issue in maven-jxr and
you can fix it? Or is it my fault?
[*INFO*] Generating "{*}Source Xref{*}" report *---*
maven-jxr-plugin:3.2.0:jxr
[*WARNING*] configuration key 'resource.loader' has been deprecated in favor of
'resource.loaders'
[*WARNING*] configuration key 'classpath.resource.loader.class' has been
deprecated in favor of 'resource.loader.classpath.class'
[*WARNING*] configuration key 'velocimacro.library' has been deprecated in
favor of 'velocimacro.library.path'
[*INFO*] Generating "{*}Test Source Xref{*}" report *---*
maven-jxr-plugin:3.2.0:test-jxr
[*WARNING*] configuration key 'resource.loader' has been deprecated in favor of
'resource.loaders'
[*WARNING*] configuration key 'classpath.resource.loader.class' has been
deprecated in favor of 'resource.loader.classpath.class'
[*WARNING*] configuration key 'velocimacro.library' has been deprecated in
favor of 'velocimacro.library.path'
> Use of deprecated velocity configuration keys
> --
>
> Key: JXR-169
> URL: https://issues.apache.org/jira/browse/JXR-169
> Project: Maven JXR
> Issue Type: Improvement
> Components: maven2 jxr plugin
>Affects Versions: 3.2.0
>Reporter: Dave Wichers
>Priority: Minor
>
> When I run: mvn site, using my project's pom:
> [https://github.com/nahsra/antisamy/blob/main/pom.xml]
> I'm seeing the following warnings. I think this means these jxr-plugins are
> using old resource names. Unless I'm doing something wrong in my pom. But I
> can't find any references to these resources in my project, so I'm assuming
> its a problem in your project. Can you confirm this is an issue in maven-jxr
> and you can fix it? Or is it my fault?
> The velocity configuration key changes are described here:
> https://velocity.apache.org/engine/devel/configuration-property-changes-in-2.1.html
> [*INFO*] Generating "{*}Source Xref{*}" report *---*
> maven-jxr-plugin:3.2.0:jxr
> [*WARNING*] configuration key 'resource.loader' has been deprecated in favor
> of 'resource.loaders'
> [*WARNING*] configuration key 'classpath.resource.loader.class' has been
> deprecated in favor of 'resource.loader.classpath.class'
> [*WARNING*] configuration key 'velocimacro.library' has been deprecated in
> favor of 'velocimacro.library.path'
> [*INFO*] Generating "{*}Test Source Xref{*}" report *---*
> maven-jxr-plugin:3.2.0:test-jxr
> [*WARNING*] configuration key 'resource.loader' has been deprecated in favor
> of 'resource.loaders'
> [*WARNING*] configuration key 'classpath.resource.loader.class' has been
> deprecated in favor of 'resource.loader.classpath.class'
> [*WARNING*] configuration key 'velocimacro.library' has been deprecated in
> favor of 'velocimacro.library.path'
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (JXR-169) Use of deprecated velocity configuration keys
Dave Wichers created JXR-169:
Summary: Use of deprecated velocity configuration keys
Key: JXR-169
URL: https://issues.apache.org/jira/browse/JXR-169
Project: Maven JXR
Issue Type: Improvement
Components: maven2 jxr plugin
Affects Versions: 3.2.0
Reporter: Dave Wichers
When I run: mvn site, using my project's pom:
https://github.com/nahsra/antisamy/blob/main/pom.xml
I'm seeing the following warnings. I think this means these jxr-plugins are
using old resource names. Unless I'm doing something wrong in my pom. But I
can't find any references to these resources in my project, so I'm assuming its
a problem in your project. Can you confirm this is an issue in maven-jxr and
you can fix it? Or is it my fault?
[*INFO*] Generating "{*}Source Xref{*}" report *---*
maven-jxr-plugin:3.2.0:jxr
[*WARNING*] configuration key 'resource.loader' has been deprecated in favor of
'resource.loaders'
[*WARNING*] configuration key 'classpath.resource.loader.class' has been
deprecated in favor of 'resource.loader.classpath.class'
[*WARNING*] configuration key 'velocimacro.library' has been deprecated in
favor of 'velocimacro.library.path'
[*INFO*] Generating "{*}Test Source Xref{*}" report *---*
maven-jxr-plugin:3.2.0:test-jxr
[*WARNING*] configuration key 'resource.loader' has been deprecated in favor of
'resource.loaders'
[*WARNING*] configuration key 'classpath.resource.loader.class' has been
deprecated in favor of 'resource.loader.classpath.class'
[*WARNING*] configuration key 'velocimacro.library' has been deprecated in
favor of 'velocimacro.library.path'
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MSHADE-417) Nul bytes appended to small files by maven-shade-plugin
[
https://issues.apache.org/jira/browse/MSHADE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516344#comment-17516344
]
Romain Manni-Bucau commented on MSHADE-417:
---
[~hboutemy] , yes I don't have perms to do that (mentionned it a few times on
slack, guess it is a bad username - romain.manni-bucau is the right one?).
Not sure about your use case for null bytes, do you have some sample? Max
analyzis is right but also means we create a shade of nothing which sounds like
a project setup error.
> Nul bytes appended to small files by maven-shade-plugin
> ---
>
> Key: MSHADE-417
> URL: https://issues.apache.org/jira/browse/MSHADE-417
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Max Zerzouri
>Priority: Major
> Attachments: original-shadetest-0.0.0.jar, pom.xml,
> shadetest-0.0.0.jar, test.txt
>
>
> Version 3.3.0 of maven shade plugin seems to append "\x00" bytes to a file if
> it's less than 4 bytes:
> {code:sh}
> $ echo -n a > src/main/resources/test.txt
> $ mvn clean install
> ...
> $ bsdtar -xOf target/original-shadetest-0.0.0.jar test.txt | xxd
> : 61 a
> $ bsdtar -xOf target/shadetest-0.0.0.jar test.txt | xxd
> : 6100 a...
> {code}
> I've attached a basic {{pom.xml}} that triggers this. This doesn't occur in
> the previous version, 3.2.4.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MARTIFACT-24) add goal to check that plugins versions do not have known reproducibility issues
[ https://issues.apache.org/jira/browse/MARTIFACT-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516342#comment-17516342 ] Hudson commented on MARTIFACT-24: - Build succeeded in Jenkins: Maven » Maven TLP » maven-artifact-plugin » master #3 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-artifact-plugin/job/master/3/ > add goal to check that plugins versions do not have known reproducibility > issues > > > Key: MARTIFACT-24 > URL: https://issues.apache.org/jira/browse/MARTIFACT-24 > Project: Maven Artifact Plugin > Issue Type: New Feature > Components: artifact:buildinfo, artifact:compare >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.3.0 > > > for newbies wanting to make their build reproducible, having a first analysis > of what to fix in their pom.xml would ease a lot: we have a list of known > plugins with minimal versions -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2033) Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
[
https://issues.apache.org/jira/browse/SUREFIRE-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516340#comment-17516340
]
Robert James Oxspring commented on SUREFIRE-2033:
-
Of course my test does not have a `@RunWith` annotation: It's a JUnit 5 test.
It's a perfectly good JUnit 5 test that used to be run by Surefire 3.0.0-M1,
3.0.0-M2, 3.0.0-M3, and 3.0.0-M4. The `@RunWith` annotation was never necessary
before, as Surefire used to run the JUnit 5 test directly using the JUnit 5
Engine because Surefire, as is stil documented, preferred to use the JUnit 5
engine if present.
Surefire 3.0.0-M5 regresses because it newly special cases the
`junit-platform-runner` and so ignores the perfectly good test.
You keep trying to tell me how `junit-platform-runner` should be used, and that
I should delete it from my project. Again I must point out that this is simply
not an option: I do understand `junit-platform-runner` well already as my
project uses it as a compile time dependency which therefore must be present.
The tests of my project exclusively use JUnit 5 and so we have a
`junit-jupiter-engine` test dependency, which always used to be a perfectly
good configuration because Surefire would find multiple engines and pick the
best available - with JUnit 5 being preferred over all others. As of 3.0.0-M5,
`junit-platform-runner` is preferred over all others instead, and results in no
tests being run in the example and in my real project. In both the attached
example and my real project, this new behaviour is a clear regressive step.
For 3.0.0-M5 to actively change the priorities and actively optimise for users
who are transitioning from JUnit 4 to 5, at the cost of those that have already
completed the transition seems crazy to me.
> Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
> ---
>
> Key: SUREFIRE-2033
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2033
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Robert James Oxspring
>Priority: Major
> Attachments: example.zip
>
>
> 3.0.0-M5 misidentifies a clearly JUnit 5 configuration and attempts to run
> using JUnit 4.
> In particular the attached project only has JUnit 5 dependencies:
> {code:java}
>
>
> org.junit.jupiter
> junit-jupiter-engine
> 5.6.2
> test
>
>
> org.junit.platform
> junit-platform-runner
> 1.6.2
> test
>
> {code}
> and a JUnit 5 test:
> {code:java}
> package pkg;
> import org.junit.jupiter.api.Test;
> class JUnit5Test {
> @Test
> public void test() {
> }
> }{code}
> When the project is run with with older version (as far back as 2.22.0) the
> test is found and run, but 3.0.0-M5 fails to run any test:
> {code:java}
> % mvn test -Dsurefire.version=2.22.0 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.337 s
> [INFO] Finished at: 2022-03-03T09:42:27Z
> [INFO]
>
> {code}
>
> {code:java}
> % mvn test -Dsurefire.version=3.0.0-M1 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.708 s
> [INFO] Finished at: 2022-03-03T09:34:58Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M2 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.701 s
> [INFO] Finished at: 2022-03-03T09:36:26Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M3 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.612 s
> [INFO] Finished at:
[jira] [Closed] (MARTIFACT-24) add goal to check that plugins versions do not have known reproducibility issues
[ https://issues.apache.org/jira/browse/MARTIFACT-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MARTIFACT-24. -- Fix Version/s: 3.3.0 Assignee: Herve Boutemy Resolution: Fixed done in check-buildplan goal > add goal to check that plugins versions do not have known reproducibility > issues > > > Key: MARTIFACT-24 > URL: https://issues.apache.org/jira/browse/MARTIFACT-24 > Project: Maven Artifact Plugin > Issue Type: New Feature > Components: artifact:buildinfo, artifact:compare >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.3.0 > > > for newbies wanting to make their build reproducible, having a first analysis > of what to fix in their pom.xml would ease a lot: we have a list of known > plugins with minimal versions -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7445) to refactor some useless code
[ https://issues.apache.org/jira/browse/MNG-7445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516331#comment-17516331 ] Hudson commented on MNG-7445: - Build succeeded in Jenkins: Maven » Maven TLP » maven » PR-702 #2 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-702/2/ > to refactor some useless code > - > > Key: MNG-7445 > URL: https://issues.apache.org/jira/browse/MNG-7445 > Project: Maven > Issue Type: Improvement > Components: Core >Affects Versions: 3.8.5 > Environment: macos, linux ,windwos >Reporter: jackyHu >Assignee: Karl Heinz Marbaise >Priority: Trivial > Labels: refactor > Fix For: 3.8.x-candidate, 3.9.0, 4.0.0 > > Attachments: wenjian.jpg > > Original Estimate: 1h > Remaining Estimate: 1h > > the code at > maven-core/src/main/java/org/apache/maven/settings/DefaultMavenSettingsBuilder.java > and the return statement (at line 158 and 162)been writen twice ,but they > could be only write once. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7432) [REGRESSION] Dependencies from profile not picked up via -P
[ https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516329#comment-17516329 ] Tamás Cservenák commented on MNG-7432: -- Created UT as PR https://github.com/apache/maven/pull/706 Please reuse it, no need to retain author etc... merge at will. > [REGRESSION] Dependencies from profile not picked up via -P > > > Key: MNG-7432 > URL: https://issues.apache.org/jira/browse/MNG-7432 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Falko Modler >Priority: Critical > > The README of the following reproducer says it all: > https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation > Initially discussed here: > https://github.com/quarkusio/quarkus/pull/24285#issuecomment-1067368625 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] cstamas commented on pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
cstamas commented on pull request #695: URL: https://github.com/apache/maven/pull/695#issuecomment-1086661992 Created UT that IMHO should cover the issue https://github.com/apache/maven/pull/706 Please reuse it freely, no need to keep author etc (just lift it from there) -- 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] cstamas opened a new pull request #706: [MNG-7432] Proposed UT for maven-3.9.x and 3.8.x
cstamas opened a new pull request #706: URL: https://github.com/apache/maven/pull/706 This UT makes sure that DefaultMaven sets up proper type of WorkspaceReader in RepositorySystemSession. For example, this UT fails with current maven-3.8.x and maven-3.9.x branches. -- 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] (SUREFIRE-1975) JDK18 - The Security Manager is deprecated and will be removed in a future release
[
https://issues.apache.org/jira/browse/SUREFIRE-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1975:
---
Fix Version/s: 2.22.3
> JDK18 - The Security Manager is deprecated and will be removed in a future
> release
> --
>
> Key: SUREFIRE-1975
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1975
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
>
> We won't run the integration test \{{Surefire34SecurityManagerIT}} since of
> JDK 18.
> We won't support SecurityManager in JUnit3 Surefire Provider since of JDK 18.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1426) Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
[
https://issues.apache.org/jira/browse/SUREFIRE-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1426:
---
Fix Version/s: 2.22.3
> Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
> ---
>
> Key: SUREFIRE-1426
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1426
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Reporter: Dan Berindei
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
> Attachments: surefire-1426-test.tar.gz
>
>
> We have a reactor with many modules, and also a few random test failures. We
> want to run the tests of all the modules even if a test failed in the core
> module, so we use {{mvn -Dmaven.test.failure.ignore=true}}. {{mvn
> --fail-at-end}} only builds the modules that do not depend on the module with
> a failed test.
> The problem is that fork crashes like this one are written to the surefire
> reports, so Jenkins ignores them:
> {noformat}
> org.apache.maven.surefire.booter.SurefireBooterForkException: There was an
> error in the forked process
> Unable to load category: stress
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:665)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356){noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1913) system properties should be restored after the in-process tests have been executed
[ https://issues.apache.org/jira/browse/SUREFIRE-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1913: --- Fix Version/s: 2.22.3 > system properties should be restored after the in-process tests have been > executed > -- > > Key: SUREFIRE-1913 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1913 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 2.22.3, 3.0.0-M6 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1912) user.dir should not be set lazily within the surefire fork JVM
[ https://issues.apache.org/jira/browse/SUREFIRE-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1912: --- Fix Version/s: 2.22.3 > user.dir should not be set lazily within the surefire fork JVM > -- > > Key: SUREFIRE-1912 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1912 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin, process > forking >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 2.22.3, 3.0.0-M6 > > > user.dir is set and overridden by ForkedBooter. > It is already done by setting CWD in the native process. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1908) Wish by Stackoverflow - Documented strategy with parallel Java packages
[ https://issues.apache.org/jira/browse/SUREFIRE-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1908: --- Fix Version/s: 2.22.3 > Wish by Stackoverflow - Documented strategy with parallel Java packages > --- > > Key: SUREFIRE-1908 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1908 > Project: Maven Surefire > Issue Type: Wish > Components: documentation, Junit 4.7+ (parallel) support, Maven > Failsafe Plugin, Maven Surefire Plugin >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 2.22.3, 3.0.0-M6 > > > https://stackoverflow.com/questions/66430769/run-suites-in-parallel-using-maven-failsafe/67113491#67113491 > This is a strategy which allows the users to run several packages in > parallel. The trick is based on Suite of JUnit4. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1865) ChecksumCalculator getSha1 does not compute checksums correctly
[
https://issues.apache.org/jira/browse/SUREFIRE-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1865:
---
Fix Version/s: 2.22.3
> ChecksumCalculator getSha1 does not compute checksums correctly
> ---
>
> Key: SUREFIRE-1865
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1865
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Gian Merlino
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
>
> ChecksumCalculator does the following in getSha1:
> {code}
> md.update( configValue.getBytes( ISO_8859_1 ), 0, configValue.length() );
> {code}
> This isn't using the right length, because {{configValue.length()}} is a
> length in characters, not bytes. This will lead to the wrong length being
> used for any strings that contain characters that aren't encoded in a single
> byte.
> Additionally, I believe that this class can be used to compute checksums on
> strings that fall outside the ISO_8859_1 character set, so UTF_8 would be a
> better choice.
> I ran into this when defining a test property that contained Cyrillic
> characters and emojis.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1851) NPE in SmartStackTraceParser causes false positive test results
[ https://issues.apache.org/jira/browse/SUREFIRE-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1851: --- Fix Version/s: 2.22.3 > NPE in SmartStackTraceParser causes false positive test results > --- > > Key: SUREFIRE-1851 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1851 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support, JUnit 5.x support, Maven Surefire > Plugin >Reporter: Adam Jones >Assignee: Tibor Digana >Priority: Major > Fix For: 2.22.3, 3.0.0-M6 > > Attachments: junit4.11andsurefire2.22.2.txt, > junit5.7.0andsurefire3.0.0M5.txt > > > If throwing an exception within a test where the stack trace is null, a core > utility (SmartStackTraceParser in comon-java5) will throw an NPE. This will > cause the test suite to fail. > What is especially scary about this is that it will not log that the test has > failed, and in some configurations will even declare the build is successful > and all tests passed. Additionally, the surefire report plugin will declare > all tests passed too. > An exception with a null stacktrace sounds odd, but is easy to do by mocking > an exception with frameworks like Mockito. While people probably shouldn't be > mocking exceptions, it definitely [can and does > happen|https://github.com/search?q=mock%28DataIntegrityViolationException.class%29+language%3AJava+fork%3Afalse=code]. > Not sure what versions exactly are affected. But it's affected the > `common-java5` package since 2012. At least both JUnit 4 and 5 are affected, > with surefire 2.22.1 or 3.0.0-M5. Logs attached. > Can be reproduced with [https://github.com/domdomegg/surefire-1851-demo] > I have a patch ready that I believe fixes this: > https://github.com/apache/maven-surefire/pull/320 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1842) Surefire - NPE at end of successful test run
[ https://issues.apache.org/jira/browse/SUREFIRE-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1842: --- Fix Version/s: 2.22.3 > Surefire - NPE at end of successful test run > > > Key: SUREFIRE-1842 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1842 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.19.1, 2.21.0, 2.22.1, 3.0.0-M2, 3.0.0-M1, 3.0.0-M3, > 3.0.0-M4 >Reporter: Jack Leech >Assignee: Tibor Digana >Priority: Major > Fix For: 2.22.3, 3.0.0-M6 > > Attachments: stack_trace.txt, test_profile.xml > > > While using surefire to run a mock test pack all tests are passed, followed > by an exception in the surefire plugin (NPE) at the end which causes the run > to be marked as a failure. > I've tried various surefire versions of surefire and other testing libraries > involved. > I have attached a stack trace of the exception in question and a copy of the > test profile xml. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1659) Log4j logger in TestExecutionListener corrupts Surefire's STDOUT.
[
https://issues.apache.org/jira/browse/SUREFIRE-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1659:
---
Fix Version/s: 2.22.3
> Log4j logger in TestExecutionListener corrupts Surefire's STDOUT.
> -
>
> Key: SUREFIRE-1659
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1659
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M3
>Reporter: Stig Rohde Døssing
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
> Attachments: src.zip, surefire-stdout-corrupt.zip
>
>
> I have a project that registers a JUnit 5 TestExecutionListener. The
> TestExecutionListener contains an SLF4j Logger, using Log4j2 as the
> underlying library. There is a log4j2.xml on the classpath, logging to
> console, and Surefire is set up to redirect output.
> Running the tests gives the following result.
> {quote}
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file ...
> {quote}
> I've attached a minimal reproduction.
> Doing either of the following eliminates the error:
> * Not having the log4j2.xml on the classpath
> * Not having the Logger in the TestExecutionListener
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1825) Unable to zip the Cucumber TXT report file on Linux and MacOS
[
https://issues.apache.org/jira/browse/SUREFIRE-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1825:
---
Fix Version/s: 2.22.3
> Unable to zip the Cucumber TXT report file on Linux and MacOS
> -
>
> Key: SUREFIRE-1825
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1825
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
> Environment: Nix systems
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
>
> We have the GitHub Workflow (CI system) and we are not able to upload the
> artifacts because the TXT file contains illegal characters.
> {noformat}
> Run actions/upload-artifact@v2-preview
> With the provided path, there will be 20483 files uploaded
> ##[error]Artifact path is not valid:
> /JUnit47WithCucumberIT_testWithParallelClasses/target/surefire-reports/Scenario:
> Do a failing test.txt. Contains character: ":". Invalid characters include:
> ",:,<,>,|,*,?.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1844) Trademarks / privacy policy footer displays broken
[ https://issues.apache.org/jira/browse/SUREFIRE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1844: --- Fix Version/s: 2.22.3 > Trademarks / privacy policy footer displays broken > -- > > Key: SUREFIRE-1844 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1844 > Project: Maven Surefire > Issue Type: Bug > Components: documentation >Reporter: Philippe Cloutier >Assignee: Enrico Olivelli >Priority: Trivial > Fix For: 2.22.3, 3.0.0-M6 > > Attachments: image-2020-09-22-17-29-40-357.png > > Original Estimate: 1h > Remaining Estimate: 1h > > The footer which is at the end of Surefire's documentation pages, such as > [this > one|https://maven.apache.org/surefire/maven-surefire-plugin/index.html], have > a broken display (at least in Firefox 81 and Google Chrome 85). The > horizontal alignment is incorrect, causing the sentence to start outside the > visible area and its end to overlap with the "Privacy policy" link, as can be > seen in the screenshot below: > !image-2020-09-22-17-29-40-357.png|thumbnail! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1844) Trademarks / privacy policy footer displays broken
[ https://issues.apache.org/jira/browse/SUREFIRE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1844: --- Fix Version/s: (was: 2.22.3) > Trademarks / privacy policy footer displays broken > -- > > Key: SUREFIRE-1844 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1844 > Project: Maven Surefire > Issue Type: Bug > Components: documentation >Reporter: Philippe Cloutier >Assignee: Enrico Olivelli >Priority: Trivial > Fix For: 3.0.0-M6 > > Attachments: image-2020-09-22-17-29-40-357.png > > Original Estimate: 1h > Remaining Estimate: 1h > > The footer which is at the end of Surefire's documentation pages, such as > [this > one|https://maven.apache.org/surefire/maven-surefire-plugin/index.html], have > a broken display (at least in Firefox 81 and Google Chrome 85). The > horizontal alignment is incorrect, causing the sentence to start outside the > visible area and its end to overlap with the "Privacy policy" link, as can be > seen in the screenshot below: > !image-2020-09-22-17-29-40-357.png|thumbnail! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1844) Trademarks / privacy policy footer displays broken
[ https://issues.apache.org/jira/browse/SUREFIRE-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1844: --- Fix Version/s: 2.22.3 > Trademarks / privacy policy footer displays broken > -- > > Key: SUREFIRE-1844 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1844 > Project: Maven Surefire > Issue Type: Bug > Components: documentation >Reporter: Philippe Cloutier >Assignee: Enrico Olivelli >Priority: Trivial > Fix For: 2.22.3, 3.0.0-M6 > > Attachments: image-2020-09-22-17-29-40-357.png > > Original Estimate: 1h > Remaining Estimate: 1h > > The footer which is at the end of Surefire's documentation pages, such as > [this > one|https://maven.apache.org/surefire/maven-surefire-plugin/index.html], have > a broken display (at least in Firefox 81 and Google Chrome 85). The > horizontal alignment is incorrect, causing the sentence to start outside the > visible area and its end to overlap with the "Privacy policy" link, as can be > seen in the screenshot below: > !image-2020-09-22-17-29-40-357.png|thumbnail! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1924) Upgrade plexus-java to Version 1.0.7
[ https://issues.apache.org/jira/browse/SUREFIRE-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1924: --- Fix Version/s: 2.22.3 > Upgrade plexus-java to Version 1.0.7 > > > Key: SUREFIRE-1924 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1924 > Project: Maven Surefire > Issue Type: Dependency upgrade > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 2.22.3, 3.0.0-M6 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1967) High resource consumption when executing TestNG tests in parallel mode with a suite file
[ https://issues.apache.org/jira/browse/SUREFIRE-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1967: --- Fix Version/s: 2.22.3 > High resource consumption when executing TestNG tests in parallel mode with a > suite file > > > Key: SUREFIRE-1967 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1967 > Project: Maven Surefire > Issue Type: Bug >Reporter: Piotr Findeisen >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 2.22.3, 3.0.0-M6 > > > When executing TestNG tests with a suite file, TestNG invokes `@AfterClass` > allowing test to free resources, before moving to next test class. > With parallel test execution, at most number-of-thread test classes get > initialized at a time. > When TestNG is invoked from Surefire without a suite file, many test > instances get initialized in sequence, without being torn down, leading to > higher resource consumption. > For resource hungry tests, like in Trino project ( > https://github.com/trinodb/trino/ ) this makes a big difference in resource > consumption. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1890) Not compatible with TestNG 7.4.0
[
https://issues.apache.org/jira/browse/SUREFIRE-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1890:
---
Fix Version/s: 2.22.3
> Not compatible with TestNG 7.4.0
>
>
> Key: SUREFIRE-1890
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1890
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 3.0.0-M5
>Reporter: Joe Barnett
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
>
> TestNG 7.4.0 removed the deprecated method
> {{org.testng.xml.XmlSuite.setParallel(java.lang.String)}}. Trying to run
> tests with parallelism set results in:
> {code:java}
> java.lang.NoSuchMethodError: 'void
> org.testng.xml.XmlSuite.setParallel(java.lang.String)'
> at
> org.apache.maven.surefire.testng.conf.TestNGMapConfigurator.configure(TestNGMapConfigurator.java:71)
> at
> org.apache.maven.surefire.testng.conf.TestNG510Configurator.configure(TestNG510Configurator.java:40)
> at
> org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:111)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeSingleClass(TestNGDirectoryTestSuite.java:112)
> at
> org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:99)
> at
> org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:145)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428)
> at
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
> at
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1856) Updated documentation for the TestNG Provider - may not disable JUnit in suiteXmlFiles
[ https://issues.apache.org/jira/browse/SUREFIRE-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1856: --- Fix Version/s: 2.22.3 > Updated documentation for the TestNG Provider - may not disable JUnit in > suiteXmlFiles > -- > > Key: SUREFIRE-1856 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1856 > Project: Maven Surefire > Issue Type: Improvement > Components: documentation, Maven Failsafe Plugin, Maven Surefire > Plugin, TestNG support >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 2.22.3, 3.0.0-M6 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (SUREFIRE-1398) TestNG test fails when both JUnitCore provider and TestNG provider are on classpath
[
https://issues.apache.org/jira/browse/SUREFIRE-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1398:
---
Fix Version/s: 2.22.3
> TestNG test fails when both JUnitCore provider and TestNG provider are on
> classpath
> ---
>
> Key: SUREFIRE-1398
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1398
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, TestNG support
>Affects Versions: 2.20
>Reporter: Matous Jobanek
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
>
> When both JUnitCore and TestNG providers are on classpath:
> {code:xml}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.20
>
>
> org.apache.maven.surefire
> surefire-junit47
> 2.20
>
>
> org.apache.maven.surefire
> surefire-testng
> 2.20
>
>
>
> {code}
> then the TestNG execution fails with a message:
> {noformat}
> Configuring TestNG with: TestNG60Configurator
> Cannot use a threadCount parameter less than 1; 1 > 0
> Usage: [options] The XML suite files to run
> Options:
> -configfailurepolicy
>Configuration failure policy (skip or continue)
> -d
>Output directory
> -dataproviderthreadcount
>Number of threads to use when running data providers
> -excludegroups
>Comma-separated list of group names to exclude
> -groups
>Comma-separated list of group names to be run
> -junit
>JUnit mode
>Default: false
> -listener
>List of .class files or list of class names implementing ITestListener
> or
>ISuiteListener
> -methods
>Comma separated of test methods
>Default: []
> -methodselectors
>List of .class files or list of class names implementing
> IMethodSelector
> -mixed
>Mixed mode - autodetect the type of current test and run it with
>appropriate runner
>Default: false
> -objectfactory
>List of .class files or list of class names implementing
>ITestRunnerFactory
> -parallel
>Parallel mode (methods, tests or classes)
>Possible Values: [tests, methods, classes, instances, none, true,
> false]
> -port
>The port
> -reporter
>Extended configuration for custom report listener
> -suitename
>Default name of test suite, if not specified in suite definition file
> or
>source code
> -suitethreadpoolsize
>Size of the thread pool to use to run suites
>Default: 1
> -testclass
>The list of test classes
> -testjar
>A jar file containing the tests
> -testname
>Default name of test, if not specified in suitedefinition file or
> source
>code
> -testnames
>The list of test names to run
> -testrunfactory, -testRunFactory
>The factory used to create tests
> -threadcount
>Number of threads to use when running tests in parallel
> -usedefaultlisteners
>Whether to use the default listeners
>Default: true
> -log, -verbose
>Level of verbosity
> -xmlpathinjar
>The full path to the xml file inside the jar file (only valid if
> -testjar
>was specified)
>Default: testng.xml
> {noformat}
> The same behavior occurs when instead of these two providers I use my own
> dynamic provider and delegate the execution to the TestNG provider.
> The cause of the behavior is a combination of the method
> [convertJunitCoreParameters()|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L1289]
> and the TestNG provider.
> The method is called for
> [JunitCoreProvider|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2696]
> and sets the thread count to the current value (no matter if it is set or
> not). In case that it is not set, then the value is 0, which causes the
> before mentioned failure when {{TestNGProvider}} is being executed.
> The same in case of
> [DynamicProvider|https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2745]
> In the description of the parameter
> [threadCount|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#threadCount],
>
[jira] [Commented] (MNG-7445) to refactor some useless code
[ https://issues.apache.org/jira/browse/MNG-7445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516323#comment-17516323 ] Hudson commented on MNG-7445: - Build unstable in Jenkins: Maven » Maven TLP » maven » PR-394 #11 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/PR-394/11/ > to refactor some useless code > - > > Key: MNG-7445 > URL: https://issues.apache.org/jira/browse/MNG-7445 > Project: Maven > Issue Type: Improvement > Components: Core >Affects Versions: 3.8.5 > Environment: macos, linux ,windwos >Reporter: jackyHu >Assignee: Karl Heinz Marbaise >Priority: Trivial > Labels: refactor > Fix For: 3.8.x-candidate, 3.9.0, 4.0.0 > > Attachments: wenjian.jpg > > Original Estimate: 1h > Remaining Estimate: 1h > > the code at > maven-core/src/main/java/org/apache/maven/settings/DefaultMavenSettingsBuilder.java > and the return statement (at line 158 and 162)been writen twice ,but they > could be only write once. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MPOM-303) Rename property maven.plugin.tools.version to mavenPluginToolsVersion
[
https://issues.apache.org/jira/browse/MPOM-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MPOM-303:
-
Fix Version/s: (was: ASF-26)
> Rename property maven.plugin.tools.version to mavenPluginToolsVersion
> -
>
> Key: MPOM-303
> URL: https://issues.apache.org/jira/browse/MPOM-303
> Project: Maven POMs
> Issue Type: Task
> Components: asf
>Affects Versions: ASF-25
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> {{maven.plugin.tools.version}} was introduced in ASF parent 25 on 2022-02-20
> (one week ago)
> https://github.com/apache/maven-apache-parent/commit/5a878dcdc00439cf03d383096c62e9003b503bfe
> having a property starting with {{maven.}} is not a good practice, because
> this prefix is used by Maven itself:
> https://maven.apache.org/ref/3.8.5/maven-model-builder/#model-interpolation
> and {{plugin.tools}} should be more {{plugin-tools}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2033) Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
[
https://issues.apache.org/jira/browse/SUREFIRE-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516316#comment-17516316
]
Tibor Digana commented on SUREFIRE-2033:
[~roxspring]
You example attached in {{example.zip}} does not contain the annotation
{code:java}
@RunWith
{code}
So there is no adapter from JUnit4 Runner to Junit5 tests and nothing to run of
course.
You example would execute all junit4 unit tests if you wrote them and it would
additionally tun junit5 tests if you used the adapter.
Specifying two surefire providers, i.e. for junit4 and platform, in plugin
dependencies would not make sense with {{junit-platform-runner}} either. So,
since you use {{junit-platform-runner}}, you should remember that still junit4
provider is activated but the you have to use @ RunWith and all the staff
around in order to adapt junit4 runner/provider to junit5 tests. This is the
purpose of {{junit-platform-runner}} in my understaning and it is used for
migration from junit4 to junit5, but final is final after all the classes are
migrated and then {{junit-platform-runner}} has to be deleted. This is I think
the main business purpose of {{junit-platform-runner}}.
> Regression: 3.0.0-M5 misidentifies JUnit 5 configuration as JUnit 4
> ---
>
> Key: SUREFIRE-2033
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2033
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Robert James Oxspring
>Priority: Major
> Attachments: example.zip
>
>
> 3.0.0-M5 misidentifies a clearly JUnit 5 configuration and attempts to run
> using JUnit 4.
> In particular the attached project only has JUnit 5 dependencies:
> {code:java}
>
>
> org.junit.jupiter
> junit-jupiter-engine
> 5.6.2
> test
>
>
> org.junit.platform
> junit-platform-runner
> 1.6.2
> test
>
> {code}
> and a JUnit 5 test:
> {code:java}
> package pkg;
> import org.junit.jupiter.api.Test;
> class JUnit5Test {
> @Test
> public void test() {
> }
> }{code}
> When the project is run with with older version (as far back as 2.22.0) the
> test is found and run, but 3.0.0-M5 fails to run any test:
> {code:java}
> % mvn test -Dsurefire.version=2.22.0 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.337 s
> [INFO] Finished at: 2022-03-03T09:42:27Z
> [INFO]
>
> {code}
>
> {code:java}
> % mvn test -Dsurefire.version=3.0.0-M1 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.708 s
> [INFO] Finished at: 2022-03-03T09:34:58Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M2 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.701 s
> [INFO] Finished at: 2022-03-03T09:36:26Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M3 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.612 s
> [INFO] Finished at: 2022-03-03T09:37:02Z
> [INFO]
>
> % mvn test -Dsurefire.version=3.0.0-M4 | tail
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.619 s
> [INFO] Finished at: 2022-03-03T09:37:37Z
> [INFO]
>
> % mvn
[GitHub] [maven] laeubi commented on a change in pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
laeubi commented on a change in pull request #695:
URL: https://github.com/apache/maven/pull/695#discussion_r841079766
##
File path:
maven-core/src/main/java/org/apache/maven/internal/aether/MavenChainedWorkspaceReader.java
##
@@ -0,0 +1,106 @@
+package org.apache.maven.internal.aether;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.File;
+import java.util.Collection;
+import java.util.List;
+
+import org.apache.maven.model.Model;
+import org.apache.maven.repository.internal.MavenWorkspaceReader;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.repository.WorkspaceReader;
+import org.eclipse.aether.repository.WorkspaceRepository;
+import org.eclipse.aether.util.repository.ChainedWorkspaceReader;
+
+/**
+ * A maven workspace reader that delegates to a chain of other readers,
effectively aggregating their contents.
+ */
+public final class MavenChainedWorkspaceReader
+implements MavenWorkspaceReader
+{
+
+private ChainedWorkspaceReader delegate;
+
+private WorkspaceReader[] readers;
+
+/**
+ * Creates a new workspace reader by chaining the specified readers.
+ *
+ * @param readers The readers to chain must not be {@code null}.
+ */
+private MavenChainedWorkspaceReader( WorkspaceReader... readers )
+{
+this.delegate = new ChainedWorkspaceReader( readers );
+this.readers = readers;
+}
+
+@Override
+public Model findModel( Artifact artifact )
+{
+for ( WorkspaceReader workspaceReader : readers )
+{
+if ( workspaceReader instanceof MavenWorkspaceReader )
+{
+Model model = ( (MavenWorkspaceReader) workspaceReader
).findModel( artifact );
+if ( model != null )
+{
+return model;
+}
+}
+}
+return null;
+}
+
+@Override
+public WorkspaceRepository getRepository()
+{
+return delegate.getRepository();
+}
+
+@Override
+public File findArtifact( Artifact artifact )
+{
+return delegate.findArtifact( artifact );
+}
+
+@Override
+public List findVersions( Artifact artifact )
+{
+return delegate.findVersions( artifact );
+}
+
+/**
+ * chains a collection of {@link WorkspaceReader}s
+ * @param workspaceReaderCollection the collection of readers, might be
empty but never null
+ * @return if the collection contains only one item returns the single
item, otherwise creates a new
+ * {@link MavenChainedWorkspaceReader} chaining all readers in the
order of the given collection.
+ */
+public static WorkspaceReader of( Collection
workspaceReaderCollection )
+{
+WorkspaceReader[] readers = workspaceReaderCollection.toArray( new
WorkspaceReader[0] );
+if ( readers.length == 1 )
Review comment:
Yes, I just used the "toArray" as we accept a collection and then
getting the first element from collection requires to iterate over the
collection, but if size is larger requires an toArray as well... in the end it
dosn't make much a difference given that this only happens once per maven
invocation.
--
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] cstamas commented on a change in pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
cstamas commented on a change in pull request #695:
URL: https://github.com/apache/maven/pull/695#discussion_r841079559
##
File path:
maven-core/src/main/java/org/apache/maven/internal/aether/MavenChainedWorkspaceReader.java
##
@@ -0,0 +1,106 @@
+package org.apache.maven.internal.aether;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.File;
+import java.util.Collection;
+import java.util.List;
+
+import org.apache.maven.model.Model;
+import org.apache.maven.repository.internal.MavenWorkspaceReader;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.repository.WorkspaceReader;
+import org.eclipse.aether.repository.WorkspaceRepository;
+import org.eclipse.aether.util.repository.ChainedWorkspaceReader;
+
+/**
+ * A maven workspace reader that delegates to a chain of other readers,
effectively aggregating their contents.
+ */
+public final class MavenChainedWorkspaceReader
+implements MavenWorkspaceReader
+{
+
+private ChainedWorkspaceReader delegate;
+
+private WorkspaceReader[] readers;
+
+/**
+ * Creates a new workspace reader by chaining the specified readers.
+ *
+ * @param readers The readers to chain must not be {@code null}.
+ */
+private MavenChainedWorkspaceReader( WorkspaceReader... readers )
+{
+this.delegate = new ChainedWorkspaceReader( readers );
+this.readers = readers;
+}
+
+@Override
+public Model findModel( Artifact artifact )
+{
+for ( WorkspaceReader workspaceReader : readers )
+{
+if ( workspaceReader instanceof MavenWorkspaceReader )
+{
+Model model = ( (MavenWorkspaceReader) workspaceReader
).findModel( artifact );
+if ( model != null )
+{
+return model;
+}
+}
+}
+return null;
+}
+
+@Override
+public WorkspaceRepository getRepository()
+{
+return delegate.getRepository();
+}
+
+@Override
+public File findArtifact( Artifact artifact )
+{
+return delegate.findArtifact( artifact );
+}
+
+@Override
+public List findVersions( Artifact artifact )
+{
+return delegate.findVersions( artifact );
+}
+
+/**
+ * chains a collection of {@link WorkspaceReader}s
+ * @param workspaceReaderCollection the collection of readers, might be
empty but never null
+ * @return if the collection contains only one item returns the single
item, otherwise creates a new
+ * {@link MavenChainedWorkspaceReader} chaining all readers in the
order of the given collection.
+ */
+public static WorkspaceReader of( Collection
workspaceReaderCollection )
+{
+WorkspaceReader[] readers = workspaceReaderCollection.toArray( new
WorkspaceReader[0] );
+if ( readers.length == 1 )
Review comment:
~~Still, the check could happen then on collection, not after conversion
to array, no?~~ nvm, am fine with it as it is
--
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-7432) [REGRESSION] Dependencies from profile not picked up via -P
[ https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516312#comment-17516312 ] Christoph Läubrich commented on MNG-7432: - [~cstamas] many thanks for the detailed analysis, even though I don't fully understand all details, what I'm wondering is, do you think we should use the reproducer (even though it has issues?) or do you think we can add a unit-test (where?) for this and drop the reproducer? Maybe you can help her so we get the fix in ASAP? > [REGRESSION] Dependencies from profile not picked up via -P > > > Key: MNG-7432 > URL: https://issues.apache.org/jira/browse/MNG-7432 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.5 >Reporter: Falko Modler >Priority: Critical > > The README of the following reproducer says it all: > https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation > Initially discussed here: > https://github.com/quarkusio/quarkus/pull/24285#issuecomment-1067368625 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] cstamas commented on a change in pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
cstamas commented on a change in pull request #695:
URL: https://github.com/apache/maven/pull/695#discussion_r841079559
##
File path:
maven-core/src/main/java/org/apache/maven/internal/aether/MavenChainedWorkspaceReader.java
##
@@ -0,0 +1,106 @@
+package org.apache.maven.internal.aether;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.File;
+import java.util.Collection;
+import java.util.List;
+
+import org.apache.maven.model.Model;
+import org.apache.maven.repository.internal.MavenWorkspaceReader;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.repository.WorkspaceReader;
+import org.eclipse.aether.repository.WorkspaceRepository;
+import org.eclipse.aether.util.repository.ChainedWorkspaceReader;
+
+/**
+ * A maven workspace reader that delegates to a chain of other readers,
effectively aggregating their contents.
+ */
+public final class MavenChainedWorkspaceReader
+implements MavenWorkspaceReader
+{
+
+private ChainedWorkspaceReader delegate;
+
+private WorkspaceReader[] readers;
+
+/**
+ * Creates a new workspace reader by chaining the specified readers.
+ *
+ * @param readers The readers to chain must not be {@code null}.
+ */
+private MavenChainedWorkspaceReader( WorkspaceReader... readers )
+{
+this.delegate = new ChainedWorkspaceReader( readers );
+this.readers = readers;
+}
+
+@Override
+public Model findModel( Artifact artifact )
+{
+for ( WorkspaceReader workspaceReader : readers )
+{
+if ( workspaceReader instanceof MavenWorkspaceReader )
+{
+Model model = ( (MavenWorkspaceReader) workspaceReader
).findModel( artifact );
+if ( model != null )
+{
+return model;
+}
+}
+}
+return null;
+}
+
+@Override
+public WorkspaceRepository getRepository()
+{
+return delegate.getRepository();
+}
+
+@Override
+public File findArtifact( Artifact artifact )
+{
+return delegate.findArtifact( artifact );
+}
+
+@Override
+public List findVersions( Artifact artifact )
+{
+return delegate.findVersions( artifact );
+}
+
+/**
+ * chains a collection of {@link WorkspaceReader}s
+ * @param workspaceReaderCollection the collection of readers, might be
empty but never null
+ * @return if the collection contains only one item returns the single
item, otherwise creates a new
+ * {@link MavenChainedWorkspaceReader} chaining all readers in the
order of the given collection.
+ */
+public static WorkspaceReader of( Collection
workspaceReaderCollection )
+{
+WorkspaceReader[] readers = workspaceReaderCollection.toArray( new
WorkspaceReader[0] );
+if ( readers.length == 1 )
Review comment:
Still, the check could happen then on collection, not after conversion,
no?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Comment Edited] (MNG-7432) [REGRESSION] Dependencies from profile not picked up via -P
[
https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516300#comment-17516300
]
Tamás Cservenák edited comment on MNG-7432 at 4/2/22 1:54 PM:
--
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps declared in profiles are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader (resolver specific) does
not implement MavenWorkspaceReader (maven specific) while newly added
MavenChainedWorkspaceReader does -> SOLVES the issue, as resolver will "come
back" to reactor workspace reader and get the model already built with profile
applied due CLI`-PextraDeps`, instead to build it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected session (as it has proper reactor WSR injected into session), The
_same code snippet_ will NEVER work if runs "standalone", outside of Maven
scope!
* The reproducer clearly violates MNG-1388: what
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies goal does
IMHO VIOLATES MNG-1388 in a way, that it resolves the current project (as a
dependency!) and expects to have profile applied.
* What reproducer
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies IMHO
SHOULD DO instead, is to utilize already built model of module (already
injected as {{MavenProject project}}) and resolve it's dependencies
({{project.getDependencies()}}) as dependencies instead, In that case, the
transitive hull is guaranteed to be equivalent to what Maven resolved. BUT,
modified this way the "reproducer" would be not reproducing anymore...
Summary:
* fix possible w/ simplification (disregard length, just always wrap WSR into
MavenChainedWorkspaceReader) should be applied IMHO
* reproducer does reproduce as expected, but IMHO it does "wrong thing" to
start with. Am afraid if we put this into Maven ITs we will put into concrete
this wrong behaviour.
* test for the fix is IMHO just an assertion that WHEN resolver resolves within
Maven scope, this is true:
{{org.eclipse.aether.RepositorySystemSession#getWorkspaceReader insteanceof
MavenWorkspaceReader}} (and NEVER "raw" resolver specific WorkspaceReader).
Notes:
* as related MNG-1388 issue documents, the actual BUG is that non-{{-P}}
activators (property, file, etc) DOES KICK IN while resolving downstream
transitive dependencies, WHILE THEY SHOULD NOT, as "profile" is defined only in
realm of reactor, but NOT in the realm of downstream dependencies. These stem
from environment (system property set, file presence, etc) hence propagate,
while {{-P}} activator is explicitly given on CLI only, and does not propagate,
as expected.
was (Author: cstamas):
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps declared in profiles are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader (resolver specific) does
not implement MavenWorkspaceReader (maven specific) while newly added
MavenChainedWorkspaceReader does -> SOLVES the issue, as resolver will "come
back" to reactor workspace reader and get the model already built with profile
applied due CLI`-PextraDeps`, instead to build it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
[jira] [Comment Edited] (MNG-7432) [REGRESSION] Dependencies from profile not picked up via -P
[
https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516300#comment-17516300
]
Tamás Cservenák edited comment on MNG-7432 at 4/2/22 1:53 PM:
--
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps declared in profiles are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader (resolver specific) does
not implement MavenWorkspaceReader (maven specific) while newly added
MavenChainedWorkspaceReader does -> SOLVES the issue, as resolver will "come
back" to reactor workspace reader and get the model already built with profile
applied due CLI`-PextraDeps`, instead to build it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected session (as it has proper reactor WSR injected into session), The
_same code snippet_ will NEVER work if runs "standalone", outside of Maven
scope!
* The reproducer clearly violates MNG-1388: what
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies goal does
IMHO VIOLATES MNG-1388 in a way, that it resolves the current project (as a
dependency!) and expects to have profile applied.
* What reproducer
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies IMHO
SHOULD DO instead, is to utilize already built model of module (already
injected as {{MavenProject project}}) and resolve it's dependencies
({{project.getDependencies()}}) as dependencies instead, In that case, the
transitive hull is guaranteed to be equivalent to what Maven resolved.
Summary:
* fix possible w/ simplification (disregard length, just always wrap WSR into
MavenChainedWorkspaceReader) should be applied IMHO
* reproducer does reproduce as expected, but IMHO it does "wrong thing" to
start with. Am afraid if we put this into Maven ITs we will put into concrete
this wrong behaviour.
* test for the fix is IMHO just an assertion that WHEN resolver resolves within
Maven scope, this is true:
{{org.eclipse.aether.RepositorySystemSession#getWorkspaceReader insteanceof
MavenWorkspaceReader}} (and NEVER "raw" resolver specific WorkspaceReader).
Notes:
* as related MNG-1388 issue documents, the actual BUG is that non-{{-P}}
activators (property, file, etc) DOES KICK IN while resolving downstream
transitive dependencies, WHILE THEY SHOULD NOT, as "profile" is defined only in
realm of reactor, but NOT in the realm of downstream dependencies. These stem
from environment (system property set, file presence, etc) hence propagate,
while {{-P}} activator is explicitly given on CLI only, and does not propagate,
as expected.
was (Author: cstamas):
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps declared in profiles are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader (resolver specific) does
not implement MavenWorkspaceReader (maven specific) while newly added
MavenChainedWorkspaceReader does -> SOLVES the issue, as resolver will "come
back" to reactor workspace reader and get the model already built with profile
applied due CLI`-PextraDeps`, instead to build it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
[jira] [Comment Edited] (MNG-7432) [REGRESSION] Dependencies from profile not picked up via -P
[
https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516300#comment-17516300
]
Tamás Cservenák edited comment on MNG-7432 at 4/2/22 1:52 PM:
--
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps declared in profiles are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader (resolver specific) does
not implement MavenWorkspaceReader (maven specific) while newly added
MavenChainedWorkspaceReader does -> SOLVES the issue, as resolver will "come
back" to reactor workspace reader and get the model already built with profile
applied due CLI`-PextraDeps`, instead to build it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected session (as it has proper reactor WSR injected into session), The
_same code snippet_ will NEVER work if runs "standalone", outside of Maven
scope!
* The reproducer clearly violates MNG-1388: what
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies goal does
IMHO VIOLATES MNG-1388 in a way, that it resolves the current project (as a
dependency!) and expects to have profile applied.
* What reproducer
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies IMHO
SHOULD DO instead, is to utilize already built model of module (already
injected as {{MavenProject project}}) and resolver it's dependencies
({{project.getDependencies()}}) as dependencies instead, In that case, the
transitive hull is guaranteed to be equivalent to what Maven resolved.
Summary:
* fix possible w/ simplification (disregard length, just always wrap WSR into
MavenChainedWorkspaceReader) should be applied IMHO
* reproducer does reproduce as expected, but IMHO it does "wrong thing" to
start with. Am afraid if we put this into Maven ITs we will put into concrete
this wrong behaviour.
* test for the fix is IMHO just an assertion that WHEN resolver resolves within
Maven scope, this is true:
{{org.eclipse.aether.RepositorySystemSession#getWorkspaceReader insteanceof
MavenWorkspaceReader}} (and NEVER "raw" resolver specific WorkspaceReader).
Notes:
* as related MNG-1388 issue documents, the actual BUG is that non-{{-P}}
activators (property, file, etc) DOES KICK IN while resolving downstream
transitive dependencies, WHILE THEY SHOULD NOT, as "profile" is defined only in
realm of reactor, but NOT in the realm of downstream dependencies. These stem
from environment (system property set, file presence, etc) hence propagate,
while {{-P}} activator is explicitly given on CLI only, and does not propagate,
as expected.
was (Author: cstamas):
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps declared in profiles are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader (resolver specific) does
not implement MavenWorkspaceReader (maven specific) while newly added
MavenChainedWorkspaceReader does -> SOLVES the issue, as resolver will "come
back" to reactor workspace reader and get the model WITH PROFILE ALREADY
APPLIED with `-PextraDeps` instead to build it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected
[GitHub] [maven] laeubi commented on a change in pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
laeubi commented on a change in pull request #695:
URL: https://github.com/apache/maven/pull/695#discussion_r841078921
##
File path:
maven-core/src/main/java/org/apache/maven/internal/aether/MavenChainedWorkspaceReader.java
##
@@ -0,0 +1,106 @@
+package org.apache.maven.internal.aether;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.File;
+import java.util.Collection;
+import java.util.List;
+
+import org.apache.maven.model.Model;
+import org.apache.maven.repository.internal.MavenWorkspaceReader;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.repository.WorkspaceReader;
+import org.eclipse.aether.repository.WorkspaceRepository;
+import org.eclipse.aether.util.repository.ChainedWorkspaceReader;
+
+/**
+ * A maven workspace reader that delegates to a chain of other readers,
effectively aggregating their contents.
+ */
+public final class MavenChainedWorkspaceReader
+implements MavenWorkspaceReader
+{
+
+private ChainedWorkspaceReader delegate;
+
+private WorkspaceReader[] readers;
+
+/**
+ * Creates a new workspace reader by chaining the specified readers.
+ *
+ * @param readers The readers to chain must not be {@code null}.
+ */
+private MavenChainedWorkspaceReader( WorkspaceReader... readers )
+{
+this.delegate = new ChainedWorkspaceReader( readers );
+this.readers = readers;
+}
+
+@Override
+public Model findModel( Artifact artifact )
+{
+for ( WorkspaceReader workspaceReader : readers )
+{
+if ( workspaceReader instanceof MavenWorkspaceReader )
+{
+Model model = ( (MavenWorkspaceReader) workspaceReader
).findModel( artifact );
+if ( model != null )
+{
+return model;
+}
+}
+}
+return null;
+}
+
+@Override
+public WorkspaceRepository getRepository()
+{
+return delegate.getRepository();
+}
+
+@Override
+public File findArtifact( Artifact artifact )
+{
+return delegate.findArtifact( artifact );
+}
+
+@Override
+public List findVersions( Artifact artifact )
+{
+return delegate.findVersions( artifact );
+}
+
+/**
+ * chains a collection of {@link WorkspaceReader}s
+ * @param workspaceReaderCollection the collection of readers, might be
empty but never null
+ * @return if the collection contains only one item returns the single
item, otherwise creates a new
+ * {@link MavenChainedWorkspaceReader} chaining all readers in the
order of the given collection.
+ */
+public static WorkspaceReader of( Collection
workspaceReaderCollection )
+{
+WorkspaceReader[] readers = workspaceReaderCollection.toArray( new
WorkspaceReader[0] );
+if ( readers.length == 1 )
Review comment:
I think the complexity is manageable given that in most cases there is
only one WSP and we save useless loop calls in that case when it is used across
the maven build.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Comment Edited] (MNG-7432) [REGRESSION] Dependencies from profile not picked up via -P
[
https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516300#comment-17516300
]
Tamás Cservenák edited comment on MNG-7432 at 4/2/22 1:45 PM:
--
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps declared in profiles are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader (resolver specific) does
not implement MavenWorkspaceReader (maven specific) while newly added
MavenChainedWorkspaceReader does -> SOLVES the issue, as resolver will "come
back" to reactor workspace reader and get the model WITH PROFILE ALREADY
APPLIED with `-PextraDeps` instead to build it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected session (as it has proper reactor WSR injected into session), The
_same code snippet_ will NEVER work if runs "standalone", outside of Maven
scope!
* The reproducer clearly violates MNG-1388: what
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies goal does
IMHO VIOLATES MNG-1388 in a way, that it resolves the current project (as a
dependency!) and expects to have profile applied.
* What reproducer
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies IMHO
SHOULD DO instead, is to utilize already built model of module (already
injected as {{MavenProject project}}) and resolver it's dependencies
({{project.getDependencies()}}) as dependencies instead, In that case, the
transitive hull is guaranteed to be equivalent to what Maven resolved.
Summary:
* fix possible w/ simplification (disregard length, just always wrap WSR into
MavenChainedWorkspaceReader) should be applied IMHO
* reproducer does reproduce as expected, but IMHO it does "wrong thing" to
start with. Am afraid if we put this into Maven ITs we will put into concrete
this wrong behaviour.
* test for the fix is IMHO just an assertion that WHEN resolver resolves within
Maven scope, this is true:
{{org.eclipse.aether.RepositorySystemSession#getWorkspaceReader insteanceof
MavenWorkspaceReader}} (and NEVER "raw" resolver specific WorkspaceReader).
Notes:
* as related MNG-1388 issue documents, the actual BUG is that non-{{-P}}
activators (property, file, etc) DOES KICK IN while resolving downstream
transitive dependencies, WHILE THEY SHOULD NOT, as "profile" is defined only in
realm of reactor, but NOT in the realm of downstream dependencies. These stem
from environment (system property set, file presence, etc) hence propagate,
while {{-P}} activator is explicitly given on CLI only, and does not propagate,
as expected.
was (Author: cstamas):
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader (resolver specific) does
not implement MavenWorkspaceReader (maven specific) while newly added
MavenChainedWorkspaceReader does -> SOLVES the issue, as resolver will "come
back" to reactor workspace reader and get the model WITH PROFILE ALREADY
APPLIED with `-PextraDeps` instead to build it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected session (as it has proper
[jira] [Commented] (MSHADE-417) Nul bytes appended to small files by maven-shade-plugin
[
https://issues.apache.org/jira/browse/MSHADE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516308#comment-17516308
]
Max Zerzouri commented on MSHADE-417:
-
Looking at the changes in that PR, I would guess it's because of these lines in
{{ZipHeaderPeekInputStream.hasZipHeader}}:
{code:java}
final byte[] header = new byte[HEADER_LEN];
super.read( header, 0, HEADER_LEN );
super.unread( header );
{code}
It always pushes back the entirety of that byte array (4 bytes,
{{HEADER_LEN}}), even though {{super.read}} could have read less than 4 bytes.
The remaining bytes in the {{header}} array will naturally be 0. It should
probably be looking at the return value of {{super.read}} to know how many
bytes to actually {{unread}}.
> Nul bytes appended to small files by maven-shade-plugin
> ---
>
> Key: MSHADE-417
> URL: https://issues.apache.org/jira/browse/MSHADE-417
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Max Zerzouri
>Priority: Major
> Attachments: original-shadetest-0.0.0.jar, pom.xml,
> shadetest-0.0.0.jar, test.txt
>
>
> Version 3.3.0 of maven shade plugin seems to append "\x00" bytes to a file if
> it's less than 4 bytes:
> {code:sh}
> $ echo -n a > src/main/resources/test.txt
> $ mvn clean install
> ...
> $ bsdtar -xOf target/original-shadetest-0.0.0.jar test.txt | xxd
> : 61 a
> $ bsdtar -xOf target/shadetest-0.0.0.jar test.txt | xxd
> : 6100 a...
> {code}
> I've attached a basic {{pom.xml}} that triggers this. This doesn't occur in
> the previous version, 3.2.4.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MNG-7432) [REGRESSION] Dependencies from profile not picked up via -P
[
https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516300#comment-17516300
]
Tamás Cservenák edited comment on MNG-7432 at 4/2/22 1:41 PM:
--
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader (resolver specific) does
not implement MavenWorkspaceReader (maven specific) while newly added
MavenChainedWorkspaceReader does -> SOLVES the issue, as resolver will "come
back" to reactor workspace reader and get the model WITH PROFILE ALREADY
APPLIED with `-PextraDeps` instead to build it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected session (as it has proper reactor WSR injected into session), The
_same code snippet_ will NEVER work if runs "standalone", outside of Maven
scope!
* The reproducer clearly violates MNG-1388: what
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies goal does
IMHO VIOLATES MNG-1388 in a way, that it resolves the current project (as a
dependency!) and expects to have profile applied.
* What reproducer
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies IMHO
SHOULD DO instead, is to utilize already built model of module (already
injected as {{MavenProject project}}) and resolver it's dependencies
({{project.getDependencies()}}) as dependencies instead, In that case, the
transitive hull is guaranteed to be equivalent to what Maven resolved.
Summary:
* fix possible w/ simplification (disregard length, just always wrap WSR into
MavenChainedWorkspaceReader) should be applied IMHO
* reproducer does reproduce as expected, but IMHO it does "wrong thing" to
start with. Am afraid if we put this into Maven ITs we will put into concrete
this wrong behaviour.
* test for the fix is IMHO just an assertion that WHEN resolver resolves within
Maven scope, this is true:
{{org.eclipse.aether.RepositorySystemSession#getWorkspaceReader insteanceof
MavenWorkspaceReader}} (and NEVER "raw" resolver specific WorkspaceReader).
Notes:
* as related MNG-1388 issue documents, the actual BUG is that non-{{-P}}
activators (property, file, etc) DOES KICK IN while resolving downstream
transitive dependencies, WHILE THEY SHOULD NOT, as "profile" is defined only in
realm of reactor, but NOT in the realm of downstream dependencies. These stem
from environment (system property set, file presence, etc) hence propagate,
while {{-P}} activator is explicitly given on CLI only, and does not propagate,
as expected.
was (Author: cstamas):
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader (resolver specific) does
not implement MavenWorkspaceReader (maven specific) while newly added
MavenChainedWorkspaceReader does -> SOLVES the issue, as resolver will "come
back" to reactor workspace reader and get the model WITH PROFILE ALREADY
APPLIED with `-PextraDeps` instead to build it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected session (as it has proper reactor WSR injected into
[GitHub] [maven] cstamas commented on a change in pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
cstamas commented on a change in pull request #695:
URL: https://github.com/apache/maven/pull/695#discussion_r841077022
##
File path:
maven-core/src/main/java/org/apache/maven/internal/aether/MavenChainedWorkspaceReader.java
##
@@ -0,0 +1,106 @@
+package org.apache.maven.internal.aether;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.File;
+import java.util.Collection;
+import java.util.List;
+
+import org.apache.maven.model.Model;
+import org.apache.maven.repository.internal.MavenWorkspaceReader;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.repository.WorkspaceReader;
+import org.eclipse.aether.repository.WorkspaceRepository;
+import org.eclipse.aether.util.repository.ChainedWorkspaceReader;
+
+/**
+ * A maven workspace reader that delegates to a chain of other readers,
effectively aggregating their contents.
+ */
+public final class MavenChainedWorkspaceReader
+implements MavenWorkspaceReader
+{
+
+private ChainedWorkspaceReader delegate;
+
+private WorkspaceReader[] readers;
+
+/**
+ * Creates a new workspace reader by chaining the specified readers.
+ *
+ * @param readers The readers to chain must not be {@code null}.
+ */
+private MavenChainedWorkspaceReader( WorkspaceReader... readers )
+{
+this.delegate = new ChainedWorkspaceReader( readers );
+this.readers = readers;
+}
+
+@Override
+public Model findModel( Artifact artifact )
+{
+for ( WorkspaceReader workspaceReader : readers )
+{
+if ( workspaceReader instanceof MavenWorkspaceReader )
+{
+Model model = ( (MavenWorkspaceReader) workspaceReader
).findModel( artifact );
+if ( model != null )
+{
+return model;
+}
+}
+}
+return null;
+}
+
+@Override
+public WorkspaceRepository getRepository()
+{
+return delegate.getRepository();
+}
+
+@Override
+public File findArtifact( Artifact artifact )
+{
+return delegate.findArtifact( artifact );
+}
+
+@Override
+public List findVersions( Artifact artifact )
+{
+return delegate.findVersions( artifact );
+}
+
+/**
+ * chains a collection of {@link WorkspaceReader}s
+ * @param workspaceReaderCollection the collection of readers, might be
empty but never null
+ * @return if the collection contains only one item returns the single
item, otherwise creates a new
+ * {@link MavenChainedWorkspaceReader} chaining all readers in the
order of the given collection.
+ */
+public static WorkspaceReader of( Collection
workspaceReaderCollection )
+{
+WorkspaceReader[] readers = workspaceReaderCollection.toArray( new
WorkspaceReader[0] );
+if ( readers.length == 1 )
Review comment:
I'd personally just remove this length check, and make it always wrapped
(is simpler).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Comment Edited] (MNG-7432) [REGRESSION] Dependencies from profile not picked up via -P
[
https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516300#comment-17516300
]
Tamás Cservenák edited comment on MNG-7432 at 4/2/22 1:36 PM:
--
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader (resolver specific) does
not implement MavenWorkspaceReader (maven specific) while newly added
MavenChainedWorkspaceReader does -> SOLVES the issue, as resolver will "come
back" to reactor workspace reader and get the model WITH PROFILE ALREADY
APPLIED with `-PextraDeps` instead to build it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected session (as it has proper reactor WSR injected into session), The
_same code snippet_ will NEVER work if runs "standalone", outside of Maven
scope!
* The reproducer clearly violates MNG-1388: what
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies goal does
IMHO VIOLATES MNG-1388 in a way, that it resolves the current project (as a
dependency!) and expects to have profile applied.
* What reproducer
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies IMHO
SHOULD DO instead, is to utilize already built model of module (already
injected as {{MavenProject project}}) and resolver it's dependencies
({{project.getDependencies()}}) as dependencies instead, In that case, the
transitive hull is guaranteed to be equivalent to what Maven resolved.
Summary:
* fix possible w/ simplification (disregard length, just always wrap WSR into
MavenChainedWorkspaceReader) should be applied IMHO
* reproducer does reproduce as expected, but IMHO it does "wrong thing" to
start with. Am afraid if we put this into Maven ITs we will put into concrete
this wrong behaviour.
* test for the fix is IMHO just an assertion that WHEN resolver resolves within
Maven scope, this is true:
{{org.eclipse.aether.RepositorySystemSession#getWorkspaceReader insteanceof
MavenWorkspaceReader}} (and not "raw" resolver specific WorkspaceReader).
Notes:
* as related MNG-1388 issue documents, the actual BUG is that non-{{-P}}
activators (property, file, etc) DOES KICK IN while resolving downstream
transitive dependencies, WHILE THEY SHOULD NOT, as "profile" is defined only in
realm of reactor, but NOT in the realm of downstream dependencies. These stem
from environment (system property set, file presence, etc) hence propagate,
while {{-P}} activator is explicitly given on CLI only, and does not propagate,
as expected.
was (Author: cstamas):
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader (resolver specific) does
not implement MavenWorkspaceReader (maven specific) while newly added
MavenChainedWorkspaceReader does -> SOLVES the issue, as resolver will "come
back" to reactor workspace reader and get the model WITH PROFILE ALREADY
APPLIED with `-PextraDeps` instead to build it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected session (as it has proper reactor WSR injected into
[jira] [Comment Edited] (MNG-7432) [REGRESSION] Dependencies from profile not picked up via -P
[
https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516300#comment-17516300
]
Tamás Cservenák edited comment on MNG-7432 at 4/2/22 1:35 PM:
--
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader (resolver specific) does
not implement MavenWorkspaceReader (maven specific) while newly added
MavenChainedWorkspaceReader does -> SOLVES the issue, as resolver will "come
back" to reactor workspace reader and get the model WITH PROFILE ALREADY
APPLIED with `-PextraDeps` instead to build it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected session (as it has proper reactor WSR injected into session), The
_same code snippet_ will NEVER work if runs "standalone", outside of Maven
scope!
* The reproducer clearly violates MNG-1388: what
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies goal does
IMHO VIOLATES MNG-1388 in a way, that it resolves the current project (as a
dependency!) and expects to have profile applied.
* What reproducer
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies IMHO
SHOULD DO instead, is to utilize already built model of module (already
injected as {{MavenProject project}}) and resolver it's dependencies
({{project.getDependencies()}}) as dependencies instead, In that case, the
transitive hull is guaranteed to be equivalent to what Maven resolved.
Summary:
* fix possible w/ simplification (disregard length, just always wrap WSR into
MavenChainedWorkspaceReader) should be applied IMHO
* reproducer does reproduce as expected, but IMHO it does "wrong thing" to
start with. Am afraid if we put this into Maven ITs we will put into concrete
this wrong behaviour.
* test for the fix is IMHO just an assertion that WHEN resolver resolvers
within Maven scope, this is true:
{{org.eclipse.aether.RepositorySystemSession#getWorkspaceReader insteanceof
MavenWorkspaceReader}} (and not "raw" resolver specific WorkspaceReader).
Notes:
* as related MNG-1388 issue documents, the actual BUG is that non-{{-P}}
activators (property, file, etc) DOES KICK IN while resolving downstream
transitive dependencies, WHILE THEY SHOULD NOT, as "profile" is defined only in
realm of reactor, but NOT in the realm of downstream dependencies. These stem
from environment (system property set, file presence, etc) hence propagate,
while {{-P}} activator is explicitly given on CLI only, and does not propagate,
as expected.
was (Author: cstamas):
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader (resolver specific) does
not implement MavenWorkspaceReader (maven specific) while newly added
MavenChainedWorkspaceReader does -> SOLVES the issue, as resolver will "come
back" to reactor workspace reader and get the model WITH PROFILE ALREADY
APPLIED with `-PextraDeps` instead to build it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected session (as it has proper reactor WSR injected into
[GitHub] [maven] cstamas commented on pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
cstamas commented on pull request #695: URL: https://github.com/apache/maven/pull/695#issuecomment-1086642516 Added some explanations here: https://issues.apache.org/jira/browse/MNG-7432?focusedCommentId=17516300=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17516300 -- 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] cstamas commented on a change in pull request #695: [MNG-7432] Dependencies from profile not picked up via -P
cstamas commented on a change in pull request #695:
URL: https://github.com/apache/maven/pull/695#discussion_r841077022
##
File path:
maven-core/src/main/java/org/apache/maven/internal/aether/MavenChainedWorkspaceReader.java
##
@@ -0,0 +1,106 @@
+package org.apache.maven.internal.aether;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.File;
+import java.util.Collection;
+import java.util.List;
+
+import org.apache.maven.model.Model;
+import org.apache.maven.repository.internal.MavenWorkspaceReader;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.repository.WorkspaceReader;
+import org.eclipse.aether.repository.WorkspaceRepository;
+import org.eclipse.aether.util.repository.ChainedWorkspaceReader;
+
+/**
+ * A maven workspace reader that delegates to a chain of other readers,
effectively aggregating their contents.
+ */
+public final class MavenChainedWorkspaceReader
+implements MavenWorkspaceReader
+{
+
+private ChainedWorkspaceReader delegate;
+
+private WorkspaceReader[] readers;
+
+/**
+ * Creates a new workspace reader by chaining the specified readers.
+ *
+ * @param readers The readers to chain must not be {@code null}.
+ */
+private MavenChainedWorkspaceReader( WorkspaceReader... readers )
+{
+this.delegate = new ChainedWorkspaceReader( readers );
+this.readers = readers;
+}
+
+@Override
+public Model findModel( Artifact artifact )
+{
+for ( WorkspaceReader workspaceReader : readers )
+{
+if ( workspaceReader instanceof MavenWorkspaceReader )
+{
+Model model = ( (MavenWorkspaceReader) workspaceReader
).findModel( artifact );
+if ( model != null )
+{
+return model;
+}
+}
+}
+return null;
+}
+
+@Override
+public WorkspaceRepository getRepository()
+{
+return delegate.getRepository();
+}
+
+@Override
+public File findArtifact( Artifact artifact )
+{
+return delegate.findArtifact( artifact );
+}
+
+@Override
+public List findVersions( Artifact artifact )
+{
+return delegate.findVersions( artifact );
+}
+
+/**
+ * chains a collection of {@link WorkspaceReader}s
+ * @param workspaceReaderCollection the collection of readers, might be
empty but never null
+ * @return if the collection contains only one item returns the single
item, otherwise creates a new
+ * {@link MavenChainedWorkspaceReader} chaining all readers in the
order of the given collection.
+ */
+public static WorkspaceReader of( Collection
workspaceReaderCollection )
+{
+WorkspaceReader[] readers = workspaceReaderCollection.toArray( new
WorkspaceReader[0] );
+if ( readers.length == 1 )
Review comment:
I'd personally would just remove this length check, and make it always
wrapped (is simpler).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Comment Edited] (MNG-7432) [REGRESSION] Dependencies from profile not picked up via -P
[
https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516300#comment-17516300
]
Tamás Cservenák edited comment on MNG-7432 at 4/2/22 1:31 PM:
--
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader (resolver specific) does
not implement MavenWorkspaceReader (maven specific) while newly added
MavenChainedWorkspaceReader does -> SOLVES the issue, as resolver will "come
back" to reactor workspace reader and get the model WITH PROFILE ALREADY
APPLIED with `-PextraDeps` instead to build it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected session (as it has proper reactor WSR injected into session), The
_same code snippet_ will NEVER work if runs "standalone", outside of Maven
scope!
* The reproducer clearly violates MNG-1388: what
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies goal does
IMHO VIOLATES MNG-1388 in a way, that it resolves the current project (as a
dependency!) and expects to have profile applied.
* What reproducer
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies IMHO
SHOULD DO instead, is to utilize already built model of module (already
injected as {{MavenProject project}}) and resolver it's dependencies
({{project.getDependencies()}}) as dependencies instead, In that case, the
transitive hull is guaranteed to be equivalent to what Maven resolved.
Summary:
* fix possible w/ simplification (disregard length, just always wrap WSR into
MavenChainedWorkspaceReader) should be applied IMHO
* reproducer does reproduce as expected, but IMHO it does "wrong thing" to
start with. Am afraid if we put this into Maven ITs we will put into concrete
this wrong behaviour.
* test for the fix is IMHO just an assertion that WHEN resolver resolvers
within Maven scope, this is true: {{WSR insteanceof MavenWorkspaceReader}} (and
not "raw" resolver specific WorkspaceReader).
Notes:
* as related MNG-1388 issue documents, the actual BUG is that non-{{-P}}
activators (property, file, etc) DOES KICK IN while resolving downstream
transitive dependencies, WHILE THEY SHOULD NOT, as "profile" is defined only in
realm of reactor, but NOT in the realm of downstream dependencies. These stem
from environment (system property set, file presence, etc) hence propagate,
while {{-P}} activator is explicitly given on CLI only, and does not propagate,
as expected.
was (Author: cstamas):
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader (resolver specific) does
not implement MavenWorkspaceReader (maven specific) while newly added
MavenChainedWorkspaceReader does -> SOLVES the issue, as resolver will "come
back" to reactor workspace reader and get the model WITH PROFILE ALREADY
APPLIED with `-PextraDeps` instead to build it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected session (as it has proper reactor WSR injected into session), The
_same code snippet_ will NEVER work if runs
[jira] [Comment Edited] (MNG-7432) [REGRESSION] Dependencies from profile not picked up via -P
[
https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516300#comment-17516300
]
Tamás Cservenák edited comment on MNG-7432 at 4/2/22 1:16 PM:
--
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader (resolver specific) does
not implement MavenWorkspaceReader (maven specific) while newly added
MavenChainedWorkspaceReader does -> SOLVES the issue, as resolver will "come
back" to reactor workspace reader and get the model WITH PROFILE ALREADY
APPLIED with `-PextraDeps` instead to build it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected session (as it has proper reactor WSR injected into session), The
_same code snippet_ will NEVER work if runs "standalone", outside of Maven
scope!
* The reproducer clearly violates MNG-1388: what
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies goal does
IMHO VIOLATES MNG-1388 in a way, that it resolves the current project (as a
dependency!) and expects to have profile applied.
* What reproducer
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies IMHO
SHOULD DO instead, is to utilize already built model of module (already
injected as {{MavenProject project}}) and resolver it's dependencies
({{project.getDependencies()}}) as dependencies instead, In that case, the
transitive hull is guaranteed to be equivalent to what Maven resolved.
Summary:
* fix possible w/ simplification (disregard length, just always wrap WSR into
MavenChainedWorkspaceReader) should be applied IMHO
* reproducer does reproduce as expected, but IMHO it does "wrong thing" to
start with. Am afraid if we put this into Maven ITs we will put into concrete
this wrong behaviour.
* test for the fix is IMHO just an assertion that WHEN resolver resolvers
within Maven scope, this is true: {{WSR insteanceof MavenWorkspaceReader}} and
not "raw" resolver specific WorkspaceReader.
Notes:
* as related MNG-1388 issue documents, the actual BUG is that non-{{-P}}
activators (property, file, etc) DOES KICK IN while resolving downstream
transitive dependencies, WHILE THEY SHOULD NOT, as "profile" is defined only in
realm of reactor, but NOT in the realm of downstream dependencies. These stem
from environment (system property set, file presence, etc) hence propagate,
while {{-P}} activator is explicitly given on CLI only, and does not propagate,
as expected.
was (Author: cstamas):
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader (resolver specific) does
not implement MavenWorkspaceReader (maven specific) while newly added
MavenChainedWorkspaceReader does -> SOLVES the issue, as resolver will "come
back" to reactor workspace reader and get the model WITH PROFILE ALREADY
APPLIED with `-PextraDeps` instead to build it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected session (as it has proper reactor WSR injected into session), The
_same code snippet_ will NEVER work if runs
[jira] [Comment Edited] (MNG-7432) [REGRESSION] Dependencies from profile not picked up via -P
[
https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516300#comment-17516300
]
Tamás Cservenák edited comment on MNG-7432 at 4/2/22 1:16 PM:
--
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader (resolver specific) does
not implement MavenWorkspaceReader (maven specific) while newly added
MavenChainedWorkspaceReader does -> SOLVES the issue, as resolver will "come
back" to reactor workspace reader and get the model WITH PROFILE ALREADY
APPLIED with `-PextraDeps` instead to build it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected session (as it has proper reactor WSR injected into session), The
_same code snippet_ will NEVER work if runs "standalone", outside of Maven
scope!
* The reproducer clearly violates MNG-1388: what
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies goal does
IMHO VIOLATES MNG-1388 in a way, that it resolves the current project (as a
dependency!) and expects to have profile applied.
* What reproducer
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies IMHO
SHOULD DO instead, is to utilize already built model of module (already
injected as {{MavenProject project}}) and resolver it's dependencies
({{project.getDependencies()}}) as dependencies instead, In that case, the
transitive hull is guaranteed to be equivalent to what Maven resolved.
Summary:
* fix possible w/ simplification (disregard length, just always wrap WSR into
MavenChainedWorkspaceReader) should be applied IMHO
* reproducer does reproduce as expected, but IMHO it does "wrong thing" to
start with. Am afraid if we put this into Maven ITs we will put into concrete
this wrong behaviour.
* test for the fix is IMHO just an assertion that WHEN resolver resolvers
within Maven scope, this is true: {{WSR insteanceof MavenWorkspaceReader}} and
not "raw" resolver specific WorkspaceReader.
Notes:
* as related MNG-1388 issue documents, the actual BUG is that non-{{-P}}
activators (property, file, etc) DOES KICK IN while resolving downstream
transitive dependencies, WHILE THEY SHOULD NOT, as "profile" is defined only in
realm of reactor, but NOT in the realm of downstream dependencies. These stem
from environment (system property set, file presence) hence propagate, while
{{-P}} activator is explicitly given on CLI only, and does not propagate, as
expected.
was (Author: cstamas):
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader (resolver specific) does
not implement MavenWorkspaceReader (maven specific) while newly added
MavenChainedWorkspaceReader does -> SOLVES the issue, as resolver will "come
back" to reactor workspace reader and get the model WITH PROFILE ALREADY
APPLIED with `-PextraDeps` instead to build it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected session (as it has proper reactor WSR injected into session), The
_same code snippet_ will NEVER work if runs
[jira] [Comment Edited] (MNG-7432) [REGRESSION] Dependencies from profile not picked up via -P
[
https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516300#comment-17516300
]
Tamás Cservenák edited comment on MNG-7432 at 4/2/22 1:14 PM:
--
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader (resolver specific) does
not implement MavenWorkspaceReader (maven specific) while newly added
MavenChainedWorkspaceReader does -> SOLVES the issue, as resolver will "come
back" to reactor workspace reader and get the model WITH PROFILE ALREADY
APPLIED with `-PextraDeps` instead to build it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected session (as it has proper reactor WSR injected into session), The
_same code snippet_ will NEVER work if runs "standalone", outside of Maven
scope!
* The reproducer clearly violates MNG-1388: what
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies goal does
IMHO VIOLATES MNG-1388 in a way, that it resolves the current project (as a
dependency!) and expects to have profile applied.
* What reproducer
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies IMHO
SHOULD DO instead, is to utilize already built model of module (already
injected as {{MavenProject project}}) and resolver it's dependencies
({{project.getDependencies()}}) as dependencies instead, In that case, the
transitive hull is guaranteed to be equivalent to what Maven resolved.
Summary:
* fix possible w/ simplification (disregard length, just always wrap WSR into
MavenChainedWorkspaceReader) should be applied IMHO
* reproducer does reproduce as expected, but IMHO it does "wrong thing" to
start with. Am afraid if we put this into Maven ITs we will put into concrete
this wrong behaviour.
* test for the fix is IMHO just an assertion that WHEN resolver resolvers
within Maven scope, this is true: {{WSR insteanceof MavenWorkspaceReader}} and
not "raw" resolver specific WorkspaceReader.
Notes:
* as related MNG-1388 issue documents, the actual BUG is that non-{{-P}}
activators (property, file, etc) DOES KICK IN while resolving downstream
transitive dependencies, WHILE THEY SHOULD NOT, as "profile" is defined only in
realm of reactor, but NOT in the realm of downstream dependencies. These stem
of "environment" (system property set, file presence) hence propagate, while
{{-P}} activator is explicitly given on CLI only, and does not propagate, as
expected.
was (Author: cstamas):
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader does not implement
MavenWorkspaceReader while newly added MavenChainedWorkspaceReader does ->
SOLVES the issue, as resolver will "come back" to reactor workspace reader and
get the model WITH PROFILE ALREADY APPLIED with `-PextraDeps` instead to build
it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected session (as it has proper reactor WSR injected into session), The
_same code snippet_ will NEVER work if runs "standalone", outside of Maven
scope!
* The
[jira] [Comment Edited] (MNG-7432) [REGRESSION] Dependencies from profile not picked up via -P
[
https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516300#comment-17516300
]
Tamás Cservenák edited comment on MNG-7432 at 4/2/22 1:13 PM:
--
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified though)
* The problem is that Resolver ChainedWorkspaceReader does not implement
MavenWorkspaceReader while newly added MavenChainedWorkspaceReader does ->
SOLVES the issue, as resolver will "come back" to reactor workspace reader and
get the model WITH PROFILE ALREADY APPLIED with `-PextraDeps` instead to build
it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected session (as it has proper reactor WSR injected into session), The
_same code snippet_ will NEVER work if runs "standalone", outside of Maven
scope!
* The reproducer clearly violates MNG-1388: what
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies goal does
IMHO VIOLATES MNG-1388 in a way, that it resolves the current project (as a
dependency!) and expects to have profile applied.
* What reproducer
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies IMHO
SHOULD DO instead, is to utilize already built model of module (already
injected as {{MavenProject project}}) and resolver it's dependencies
({{project.getDependencies()}}) as dependencies instead, In that case, the
transitive hull is guaranteed to be equivalent to what Maven resolved.
Summary:
* fix possible w/ simplification (disregard length, just always wrap WSR into
MavenChainedWorkspaceReader) should be applied IMHO
* reproducer does reproduce as expected, but IMHO it does "wrong thing" to
start with. Am afraid if we put this into Maven ITs we will put into concrete
this wrong behaviour.
* test for the fix is IMHO just an assertion that WHEN resolver resolvers
within Maven scope, this is true: {{WSR insteanceof MavenWorkspaceReader}} and
not "raw" resolver specific WorkspaceReader.
Notes:
* as related MNG-1388 issue documents, the actual BUG is that non-{{-P}}
activators (property, file, etc) DOES KICK IN while resolving downstream
transitive dependencies, WHILE THEY SHOULD NOT, as "profile" is defined only in
realm of reactor, but NOT in the realm of downstream dependencies. These stem
of "environment" (system property set, file presence) hence propagate, while
{{-P}} activator is explicitly given on CLI only, and does not propagate, as
expected.
was (Author: cstamas):
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified thought)
* The problem is that Resolver ChainedWorkspaceReader does not implement
MavenWorkspaceReader while newly added MavenChainedWorkspaceReader does ->
SOLVES the issue, as resolver will "come back" to reactor workspace reader and
get the model WITH PROFILE ALREADY APPLIED with `-PextraDeps` instead to build
it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected session (as it has proper reactor WSR injected into session), The
_same code snippet_ will NEVER work if runs "standalone", outside of Maven
scope!
* The reproducer clearly violates
[jira] [Commented] (MNG-7432) [REGRESSION] Dependencies from profile not picked up via -P
[
https://issues.apache.org/jira/browse/MNG-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516300#comment-17516300
]
Tamás Cservenák commented on MNG-7432:
--
Went thru this issue and here are my findings:
* title is wrong: Maven _does_ pick up profile dependencies all right, it
happens only if _Resolver used directly within Mojo to resolve project_ (then
profile is not applied, hence deps are not present).
* The reproducer found here
https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
does reproduce the issue (but it has several other issues, more about it later)
* The fix found here https://github.com/apache/maven/pull/695 fixes the issue
(can be simplified thought)
* The problem is that Resolver ChainedWorkspaceReader does not implement
MavenWorkspaceReader while newly added MavenChainedWorkspaceReader does ->
SOLVES the issue, as resolver will "come back" to reactor workspace reader and
get the model WITH PROFILE ALREADY APPLIED with `-PextraDeps` instead to build
it from scratch.
* In maven 3.8.5 this does not happen as Resolver ChainedWorkspaceReader is not
instance of MavenWorkspaceReader, and model is built from scratch, but as
Resolver is maven agnostic (hence is profile agnostic as well, no way to "tell"
resolver about profiles to pass it downstream to model builder), no profile is
applied whatsoever, as explained in MNG-1388
So, problems with reproducer:
* the reproduce code WILL WORK ONLY when executed within Mojo using Maven
injected session (as it has proper reactor WSR injected into session), The
_same code snippet_ will NEVER work if runs "standalone", outside of Maven
scope!
* The reproducer clearly violates MNG-1388: what
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies goal does
IMHO VIOLATES MNG-1388 in a way, that it resolves the current project (as a
dependency!) and expects to have profile applied.
* What reproducer
org.acme:acme-maven-plugin:1.0-SNAPSHOT:resolve-project-dependencies IMHO
SHOULD DO instead, is to utilize already built model of module (already
injected as {{MavenProject project}}) and resolver it's dependencies
({{project.getDependencies()}}) as dependencies instead, In that case, the
transitive hull is guaranteed to be equivalent to what Maven resolved.
Summary:
* fix possible w/ simplification (disregard length, just always wrap WSR into
MavenChainedWorkspaceReader) should be applied IMHO
* reproducer does reproduce as expected, but IMHO it does "wrong thing" to
start with. Am afraid if we put this into Maven ITs we will put into concrete
this wrong behaviour.
* test for the fix is IMHO just an assertion that WHEN resolver resolvers
within Maven scope, this is true: {{WSR insteanceof MavenWorkspaceReader}} and
not "raw" resolver specific WorkspaceReader.
Notes:
* as related MNG-1388 issue documents, the actual BUG is that non-{{-P}}
activators (property, file, etc) DOES KICK IN while resolving downstream
transitive dependencies, WHILE THEY SHOULD NOT, as "profile" is defined only in
realm of reactor, but NOT in the realm of downstream dependencies. These stem
of "environment" (system property set, file presence) hence propagate, while
{{-P}} activator is explicitly given on CLI only, and does not propagate, as
expected.
> [REGRESSION] Dependencies from profile not picked up via -P
>
>
> Key: MNG-7432
> URL: https://issues.apache.org/jira/browse/MNG-7432
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.5
>Reporter: Falko Modler
>Priority: Critical
>
> The README of the following reproducer says it all:
> https://github.com/aloubyansky/playground/tree/maven-3.8.5-profile-activation
> Initially discussed here:
> https://github.com/quarkusio/quarkus/pull/24285#issuecomment-1067368625
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MSHADE-417) Nul bytes appended to small files by maven-shade-plugin
[
https://issues.apache.org/jira/browse/MSHADE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516299#comment-17516299
]
Herve Boutemy commented on MSHADE-417:
--
[~rmannibucau] it seems you have merged PR
https://github.com/apache/maven-shade-plugin/pull/73 but not updated MSHADE-378
: was it intentional?
and it seems it creates a strange behaviour, adding null bytes: do you have any
idea?
> Nul bytes appended to small files by maven-shade-plugin
> ---
>
> Key: MSHADE-417
> URL: https://issues.apache.org/jira/browse/MSHADE-417
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Max Zerzouri
>Priority: Major
> Attachments: original-shadetest-0.0.0.jar, pom.xml,
> shadetest-0.0.0.jar, test.txt
>
>
> Version 3.3.0 of maven shade plugin seems to append "\x00" bytes to a file if
> it's less than 4 bytes:
> {code:sh}
> $ echo -n a > src/main/resources/test.txt
> $ mvn clean install
> ...
> $ bsdtar -xOf target/original-shadetest-0.0.0.jar test.txt | xxd
> : 61 a
> $ bsdtar -xOf target/shadetest-0.0.0.jar test.txt | xxd
> : 6100 a...
> {code}
> I've attached a basic {{pom.xml}} that triggers this. This doesn't occur in
> the previous version, 3.2.4.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MSHADE-417) Nul bytes appended to small files by maven-shade-plugin
[
https://issues.apache.org/jira/browse/MSHADE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17515840#comment-17515840
]
Herve Boutemy edited comment on MSHADE-417 at 4/2/22 1:00 PM:
--
https://github.com/apache/maven-shade-plugin/commit/c798d01138e9fecdd6422a2a8acce22ca8987924
is the first bad commit
{noformat}
commit c798d01138e9fecdd6422a2a8acce22ca8987924
Author: jenrryyou
Date: Sun Nov 22 23:17:56 2020 +0800
[MSHADE-378] Shade plugin changes the compression level of nested jar… (#73)
* [MSHADE-378] Shade plugin changes the compression level of nested jar
entries
* [MSHADE-378] Shade plugin changes the compression level of nested jar
entries
Co-authored-by: shaoyao
.../apache/maven/plugins/shade/DefaultShader.java | 107 +++--
.../maven/plugins/shade/DefaultShaderTest.java | 67 +
2 files changed, 165 insertions(+), 9 deletions(-)
{noformat}
was (Author: michael-o):
{noformat}
c798d01138e9fecdd6422a2a8acce22ca8987924 is the first bad commit
commit c798d01138e9fecdd6422a2a8acce22ca8987924
Author: jenrryyou
Date: Sun Nov 22 23:17:56 2020 +0800
[MSHADE-378] Shade plugin changes the compression level of nested jar… (#73)
* [MSHADE-378] Shade plugin changes the compression level of nested jar
entries
* [MSHADE-378] Shade plugin changes the compression level of nested jar
entries
Co-authored-by: shaoyao
.../apache/maven/plugins/shade/DefaultShader.java | 107 +++--
.../maven/plugins/shade/DefaultShaderTest.java | 67 +
2 files changed, 165 insertions(+), 9 deletions(-)
{noformat}
> Nul bytes appended to small files by maven-shade-plugin
> ---
>
> Key: MSHADE-417
> URL: https://issues.apache.org/jira/browse/MSHADE-417
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Max Zerzouri
>Priority: Major
> Attachments: original-shadetest-0.0.0.jar, pom.xml,
> shadetest-0.0.0.jar, test.txt
>
>
> Version 3.3.0 of maven shade plugin seems to append "\x00" bytes to a file if
> it's less than 4 bytes:
> {code:sh}
> $ echo -n a > src/main/resources/test.txt
> $ mvn clean install
> ...
> $ bsdtar -xOf target/original-shadetest-0.0.0.jar test.txt | xxd
> : 61 a
> $ bsdtar -xOf target/shadetest-0.0.0.jar test.txt | xxd
> : 6100 a...
> {code}
> I've attached a basic {{pom.xml}} that triggers this. This doesn't occur in
> the previous version, 3.2.4.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MSHADE-417) Nul bytes appended to small files by maven-shade-plugin
[
https://issues.apache.org/jira/browse/MSHADE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516296#comment-17516296
]
Herve Boutemy commented on MSHADE-417:
--
bq. The first and foremost problem is that all packaging plugins use Maven
Archiver/Plexus Archiver/Commons Compress which MSHADE uses Java's ZipFile.
[~michael-o] I don't get why this is a problem nor how it is relevant to the
issue reported
> Nul bytes appended to small files by maven-shade-plugin
> ---
>
> Key: MSHADE-417
> URL: https://issues.apache.org/jira/browse/MSHADE-417
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Max Zerzouri
>Priority: Major
> Attachments: original-shadetest-0.0.0.jar, pom.xml,
> shadetest-0.0.0.jar, test.txt
>
>
> Version 3.3.0 of maven shade plugin seems to append "\x00" bytes to a file if
> it's less than 4 bytes:
> {code:sh}
> $ echo -n a > src/main/resources/test.txt
> $ mvn clean install
> ...
> $ bsdtar -xOf target/original-shadetest-0.0.0.jar test.txt | xxd
> : 61 a
> $ bsdtar -xOf target/shadetest-0.0.0.jar test.txt | xxd
> : 6100 a...
> {code}
> I've attached a basic {{pom.xml}} that triggers this. This doesn't occur in
> the previous version, 3.2.4.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2004) Empty report for single-module project with 'aggregate=true'
[
https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516289#comment-17516289
]
Tibor Digana commented on SUREFIRE-2004:
[~gzm55]
I am sorry but we are already on the mailing list with the release Vote.
I analysed the code but I was not totally sure about this business feature, so
I dedicated my time to the plan with milestones.
Now we know what lines of code should be touched, there are two potentional
fixes but this fix would require the developer to debug the code because there
are some open questions about the code. It would be worth to debug the code,
compare the flow in both one-pom, multiple-poms are make the decision about the
fix.
> Empty report for single-module project with 'aggregate=true'
>
>
> Key: SUREFIRE-2004
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2004
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.4, 3.0.0-M5
>Reporter: Alexander Kriegisch
>Priority: Major
> Fix For: waiting-for-apache-feedback
>
>
> Using either {{-Daggregate=true}} on CLI or {{true}}
> in the plugin configuration leads to an empty report (i.e. zero tests
> reported) when e.g. executing
> {code:none}
> mvn -Dmaven.test.failure.ignore=true -Daggregate=true clean verify
> surefire-report:report-only
> {code}
> in the context of a single-module project. As soon as I make the root module
> pom-packaged and move the tests to into a child module, the aggregate report
> works.
> FYI, if I do not define the plugin and its version in my POM at all, the
> default version 2.4 used by Maven on my workstation has the same problem, so
> this does not seem to be a 3.0.0-M5 issue only.
>
> Background info about how and why I actually stumbled across this problem: I
> have an OSS multi-module project with lots of expensive UI tests. The full
> build can take 2.5 hours. I wanted to test a few CLI settings before creating
> an additional GitHub CI build workflow which can be run on demand and always
> runs all tests in all modules (ignoring errors and failures), no matter what.
> In the end, it is supposed to create a single-file aggregate HTML report
> which can easily be attached to the build and later is available for
> download, if the user so chooses in order to analyse failing tests
> comfortable and without having to scroll through build logs. You get the
> picture, I guess. In the original project, there is a pom-packaged root POM,
> so the problem described in this issue does not occur there. I simply created
> a single-module dummy project in order to verify the effect of certain build
> options quickly and not having to wait for the slow original build to finish.
> Eventually, I noticed the issue described above.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2004) Empty report for single-module project with 'aggregate=true'
[
https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516286#comment-17516286
]
James Z.M. Gao commented on SUREFIRE-2004:
--
hi [~tibordigana], thx for your response.
this should be not a complex issue, could we have time to resolve this in
3.0.0-M6?
> Empty report for single-module project with 'aggregate=true'
>
>
> Key: SUREFIRE-2004
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2004
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.4, 3.0.0-M5
>Reporter: Alexander Kriegisch
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Using either {{-Daggregate=true}} on CLI or {{true}}
> in the plugin configuration leads to an empty report (i.e. zero tests
> reported) when e.g. executing
> {code:none}
> mvn -Dmaven.test.failure.ignore=true -Daggregate=true clean verify
> surefire-report:report-only
> {code}
> in the context of a single-module project. As soon as I make the root module
> pom-packaged and move the tests to into a child module, the aggregate report
> works.
> FYI, if I do not define the plugin and its version in my POM at all, the
> default version 2.4 used by Maven on my workstation has the same problem, so
> this does not seem to be a 3.0.0-M5 issue only.
>
> Background info about how and why I actually stumbled across this problem: I
> have an OSS multi-module project with lots of expensive UI tests. The full
> build can take 2.5 hours. I wanted to test a few CLI settings before creating
> an additional GitHub CI build workflow which can be run on demand and always
> runs all tests in all modules (ignoring errors and failures), no matter what.
> In the end, it is supposed to create a single-file aggregate HTML report
> which can easily be attached to the build and later is available for
> download, if the user so chooses in order to analyse failing tests
> comfortable and without having to scroll through build logs. You get the
> picture, I guess. In the original project, there is a pom-packaged root POM,
> so the problem described in this issue does not occur there. I simply created
> a single-module dummy project in order to verify the effect of certain build
> options quickly and not having to wait for the slow original build to finish.
> Eventually, I noticed the issue described above.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2004) Empty report for single-module project with 'aggregate=true'
[
https://issues.apache.org/jira/browse/SUREFIRE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516282#comment-17516282
]
Tibor Digana commented on SUREFIRE-2004:
[~kriegaex]
I do not expect your feedback. It is opposite :-)
We will give you our feedback.
Last days I have assigned several issues to the backlog as they suddenly
appeared during the release Vote 3.0.0-M6 but they are not related to this
release Vote. We only do not want to forget these issues, and we will have a
chance to have a look at them during the next development iteration.
> Empty report for single-module project with 'aggregate=true'
>
>
> Key: SUREFIRE-2004
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2004
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.4, 3.0.0-M5
>Reporter: Alexander Kriegisch
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Using either {{-Daggregate=true}} on CLI or {{true}}
> in the plugin configuration leads to an empty report (i.e. zero tests
> reported) when e.g. executing
> {code:none}
> mvn -Dmaven.test.failure.ignore=true -Daggregate=true clean verify
> surefire-report:report-only
> {code}
> in the context of a single-module project. As soon as I make the root module
> pom-packaged and move the tests to into a child module, the aggregate report
> works.
> FYI, if I do not define the plugin and its version in my POM at all, the
> default version 2.4 used by Maven on my workstation has the same problem, so
> this does not seem to be a 3.0.0-M5 issue only.
>
> Background info about how and why I actually stumbled across this problem: I
> have an OSS multi-module project with lots of expensive UI tests. The full
> build can take 2.5 hours. I wanted to test a few CLI settings before creating
> an additional GitHub CI build workflow which can be run on demand and always
> runs all tests in all modules (ignoring errors and failures), no matter what.
> In the end, it is supposed to create a single-file aggregate HTML report
> which can easily be attached to the build and later is available for
> download, if the user so chooses in order to analyse failing tests
> comfortable and without having to scroll through build logs. You get the
> picture, I guess. In the original project, there is a pom-packaged root POM,
> so the problem described in this issue does not occur there. I simply created
> a single-module dummy project in order to verify the effect of certain build
> options quickly and not having to wait for the slow original build to finish.
> Eventually, I noticed the issue described above.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-parent] slawekjaranowski commented on pull request #55: execute checkstyle in early phase of the build
slawekjaranowski commented on pull request #55: URL: https://github.com/apache/maven-parent/pull/55#issuecomment-1086626819 https://issues.apache.org/jira/browse/MPOM-313 -- 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] (MPOM-313) Execute checkstyle in early phase of the build
[ https://issues.apache.org/jira/browse/MPOM-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MPOM-313: - Fix Version/s: MAVEN-36 > Execute checkstyle in early phase of the build > -- > > Key: MPOM-313 > URL: https://issues.apache.org/jira/browse/MPOM-313 > Project: Maven POMs > Issue Type: Improvement > Components: maven >Reporter: Slawomir Jaranowski >Priority: Major > Fix For: MAVEN-36 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MPOM-313) Execute checkstyle in early phase of the build
Slawomir Jaranowski created MPOM-313: Summary: Execute checkstyle in early phase of the build Key: MPOM-313 URL: https://issues.apache.org/jira/browse/MPOM-313 Project: Maven POMs Issue Type: Improvement Components: maven Reporter: Slawomir Jaranowski -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-parent] olamy commented on pull request #55: execute checkstyle in early phase of the build
olamy commented on pull request #55: URL: https://github.com/apache/maven-parent/pull/55#issuecomment-1086624006 > Simple change - can save some of time during development. Are there any objection before process it? not from me 藍 -- 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-7449) [REGRESSION] StringVisitorModelInterpolator NullPointerException
[
https://issues.apache.org/jira/browse/MNG-7449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516277#comment-17516277
]
Hudson commented on MNG-7449:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven-site » PR-287 #24
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-site/job/PR-287/24/
> [REGRESSION] StringVisitorModelInterpolator NullPointerException
>
>
> Key: MNG-7449
> URL: https://issues.apache.org/jira/browse/MNG-7449
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.8.5
>Reporter: Ronnie de Lang
>Priority: Major
>
> Since Maven 3.8.5 our own custom Maven plugin is failing with a
> NullPointerException when trying to interpolate Maven properties in a Maven
> model.
> Code:
> {code:java}
> StringVisitorModelInterpolator interpolator = new
> StringVisitorModelInterpolator();
> interpolated = interpolator.interpolateModel(model, null, new
> DefaultModelBuildingRequest(), new ModelProblemCollector() {
> @Override
> public void add(ModelProblemCollectorRequest
> modelProblemCollectorRequest) {
> problems.add(modelProblemCollectorRequest);
> }
> }); {code}
> Stacktrace:
> {code:java}
> [ERROR] Failed to execute goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> (default) on project DNL_PMDM_HelloYou: Execution default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.: NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> (default) on project DNL_PMDM_HelloYou: Execution default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:306)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:121)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:127)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default of goal
> nl.ing.cis.tools.deploy:deploy-configuration-maven-plugin:5.2.0:flatten
> failed.
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:148)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:301)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:211)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:165)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:121)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
>
[GitHub] [maven-parent] slawekjaranowski commented on pull request #55: execute checkstyle in early phase of the build
slawekjaranowski commented on pull request #55: URL: https://github.com/apache/maven-parent/pull/55#issuecomment-1086621849 Simple change - can save some of time during development. Are there any objection before process it? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MPOM-311) Upgrade Maven JXR Plugin from 3.1.1 to 3.2.0
[ https://issues.apache.org/jira/browse/MPOM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MPOM-311. Assignee: Slawomir Jaranowski Resolution: Fixed > Upgrade Maven JXR Plugin from 3.1.1 to 3.2.0 > > > Key: MPOM-311 > URL: https://issues.apache.org/jira/browse/MPOM-311 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: maven >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: MAVEN-36 > > > h1. Release Notes - Maven JXR - Version 3.2.0 > h2. Bug > * [JXR-164] - Full path to local code sources in page title > h2. Task > * [JXR-162] - Lift Minimum Java to Java 8 > h2. Dependency upgrade > * [JXR-157] - Upgrade Velocity templating engine > * [JXR-163] - Require Maven 3.2.5+ > * [JXR-165] - Upgrade Maven Reporting to 3.1.0 > * [JXR-167] - Upgrade Parent to 35 > * [JXR-168] - Dependency upgrade and cleanup -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-parent] slawekjaranowski merged pull request #60: Bump maven-jxr-plugin from 3.1.1 to 3.2.0
slawekjaranowski merged pull request #60: URL: https://github.com/apache/maven-parent/pull/60 -- 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] (MPOM-309) Upgrade TagList Maven Plugin from 2.4 to 3.0.0
[ https://issues.apache.org/jira/browse/MPOM-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MPOM-309. Assignee: Slawomir Jaranowski Resolution: Fixed > Upgrade TagList Maven Plugin from 2.4 to 3.0.0 > -- > > Key: MPOM-309 > URL: https://issues.apache.org/jira/browse/MPOM-309 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: maven >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: MAVEN-36 > > > Release notes: > [https://github.com/mojohaus/taglist-maven-plugin/releases/tag/taglist-maven-plugin-3.0.0] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-parent] slawekjaranowski merged pull request #45: Bump taglist-maven-plugin from 2.4 to 3.0.0
slawekjaranowski merged pull request #45: URL: https://github.com/apache/maven-parent/pull/45 -- 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] (MPOM-312) Upgrade Maven Shade Plugin from 3.2.4 to 3.3.0
[ https://issues.apache.org/jira/browse/MPOM-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MPOM-312. Resolution: Fixed > Upgrade Maven Shade Plugin from 3.2.4 to 3.3.0 > -- > > Key: MPOM-312 > URL: https://issues.apache.org/jira/browse/MPOM-312 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: ASF-26 > > > h1. Release Notes - Maven Shade Plugin - Version 3.3.0 > h2. Bug > * [MSHADE-252] - shadeSourcesContent is broken when combined with partial > relocation > * [MSHADE-396] - Improve SourceContent Shading > h2. New Feature > * [MSHADE-36] - Add option to include dependency reduced POM instead of > original one > h2. Improvement > * [MSHADE-321] - Always respect 'createDependencyReducedPom' flag > * [MSHADE-371] - Update Shade Apache[Notice/LICENSE]ResourceTransformer > to use also [NOTICE/LICENSE].md > * [MSHADE-373] - Source transformation on source jar can break OSGi > resolution due to duplicated bundle name > * [MSHADE-382] - Add an option to skip execution > * [MSHADE-391] - Do not modify class files, if nothing was relocated > * [MSHADE-405] - ShowOverlapping Uses http instead of https > h2. Task > * [MSHADE-389] - Get rid of old baggage > * [MSHADE-390] - Implement Sisu index transformer > * [MSHADE-401] - Improve ServiceResourceTransformer > * [MSHADE-412] - SimpleRelocator can fail in NPE, in particular with > manifest transformer > h2. Dependency upgrade > * [MSHADE-379] - Support Java 16 - upgrade ASM to 9.0 > * [MSHADE-386] - Update JDependency to 2.6.0 > * [MSHADE-407] - Update ASM to 9.2 to support Java 17 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-apache-parent] slawekjaranowski merged pull request #75: Bump maven-shade-plugin from 3.2.4 to 3.3.0
slawekjaranowski merged pull request #75: URL: https://github.com/apache/maven-apache-parent/pull/75 -- 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] (MPOM-312) Upgrade Maven Shade Plugin from 3.2.4 to 3.3.0
[ https://issues.apache.org/jira/browse/MPOM-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MPOM-312: - Summary: Upgrade Maven Shade Plugin from 3.2.4 to 3.3.0 (was: Update Maven Shade Plugin from 3.2.4 to 3.3.0) > Upgrade Maven Shade Plugin from 3.2.4 to 3.3.0 > -- > > Key: MPOM-312 > URL: https://issues.apache.org/jira/browse/MPOM-312 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: ASF-26 > > > h1. Release Notes - Maven Shade Plugin - Version 3.3.0 > h2. Bug > * [MSHADE-252] - shadeSourcesContent is broken when combined with partial > relocation > * [MSHADE-396] - Improve SourceContent Shading > h2. New Feature > * [MSHADE-36] - Add option to include dependency reduced POM instead of > original one > h2. Improvement > * [MSHADE-321] - Always respect 'createDependencyReducedPom' flag > * [MSHADE-371] - Update Shade Apache[Notice/LICENSE]ResourceTransformer > to use also [NOTICE/LICENSE].md > * [MSHADE-373] - Source transformation on source jar can break OSGi > resolution due to duplicated bundle name > * [MSHADE-382] - Add an option to skip execution > * [MSHADE-391] - Do not modify class files, if nothing was relocated > * [MSHADE-405] - ShowOverlapping Uses http instead of https > h2. Task > * [MSHADE-389] - Get rid of old baggage > * [MSHADE-390] - Implement Sisu index transformer > * [MSHADE-401] - Improve ServiceResourceTransformer > * [MSHADE-412] - SimpleRelocator can fail in NPE, in particular with > manifest transformer > h2. Dependency upgrade > * [MSHADE-379] - Support Java 16 - upgrade ASM to 9.0 > * [MSHADE-386] - Update JDependency to 2.6.0 > * [MSHADE-407] - Update ASM to 9.2 to support Java 17 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MPOM-312) Update Maven Shade Plugin from 3.2.4 to 3.3.0
Slawomir Jaranowski created MPOM-312: Summary: Update Maven Shade Plugin from 3.2.4 to 3.3.0 Key: MPOM-312 URL: https://issues.apache.org/jira/browse/MPOM-312 Project: Maven POMs Issue Type: Dependency upgrade Components: asf Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: ASF-26 h1. Release Notes - Maven Shade Plugin - Version 3.3.0 h2. Bug * [MSHADE-252] - shadeSourcesContent is broken when combined with partial relocation * [MSHADE-396] - Improve SourceContent Shading h2. New Feature * [MSHADE-36] - Add option to include dependency reduced POM instead of original one h2. Improvement * [MSHADE-321] - Always respect 'createDependencyReducedPom' flag * [MSHADE-371] - Update Shade Apache[Notice/LICENSE]ResourceTransformer to use also [NOTICE/LICENSE].md * [MSHADE-373] - Source transformation on source jar can break OSGi resolution due to duplicated bundle name * [MSHADE-382] - Add an option to skip execution * [MSHADE-391] - Do not modify class files, if nothing was relocated * [MSHADE-405] - ShowOverlapping Uses http instead of https h2. Task * [MSHADE-389] - Get rid of old baggage * [MSHADE-390] - Implement Sisu index transformer * [MSHADE-401] - Improve ServiceResourceTransformer * [MSHADE-412] - SimpleRelocator can fail in NPE, in particular with manifest transformer h2. Dependency upgrade * [MSHADE-379] - Support Java 16 - upgrade ASM to 9.0 * [MSHADE-386] - Update JDependency to 2.6.0 * [MSHADE-407] - Update ASM to 9.2 to support Java 17 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-apache-parent] slawekjaranowski merged pull request #74: Bump maven-compiler-plugin from 3.10.0 to 3.10.1
slawekjaranowski merged pull request #74: URL: https://github.com/apache/maven-apache-parent/pull/74 -- 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] (MPOM-306) Upgrade Maven Compiler Plugin from 3.10.0 to 3.10.1
[ https://issues.apache.org/jira/browse/MPOM-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MPOM-306. Assignee: Slawomir Jaranowski Resolution: Fixed > Upgrade Maven Compiler Plugin from 3.10.0 to 3.10.1 > --- > > Key: MPOM-306 > URL: https://issues.apache.org/jira/browse/MPOM-306 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: ASF-26 > > > h1. Release Notes - Maven Compiler Plugin - Version 3.10.1 > h2. Bug > * [MCOMPILER-346] - workaround to jdk bug: assertionError inside javac > when using javax.tools API > * [MCOMPILER-485] - Incorrect internal string format in generated > package-info.class files on Windows > h2. New Feature > * [MCOMPILER-426] - dedicated option for enabling preview feature -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (MPOM-307) Upgrade Maven Dependency Plugin from 3.2.0 to 3.3.0
[ https://issues.apache.org/jira/browse/MPOM-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MPOM-307. Assignee: Slawomir Jaranowski Resolution: Fixed > Upgrade Maven Dependency Plugin from 3.2.0 to 3.3.0 > --- > > Key: MPOM-307 > URL: https://issues.apache.org/jira/browse/MPOM-307 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: ASF-26 > > > h1. Release Notes - Maven Dependency Plugin - Version 3.3.0 > h2. Bug > * [MDEP-679] - mvn dependency:analyze detected wrong transitive dependency > * [MDEP-742] - dependency plugin does not work with JDK 16 > * [MDEP-752] - skip dependency analyze in ear packaging > * [MDEP-753] - Non-test dependency reported as Non-test scoped test only > dependency > * [MDEP-759] - 'Dependency not found' with 3.2.0 and Java-17 while > analyzing > * [MDEP-761] - Tree plugin does not terminate with 3.2.0 > * [MDEP-769] - Minor improvement - continue > * [MDEP-774] - analyze-only failed: PermittedSubclasses requires ASM9 > * [MDEP-781] - Broken Link to "Introduction to Dependency Mechanism Page" > * [MDEP-783] - TreeMojo docs say scope doesn't work due to MSHARED-4 > * [MDEP-786] - Sealed classes not supported > h2. New Feature > * [MDEP-787] - Allow ignoring non-test-scoped dependencies > h2. Improvement > * [MDEP-763] - Minor improvements > * [MDEP-768] - GitHub Action build improvement > * [MDEP-779] - dependency:analyze should list the classes that cause a > used undeclared dependency > * [MDEP-789] - Improve documentation of analyze - Non-test scoped > h2. Task > * [MDEP-760] - Java 1.8 as minimum > h2. Dependency upgrade > * [MDEP-766] - Upgrade maven-invoker-plugin to version 3.2.2 > * [MDEP-784] - Upgrade maven-dependency-analyzer to 1.12.0 > * [MDEP-788] - Upgrade maven-reporting-impl to version 3.1.0 > * [MDEP-795] - Update Jetty to 9.4.45.v20220203 > * [MDEP-796] - Upgrade Maven Parent to 35 > * [MDEP-797] - Update transitive dependency commons-beanutils to 1.9.4 > * [MDEP-798] - Upgrade maven-dependency-tree from 3.0.1 to 3.1.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-apache-parent] slawekjaranowski merged pull request #73: Bump maven-dependency-plugin from 3.2.0 to 3.3.0
slawekjaranowski merged pull request #73: URL: https://github.com/apache/maven-apache-parent/pull/73 -- 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] (MPOM-304) Upgrade Maven Project Info Reports Plugin from 3.1.2 to 3.2.2
[ https://issues.apache.org/jira/browse/MPOM-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MPOM-304. Assignee: Slawomir Jaranowski Resolution: Fixed > Upgrade Maven Project Info Reports Plugin from 3.1.2 to 3.2.2 > - > > Key: MPOM-304 > URL: https://issues.apache.org/jira/browse/MPOM-304 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: ASF-26 > > > h1. Release Notes - Maven Project Info Reports Plugin - Version 3.2.1 > h2. Bug > * [MPIR-403] - Travis link should point to travis-ci.com instead of > travis-ci.org > * [MPIR-404] - Warn and accept invalid mailing list links > * [MPIR-405] - Regression in Maven site rendering due to Doxia change to > HTML5 > * [MPIR-412] - Dependency report generates non-well-formed output if the > POM of a depdendency cannot be parsed > h2. Improvement > * [MPIR-408] - Add some i18n properties for zh_CH > h2. Dependency upgrade > * [MPIR-409] - Upgrade Maven Site Plugin to 3.10.0 > * [MPIR-410] - Upgrade Maven SCM to 1.12.2 > * [MPIR-411] - Upgrade Doxia to 1.11.1 and Doxia Sitetools to 1.11.1 > h1. Release Notes - Maven Project Info Reports Plugin - Version 3.2.2 > h2. Bug > * [MPIR-413] - Plugin repositories defined in project are not used by > plugin-management report > h2. Dependency upgrade > * [MPIR-414] - Upgrade Maven Reporting API/Impl to 3.1.0 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-apache-parent] slawekjaranowski merged pull request #71: Bump maven-project-info-reports-plugin from 3.1.2 to 3.2.2
slawekjaranowski merged pull request #71: URL: https://github.com/apache/maven-apache-parent/pull/71 -- 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-apache-parent] slawekjaranowski closed pull request #61: [MPOM-286] org.apache:apache should conform with needed Sonatype checksums on deployment
slawekjaranowski closed pull request #61: URL: https://github.com/apache/maven-apache-parent/pull/61 -- 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] [Assigned] (MPOM-305) Set minimum enforced Maven version to 3.2.5
[ https://issues.apache.org/jira/browse/MPOM-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski reassigned MPOM-305: Assignee: Slawomir Jaranowski > Set minimum enforced Maven version to 3.2.5 > --- > > Key: MPOM-305 > URL: https://issues.apache.org/jira/browse/MPOM-305 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: ASF-26 > > > Used plugins required Maven 3.2.5 > - maven-compiler-plugin from 3.9.0 > - maven-plugin-plugin from 3.6.4 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-integration-testing] kwin commented on a change in pull request #143: [MNG-5222] IT test - warn about deprecated plugin params
kwin commented on a change in pull request #143: URL: https://github.com/apache/maven-integration-testing/pull/143#discussion_r841047805 ## File path: core-it-suite/src/test/java/org/apache/maven/it/IntegrationTestSuite.java ## @@ -190,6 +190,7 @@ public static Test suite() suite.addTestSuite( MavenITmng5280SettingsProfilesRepositoriesOrderTest.class ); suite.addTestSuite( MavenITmng5230MakeReactorWithExcludesTest.class ); suite.addTestSuite( MavenITmng5224InjectedSettings.class ); +suite.addTestSuite( MavenITmng5222MojoDeprectaeParamsTest.class ); Review comment: ...MojoDeprecatedParamsTest.class -- 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] (MRELEASE-955) Document how to work with release profile in 3.x vs 2.x
[
https://issues.apache.org/jira/browse/MRELEASE-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516251#comment-17516251
]
Hudson commented on MRELEASE-955:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven-release » master #8
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-release/job/master/8/
> Document how to work with release profile in 3.x vs 2.x
> ---
>
> Key: MRELEASE-955
> URL: https://issues.apache.org/jira/browse/MRELEASE-955
> Project: Maven Release Plugin
> Issue Type: Task
> Components: documentation
>Affects Versions: 3.0.0-M1, 3.0.0-M5
> Environment: n/a
>Reporter: Anders Hammar
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> In v3.0.0 of the plugin, the {{useReleaseProfile}} parameter has been
> deprecated *and default value changed to {{false}}*.
> This effectively changes from convention over configuration with a default
> release profile (the {{release-profile}} profile in the super-POM) so that
> the end user now needs:
> 1. to create a release profile (with his own naming choice)
> 2. and configure the plugin to use it (like add
> {{-Pname_of_the_release_profile ...}}).
> We need to document this change in behavior as well as describe best-practice
> for handling this.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MRELEASE-955) Document how to work with release profile in 3.x vs 2.x
[
https://issues.apache.org/jira/browse/MRELEASE-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MRELEASE-955:
---
Description:
In v3.0.0 of the plugin, the {{useReleaseProfile}} parameter has been
deprecated *and default value changed to {{false}}*.
This effectively changes from convention over configuration with a default
release profile (the {{release-profile}} profile in the super-POM) so that the
end user now needs:
1. to create a release profile (with his own naming choice)
2. and configure the plugin to use it (like add
{{-Pname_of_the_release_profile ...}}).
We need to document this change in behavior as well as describe best-practice
for handling this.
was:
In v3.0.0, of the plugin the {{useReleaseProfile}} parameter has been
deprecated *and default value changed to {{false}}*.
This effectively changes from convention over configuration with a default
release profile (the {{release-profile}} profile in the super-POM) so that the
end user now needs:
1. to create a release profile (with his own naming choice)
2. and configure the plugin to use it (like add
{{-Pname_of_the_release_profile ...}}).
We need to document this change in behavior as well as describe best-practice
for handling this.
> Document how to work with release profile in 3.x vs 2.x
> ---
>
> Key: MRELEASE-955
> URL: https://issues.apache.org/jira/browse/MRELEASE-955
> Project: Maven Release Plugin
> Issue Type: Task
> Components: documentation
>Affects Versions: 3.0.0-M1, 3.0.0-M5
> Environment: n/a
>Reporter: Anders Hammar
>Priority: Major
> Fix For: 3.0.0-M6
>
>
> In v3.0.0 of the plugin, the {{useReleaseProfile}} parameter has been
> deprecated *and default value changed to {{false}}*.
> This effectively changes from convention over configuration with a default
> release profile (the {{release-profile}} profile in the super-POM) so that
> the end user now needs:
> 1. to create a release profile (with his own naming choice)
> 2. and configure the plugin to use it (like add
> {{-Pname_of_the_release_profile ...}}).
> We need to document this change in behavior as well as describe best-practice
> for handling this.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
