[GitHub] [maven-jlink-plugin] dependabot[bot] opened a new pull request #44: Bump mockito-core from 3.8.0 to 3.9.0
dependabot[bot] opened a new pull request #44: URL: https://github.com/apache/maven-jlink-plugin/pull/44 Bumps [mockito-core](https://github.com/mockito/mockito) from 3.8.0 to 3.9.0. Release notes Sourced from https://github.com/mockito/mockito/releases;>mockito-core's releases. v3.9.0 Changelog generated by https://github.com/shipkit/shipkit-changelog;>Shipkit Changelog Gradle Plugin 3.9.0 2021-04-07 - https://github.com/mockito/mockito/compare/v3.8.22...v3.9.0;>4 commit(s) by Tim van der Lippe, dependabot[bot] But invoked here lists the invocation parameters [(https://github-redirect.dependabot.com/mockito/mockito/issues/2259;>#2259)](https://github-redirect.dependabot.com/mockito/mockito/pull/2259;>mockito/mockito#2259) Bump auto-service from 1.0-rc7 to 1.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2258;>#2258)](https://github-redirect.dependabot.com/mockito/mockito/pull/2258;>mockito/mockito#2258) Bump actions/setup-java from v1 to v2 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2255;>#2255)](https://github-redirect.dependabot.com/mockito/mockito/pull/2255;>mockito/mockito#2255) But invoked here should list the invocation parameters [(https://github-redirect.dependabot.com/mockito/mockito/issues/2058;>#2058)](https://github-redirect.dependabot.com/mockito/mockito/issues/2058;>mockito/mockito#2058) v3.8.25 Changelog generated by https://github.com/shipkit/shipkit-changelog;>Shipkit Changelog Gradle Plugin 3.8.25 2021-04-07 - https://github.com/mockito/mockito/compare/v3.8.22...v3.8.25;>3 commit(s) by Tim van der Lippe, dependabot[bot] But invoked here lists the invocation parameters [(https://github-redirect.dependabot.com/mockito/mockito/issues/2259;>#2259)](https://github-redirect.dependabot.com/mockito/mockito/pull/2259;>mockito/mockito#2259) Bump auto-service from 1.0-rc7 to 1.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2258;>#2258)](https://github-redirect.dependabot.com/mockito/mockito/pull/2258;>mockito/mockito#2258) Bump actions/setup-java from v1 to v2 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2255;>#2255)](https://github-redirect.dependabot.com/mockito/mockito/pull/2255;>mockito/mockito#2255) But invoked here should list the invocation parameters [(https://github-redirect.dependabot.com/mockito/mockito/issues/2058;>#2058)](https://github-redirect.dependabot.com/mockito/mockito/issues/2058;>mockito/mockito#2058) v3.8.22 Changelog generated by https://github.com/shipkit/shipkit-changelog;>Shipkit Changelog Gradle Plugin 3.8.22 2021-04-05 - https://github.com/mockito/mockito/compare/v3.8.20...v3.8.22;>2 commit(s) by Tim van der Lippe Fix thread race condition [(https://github-redirect.dependabot.com/mockito/mockito/issues/2248;>#2248)](https://github-redirect.dependabot.com/mockito/mockito/pull/2248;>mockito/mockito#2248) Add missing Deprecated annotation [(https://github-redirect.dependabot.com/mockito/mockito/issues/2227;>#2227)](https://github-redirect.dependabot.com/mockito/mockito/pull/2227;>mockito/mockito#2227) v3.8.21 Changelog generated by https://github.com/shipkit/shipkit-changelog;>Shipkit Changelog Gradle Plugin 3.8.21 2021-04-05 - https://github.com/mockito/mockito/compare/v3.8.20...v3.8.21;>1 commit(s) by Tim van der Lippe Add missing Deprecated annotation [(https://github-redirect.dependabot.com/mockito/mockito/issues/2227;>#2227)](https://github-redirect.dependabot.com/mockito/mockito/pull/2227;>mockito/mockito#2227) v3.8.20 Changelog generated by https://github.com/shipkit/shipkit-changelog;>Shipkit Changelog Gradle Plugin 3.8.20 2021-04-01 - https://github.com/mockito/mockito/compare/v3.8.17...v3.8.20;>3 commit(s) by Paul Klauser, dependabot[bot] Bump google-java-format from 1.9 to 1.10.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2251;>#2251)](https://github-redirect.dependabot.com/mockito/mockito/pull/2251;>mockito/mockito#2251) Bump versions.errorprone from 2.5.1 to 2.6.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2250;>#2250)](https://github-redirect.dependabot.com/mockito/mockito/pull/2250;>mockito/mockito#2250) Fixes https://github-redirect.dependabot.com/mockito/mockito/issues/2007;>#2007 : Update objenesis dep to 3.2 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2249;>#2249)](https://github-redirect.dependabot.com/mockito/mockito/pull/2249;>mockito/mockito#2249) Fixes https://github-redirect.dependabot.com/mockito/mockito/issues/2007;>#2007 : Downgrade objenesis version for mockito-android [(https://github-redirect.dependabot.com/mockito/mockito/issues/2024;>#2024)](https://github-redirect.dependabot.com/mockito/mockito/pull/2024;>mockito/mockito#2024) Android instrumentation test packaging fails for mockito-android 3.5.0 with minSdk 26
[GitHub] [maven-doxia-converter] dependabot[bot] opened a new pull request #10: Bump icu4j from 67.1 to 69.1
dependabot[bot] opened a new pull request #10: URL: https://github.com/apache/maven-doxia-converter/pull/10 Bumps [icu4j](https://github.com/unicode-org/icu) from 67.1 to 69.1. Release notes Sourced from https://github.com/unicode-org/icu/releases;>icu4j's releases. ICU 69.1 We are pleased to announce the release of Unicode® ICU 69. ICU 69 updates to http://cldr.unicode.org/index/downloads/cldr-39;>CLDR 39 locale data with many additions and corrections. ICU 69 also includes significant improvements for measurement unit formatting and number formatting in general, as well as many other bug fixes and enhancements. For details, please see http://site.icu-project.org/download/69;>http://site.icu-project.org/download/69 The API reference documents will be published at the following location: https://unicode-org.github.io/icu-docs/;>https://unicode-org.github.io/icu-docs/ Note: The prebuilt WinARM64 binaries below should be considered alpha/experimental. ICU 69 RC We are pleased to announce the release candidate for Unicode® ICU 69. ICU 69 updates to http://cldr.unicode.org/index/downloads/cldr-39;>CLDR 39 locale data with many additions and corrections. ICU 69 also includes significant improvements for measurement unit formatting and number formatting in general, as well as many other bug fixes and enhancements. For details please see http://site.icu-project.org/download/69;>http://site.icu-project.org/download/69 Please test this release candidate on your platforms and report bugs and regressions by Tuesday, 2021-apr-06, via the http://site.icu-project.org/contacts;>icu-support mailing list, and/or please http://site.icu-project.org/bugs;>find/submit error reports. Please do not use this release candidate in production. The release candidate API reference documents are published on https://unicode-org.github.io/icu-docs/;>https://unicode-org.github.io/icu-docs/ – follow the “Dev” links there. Note: The prebuilt WinARM64 binaries below should be considered alpha/experimental. ICU 68.2 We are pleased to announce the release of Unicode® ICU 68. ICU 68 updates to http://cldr.unicode.org/index/downloads/cldr-38;>CLDR 38 locale data with many additions and corrections. ICU 68 brings major improvements and API additions for measurement unit formatting, implements locale ID canonicalization conformant with CLDR, and includes many other bug fixes and enhancements. This 68.2 maintenance release adds some bug fixes from CLDR 38.1 and for some issues in the ICU code. For details please see http://site.icu-project.org/download/68;>http://site.icu-project.org/download/68 The API reference documents are published at the following location: https://unicode-org.github.io/icu-docs/;>https://unicode-org.github.io/icu-docs/ (No changes/updates for 68.2.) Note: The prebuilt WinARM64 binaries below should be considered alpha/experimental. ICU 68.1 We are pleased to announce the release of Unicode® ICU 68. ICU 68 updates to http://cldr.unicode.org/index/downloads/cldr-38;>CLDR 38 locale data with many additions and corrections. ICU 68 brings major improvements and API additions for measurement unit formatting, implements locale ID canonicalization conformant with CLDR, and includes many other bug fixes and enhancements. For details please see http://site.icu-project.org/download/68;>http://site.icu-project.org/download/68 The API reference documents will be published at the following location: https://unicode-org.github.io/icu-docs/;>https://unicode-org.github.io/icu-docs/ ... (truncated) Commits See full diff in https://github.com/unicode-org/icu/commits;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot
[jira] [Commented] (MNG-7128) improve error message when blocked repository defined in build POM
[ https://issues.apache.org/jira/browse/MNG-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316792#comment-17316792 ] Hudson commented on MNG-7128: - Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #19 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/19/ > improve error message when blocked repository defined in build POM > -- > > Key: MNG-7128 > URL: https://issues.apache.org/jira/browse/MNG-7128 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Maarten Mulders >Assignee: Herve Boutemy >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.1 > > > MRESOLVER-166 brings an enhanced message when the blocked repository comes > from a dependency > But when blocked repository is defined in build pom.xml, there is not > dedidated message: user has to guess that "Downloading from > maven-default-http-blocker: [http://0.0.0.0/]...; comes from such a case > > The download is not blocked as expected before even trying to download, but > the download fails because this is the intent of the chosen > [http://0.0.0.0|http://0.0.0.0/] url... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316793#comment-17316793 ] Hudson commented on MNG-7045: - Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #19 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/19/ > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Labels: up-for-grabs > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7112) --projects flag should honor --non-recursive flag
[
https://issues.apache.org/jira/browse/MNG-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316794#comment-17316794
]
Hudson commented on MNG-7112:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #19
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/19/
> --projects flag should honor --non-recursive flag
> -
>
> Key: MNG-7112
> URL: https://issues.apache.org/jira/browse/MNG-7112
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and workspace
>Affects Versions: 4.0.x-candidate
>Reporter: Martin Kanters
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> In MNG-6981 and MNG-7102 the behavior around selecting aggregate projects has
> changed.
> Now, when an aggregate is (de)selected, the aggregate project and all its
> children will be (de)selected in the reactor.
> Before, just the aggregate was (de)selected and children were not taken into
> account.
> Because there is no good workaround currently and there is a need for it, we
> should offer a way to bring the old behavior back.
> {{\-N}} or {{\--non-recursive}} is currently used to only select one project,
> and it will not take its children into account during project collection
> (before the reactor flags are applied).
> After discussion on the mailing list, the proposed implementation is to use
> {{\--non-recursive}} together with {{\--projects}} to restore the old
> non-recursive behavior we had before.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316791#comment-17316791
]
Hudson commented on MNG-6511:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #19
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/19/
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6075) Increase the model validation level to the next minor level version
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316790#comment-17316790 ] Hudson commented on MNG-6075: - Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #19 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/19/ > Increase the model validation level to the next minor level version > --- > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Critical > Fix For: 4.0.0, 4.0.0-alpha-1 > > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #343: SUREFIRE-1881 Adds additional debug log and fork connection timeout
Tibor17 edited a comment on pull request #343: URL: https://github.com/apache/maven-surefire/pull/343#issuecomment-815055226 The interprocess comunication between Maven process and Surefire process can be two: 1. process pipes (System.in, System.out see in the Surefire JVM) 2. the TCP connection in Surefire JVM which leaves (1) not used by default in 3.0.0 Therefore I recomended to used the `` which uses the TCP. There are two classes, `legacy` and `surefire` fork node factory. In the future we are aiming for the TCP as default factory, calling it `SurefireForkNodeFactory`. The `LegacyForkNodeFactory` uses the process pipes. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #343: SUREFIRE-1881 Adds additional debug log and fork connection timeout
Tibor17 edited a comment on pull request #343: URL: https://github.com/apache/maven-surefire/pull/343#issuecomment-815055226 The interprocess comunication between Maven process and Surefire process can be two: 1. process pipes (System.in, System.out see in the Surefire JVM) 2. the TCP connection in Surefire JVM which leaves (1) not used by default Therefore I recomended to used the `` which uses the TCP. There are two classes, `legacy` and `surefire` fork node factory. In the future we are aiming for the TCP as default factory, calling it `SurefireForkNodeFactory`. The `LegacyForkNodeFactory` uses the process pipes. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316777#comment-17316777 ] Hudson commented on MNG-7045: - Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #19 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/19/ > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Labels: up-for-grabs > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316775#comment-17316775
]
Hudson commented on MNG-6511:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #19
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/19/
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7112) --projects flag should honor --non-recursive flag
[
https://issues.apache.org/jira/browse/MNG-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316778#comment-17316778
]
Hudson commented on MNG-7112:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #19
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/19/
> --projects flag should honor --non-recursive flag
> -
>
> Key: MNG-7112
> URL: https://issues.apache.org/jira/browse/MNG-7112
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and workspace
>Affects Versions: 4.0.x-candidate
>Reporter: Martin Kanters
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> In MNG-6981 and MNG-7102 the behavior around selecting aggregate projects has
> changed.
> Now, when an aggregate is (de)selected, the aggregate project and all its
> children will be (de)selected in the reactor.
> Before, just the aggregate was (de)selected and children were not taken into
> account.
> Because there is no good workaround currently and there is a need for it, we
> should offer a way to bring the old behavior back.
> {{\-N}} or {{\--non-recursive}} is currently used to only select one project,
> and it will not take its children into account during project collection
> (before the reactor flags are applied).
> After discussion on the mailing list, the proposed implementation is to use
> {{\--non-recursive}} together with {{\--projects}} to restore the old
> non-recursive behavior we had before.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7128) improve error message when blocked repository defined in build POM
[ https://issues.apache.org/jira/browse/MNG-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316776#comment-17316776 ] Hudson commented on MNG-7128: - Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #19 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/19/ > improve error message when blocked repository defined in build POM > -- > > Key: MNG-7128 > URL: https://issues.apache.org/jira/browse/MNG-7128 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Maarten Mulders >Assignee: Herve Boutemy >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.1 > > > MRESOLVER-166 brings an enhanced message when the blocked repository comes > from a dependency > But when blocked repository is defined in build pom.xml, there is not > dedidated message: user has to guess that "Downloading from > maven-default-http-blocker: [http://0.0.0.0/]...; comes from such a case > > The download is not blocked as expected before even trying to download, but > the download fails because this is the intent of the chosen > [http://0.0.0.0|http://0.0.0.0/] url... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6075) Increase the model validation level to the next minor level version
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316774#comment-17316774 ] Hudson commented on MNG-6075: - Build unstable in Jenkins: Maven » Maven TLP » maven » REMOVE_DEPRECATED #19 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/REMOVE_DEPRECATED/19/ > Increase the model validation level to the next minor level version > --- > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Critical > Fix For: 4.0.0, 4.0.0-alpha-1 > > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7112) --projects flag should honor --non-recursive flag
[
https://issues.apache.org/jira/browse/MNG-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316770#comment-17316770
]
Hudson commented on MNG-7112:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6889 #19
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6889/19/
> --projects flag should honor --non-recursive flag
> -
>
> Key: MNG-7112
> URL: https://issues.apache.org/jira/browse/MNG-7112
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and workspace
>Affects Versions: 4.0.x-candidate
>Reporter: Martin Kanters
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> In MNG-6981 and MNG-7102 the behavior around selecting aggregate projects has
> changed.
> Now, when an aggregate is (de)selected, the aggregate project and all its
> children will be (de)selected in the reactor.
> Before, just the aggregate was (de)selected and children were not taken into
> account.
> Because there is no good workaround currently and there is a need for it, we
> should offer a way to bring the old behavior back.
> {{\-N}} or {{\--non-recursive}} is currently used to only select one project,
> and it will not take its children into account during project collection
> (before the reactor flags are applied).
> After discussion on the mailing list, the proposed implementation is to use
> {{\--non-recursive}} together with {{\--projects}} to restore the old
> non-recursive behavior we had before.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7128) improve error message when blocked repository defined in build POM
[ https://issues.apache.org/jira/browse/MNG-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316768#comment-17316768 ] Hudson commented on MNG-7128: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6889 #19 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6889/19/ > improve error message when blocked repository defined in build POM > -- > > Key: MNG-7128 > URL: https://issues.apache.org/jira/browse/MNG-7128 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Maarten Mulders >Assignee: Herve Boutemy >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.1 > > > MRESOLVER-166 brings an enhanced message when the blocked repository comes > from a dependency > But when blocked repository is defined in build pom.xml, there is not > dedidated message: user has to guess that "Downloading from > maven-default-http-blocker: [http://0.0.0.0/]...; comes from such a case > > The download is not blocked as expected before even trying to download, but > the download fails because this is the intent of the chosen > [http://0.0.0.0|http://0.0.0.0/] url... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316769#comment-17316769 ] Hudson commented on MNG-7045: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6889 #19 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6889/19/ > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Labels: up-for-grabs > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6075) Increase the model validation level to the next minor level version
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316766#comment-17316766 ] Hudson commented on MNG-6075: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6889 #19 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6889/19/ > Increase the model validation level to the next minor level version > --- > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Critical > Fix For: 4.0.0, 4.0.0-alpha-1 > > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316767#comment-17316767
]
Hudson commented on MNG-6511:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6889 #19
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6889/19/
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7112) --projects flag should honor --non-recursive flag
[
https://issues.apache.org/jira/browse/MNG-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316761#comment-17316761
]
Hudson commented on MNG-7112:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #19
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/19/
> --projects flag should honor --non-recursive flag
> -
>
> Key: MNG-7112
> URL: https://issues.apache.org/jira/browse/MNG-7112
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and workspace
>Affects Versions: 4.0.x-candidate
>Reporter: Martin Kanters
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> In MNG-6981 and MNG-7102 the behavior around selecting aggregate projects has
> changed.
> Now, when an aggregate is (de)selected, the aggregate project and all its
> children will be (de)selected in the reactor.
> Before, just the aggregate was (de)selected and children were not taken into
> account.
> Because there is no good workaround currently and there is a need for it, we
> should offer a way to bring the old behavior back.
> {{\-N}} or {{\--non-recursive}} is currently used to only select one project,
> and it will not take its children into account during project collection
> (before the reactor flags are applied).
> After discussion on the mailing list, the proposed implementation is to use
> {{\--non-recursive}} together with {{\--projects}} to restore the old
> non-recursive behavior we had before.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7128) improve error message when blocked repository defined in build POM
[ https://issues.apache.org/jira/browse/MNG-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316759#comment-17316759 ] Hudson commented on MNG-7128: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #19 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/19/ > improve error message when blocked repository defined in build POM > -- > > Key: MNG-7128 > URL: https://issues.apache.org/jira/browse/MNG-7128 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Maarten Mulders >Assignee: Herve Boutemy >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.1 > > > MRESOLVER-166 brings an enhanced message when the blocked repository comes > from a dependency > But when blocked repository is defined in build pom.xml, there is not > dedidated message: user has to guess that "Downloading from > maven-default-http-blocker: [http://0.0.0.0/]...; comes from such a case > > The download is not blocked as expected before even trying to download, but > the download fails because this is the intent of the chosen > [http://0.0.0.0|http://0.0.0.0/] url... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316758#comment-17316758
]
Hudson commented on MNG-6511:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #19
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/19/
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316760#comment-17316760 ] Hudson commented on MNG-7045: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #19 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/19/ > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Labels: up-for-grabs > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6075) Increase the model validation level to the next minor level version
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316757#comment-17316757 ] Hudson commented on MNG-6075: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #19 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/19/ > Increase the model validation level to the next minor level version > --- > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Critical > Fix For: 4.0.0, 4.0.0-alpha-1 > > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316749#comment-17316749 ] Hudson commented on MNG-7045: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6012-Missing-Profile-At-End #19 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/19/ > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Labels: up-for-grabs > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316747#comment-17316747
]
Hudson commented on MNG-6511:
-
Build unstable in Jenkins: Maven » Maven TLP » maven »
MNG-6012-Missing-Profile-At-End #19
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/19/
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7128) improve error message when blocked repository defined in build POM
[ https://issues.apache.org/jira/browse/MNG-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316748#comment-17316748 ] Hudson commented on MNG-7128: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6012-Missing-Profile-At-End #19 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/19/ > improve error message when blocked repository defined in build POM > -- > > Key: MNG-7128 > URL: https://issues.apache.org/jira/browse/MNG-7128 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Maarten Mulders >Assignee: Herve Boutemy >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.1 > > > MRESOLVER-166 brings an enhanced message when the blocked repository comes > from a dependency > But when blocked repository is defined in build pom.xml, there is not > dedidated message: user has to guess that "Downloading from > maven-default-http-blocker: [http://0.0.0.0/]...; comes from such a case > > The download is not blocked as expected before even trying to download, but > the download fails because this is the intent of the chosen > [http://0.0.0.0|http://0.0.0.0/] url... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7112) --projects flag should honor --non-recursive flag
[
https://issues.apache.org/jira/browse/MNG-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316750#comment-17316750
]
Hudson commented on MNG-7112:
-
Build unstable in Jenkins: Maven » Maven TLP » maven »
MNG-6012-Missing-Profile-At-End #19
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/19/
> --projects flag should honor --non-recursive flag
> -
>
> Key: MNG-7112
> URL: https://issues.apache.org/jira/browse/MNG-7112
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and workspace
>Affects Versions: 4.0.x-candidate
>Reporter: Martin Kanters
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> In MNG-6981 and MNG-7102 the behavior around selecting aggregate projects has
> changed.
> Now, when an aggregate is (de)selected, the aggregate project and all its
> children will be (de)selected in the reactor.
> Before, just the aggregate was (de)selected and children were not taken into
> account.
> Because there is no good workaround currently and there is a need for it, we
> should offer a way to bring the old behavior back.
> {{\-N}} or {{\--non-recursive}} is currently used to only select one project,
> and it will not take its children into account during project collection
> (before the reactor flags are applied).
> After discussion on the mailing list, the proposed implementation is to use
> {{\--non-recursive}} together with {{\--projects}} to restore the old
> non-recursive behavior we had before.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6075) Increase the model validation level to the next minor level version
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316746#comment-17316746 ] Hudson commented on MNG-6075: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6012-Missing-Profile-At-End #19 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/19/ > Increase the model validation level to the next minor level version > --- > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Critical > Fix For: 4.0.0, 4.0.0-alpha-1 > > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7128) improve error message when blocked repository defined in build POM
[ https://issues.apache.org/jira/browse/MNG-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316722#comment-17316722 ] Hudson commented on MNG-7128: - Build unstable in Jenkins: Maven » Maven TLP » maven » MRESOLVER-94 #19 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MRESOLVER-94/19/ > improve error message when blocked repository defined in build POM > -- > > Key: MNG-7128 > URL: https://issues.apache.org/jira/browse/MNG-7128 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Maarten Mulders >Assignee: Herve Boutemy >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.1 > > > MRESOLVER-166 brings an enhanced message when the blocked repository comes > from a dependency > But when blocked repository is defined in build pom.xml, there is not > dedidated message: user has to guess that "Downloading from > maven-default-http-blocker: [http://0.0.0.0/]...; comes from such a case > > The download is not blocked as expected before even trying to download, but > the download fails because this is the intent of the chosen > [http://0.0.0.0|http://0.0.0.0/] url... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7112) --projects flag should honor --non-recursive flag
[
https://issues.apache.org/jira/browse/MNG-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316724#comment-17316724
]
Hudson commented on MNG-7112:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MRESOLVER-94 #19
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MRESOLVER-94/19/
> --projects flag should honor --non-recursive flag
> -
>
> Key: MNG-7112
> URL: https://issues.apache.org/jira/browse/MNG-7112
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and workspace
>Affects Versions: 4.0.x-candidate
>Reporter: Martin Kanters
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> In MNG-6981 and MNG-7102 the behavior around selecting aggregate projects has
> changed.
> Now, when an aggregate is (de)selected, the aggregate project and all its
> children will be (de)selected in the reactor.
> Before, just the aggregate was (de)selected and children were not taken into
> account.
> Because there is no good workaround currently and there is a need for it, we
> should offer a way to bring the old behavior back.
> {{\-N}} or {{\--non-recursive}} is currently used to only select one project,
> and it will not take its children into account during project collection
> (before the reactor flags are applied).
> After discussion on the mailing list, the proposed implementation is to use
> {{\--non-recursive}} together with {{\--projects}} to restore the old
> non-recursive behavior we had before.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316721#comment-17316721
]
Hudson commented on MNG-6511:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MRESOLVER-94 #19
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MRESOLVER-94/19/
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316723#comment-17316723 ] Hudson commented on MNG-7045: - Build unstable in Jenkins: Maven » Maven TLP » maven » MRESOLVER-94 #19 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MRESOLVER-94/19/ > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Labels: up-for-grabs > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6075) Increase the model validation level to the next minor level version
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316720#comment-17316720 ] Hudson commented on MNG-6075: - Build unstable in Jenkins: Maven » Maven TLP » maven » MRESOLVER-94 #19 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MRESOLVER-94/19/ > Increase the model validation level to the next minor level version > --- > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Critical > Fix For: 4.0.0, 4.0.0-alpha-1 > > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7128) improve error message when blocked repository defined in build POM
[ https://issues.apache.org/jira/browse/MNG-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316704#comment-17316704 ] Hudson commented on MNG-7128: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6829 #19 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6829/19/ > improve error message when blocked repository defined in build POM > -- > > Key: MNG-7128 > URL: https://issues.apache.org/jira/browse/MNG-7128 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Maarten Mulders >Assignee: Herve Boutemy >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.1 > > > MRESOLVER-166 brings an enhanced message when the blocked repository comes > from a dependency > But when blocked repository is defined in build pom.xml, there is not > dedidated message: user has to guess that "Downloading from > maven-default-http-blocker: [http://0.0.0.0/]...; comes from such a case > > The download is not blocked as expected before even trying to download, but > the download fails because this is the intent of the chosen > [http://0.0.0.0|http://0.0.0.0/] url... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7112) --projects flag should honor --non-recursive flag
[
https://issues.apache.org/jira/browse/MNG-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316706#comment-17316706
]
Hudson commented on MNG-7112:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6829 #19
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6829/19/
> --projects flag should honor --non-recursive flag
> -
>
> Key: MNG-7112
> URL: https://issues.apache.org/jira/browse/MNG-7112
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and workspace
>Affects Versions: 4.0.x-candidate
>Reporter: Martin Kanters
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> In MNG-6981 and MNG-7102 the behavior around selecting aggregate projects has
> changed.
> Now, when an aggregate is (de)selected, the aggregate project and all its
> children will be (de)selected in the reactor.
> Before, just the aggregate was (de)selected and children were not taken into
> account.
> Because there is no good workaround currently and there is a need for it, we
> should offer a way to bring the old behavior back.
> {{\-N}} or {{\--non-recursive}} is currently used to only select one project,
> and it will not take its children into account during project collection
> (before the reactor flags are applied).
> After discussion on the mailing list, the proposed implementation is to use
> {{\--non-recursive}} together with {{\--projects}} to restore the old
> non-recursive behavior we had before.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316705#comment-17316705 ] Hudson commented on MNG-7045: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6829 #19 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6829/19/ > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Labels: up-for-grabs > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316703#comment-17316703
]
Hudson commented on MNG-6511:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6829 #19
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6829/19/
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6075) Increase the model validation level to the next minor level version
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316702#comment-17316702 ] Hudson commented on MNG-6075: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6829 #19 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6829/19/ > Increase the model validation level to the next minor level version > --- > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Critical > Fix For: 4.0.0, 4.0.0-alpha-1 > > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6075) Increase the model validation level to the next minor level version
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316689#comment-17316689 ] Hudson commented on MNG-6075: - Build unstable in Jenkins: Maven » Maven TLP » maven » MODELTESTS_IMPROVEMENT #20 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MODELTESTS_IMPROVEMENT/20/ > Increase the model validation level to the next minor level version > --- > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Critical > Fix For: 4.0.0, 4.0.0-alpha-1 > > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7128) improve error message when blocked repository defined in build POM
[ https://issues.apache.org/jira/browse/MNG-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316691#comment-17316691 ] Hudson commented on MNG-7128: - Build unstable in Jenkins: Maven » Maven TLP » maven » MODELTESTS_IMPROVEMENT #20 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MODELTESTS_IMPROVEMENT/20/ > improve error message when blocked repository defined in build POM > -- > > Key: MNG-7128 > URL: https://issues.apache.org/jira/browse/MNG-7128 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Maarten Mulders >Assignee: Herve Boutemy >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.1 > > > MRESOLVER-166 brings an enhanced message when the blocked repository comes > from a dependency > But when blocked repository is defined in build pom.xml, there is not > dedidated message: user has to guess that "Downloading from > maven-default-http-blocker: [http://0.0.0.0/]...; comes from such a case > > The download is not blocked as expected before even trying to download, but > the download fails because this is the intent of the chosen > [http://0.0.0.0|http://0.0.0.0/] url... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316692#comment-17316692 ] Hudson commented on MNG-7045: - Build unstable in Jenkins: Maven » Maven TLP » maven » MODELTESTS_IMPROVEMENT #20 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MODELTESTS_IMPROVEMENT/20/ > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Labels: up-for-grabs > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7112) --projects flag should honor --non-recursive flag
[
https://issues.apache.org/jira/browse/MNG-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316693#comment-17316693
]
Hudson commented on MNG-7112:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MODELTESTS_IMPROVEMENT
#20
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MODELTESTS_IMPROVEMENT/20/
> --projects flag should honor --non-recursive flag
> -
>
> Key: MNG-7112
> URL: https://issues.apache.org/jira/browse/MNG-7112
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and workspace
>Affects Versions: 4.0.x-candidate
>Reporter: Martin Kanters
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> In MNG-6981 and MNG-7102 the behavior around selecting aggregate projects has
> changed.
> Now, when an aggregate is (de)selected, the aggregate project and all its
> children will be (de)selected in the reactor.
> Before, just the aggregate was (de)selected and children were not taken into
> account.
> Because there is no good workaround currently and there is a need for it, we
> should offer a way to bring the old behavior back.
> {{\-N}} or {{\--non-recursive}} is currently used to only select one project,
> and it will not take its children into account during project collection
> (before the reactor flags are applied).
> After discussion on the mailing list, the proposed implementation is to use
> {{\--non-recursive}} together with {{\--projects}} to restore the old
> non-recursive behavior we had before.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316690#comment-17316690
]
Hudson commented on MNG-6511:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MODELTESTS_IMPROVEMENT
#20
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MODELTESTS_IMPROVEMENT/20/
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7128) improve error message when blocked repository defined in build POM
[ https://issues.apache.org/jira/browse/MNG-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316674#comment-17316674 ] Hudson commented on MNG-7128: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-4645+MNG-6772 #6 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-4645+MNG-6772/6/ > improve error message when blocked repository defined in build POM > -- > > Key: MNG-7128 > URL: https://issues.apache.org/jira/browse/MNG-7128 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Maarten Mulders >Assignee: Herve Boutemy >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.1 > > > MRESOLVER-166 brings an enhanced message when the blocked repository comes > from a dependency > But when blocked repository is defined in build pom.xml, there is not > dedidated message: user has to guess that "Downloading from > maven-default-http-blocker: [http://0.0.0.0/]...; comes from such a case > > The download is not blocked as expected before even trying to download, but > the download fails because this is the intent of the chosen > [http://0.0.0.0|http://0.0.0.0/] url... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7112) --projects flag should honor --non-recursive flag
[
https://issues.apache.org/jira/browse/MNG-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316676#comment-17316676
]
Hudson commented on MNG-7112:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-4645+MNG-6772 #6
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-4645+MNG-6772/6/
> --projects flag should honor --non-recursive flag
> -
>
> Key: MNG-7112
> URL: https://issues.apache.org/jira/browse/MNG-7112
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and workspace
>Affects Versions: 4.0.x-candidate
>Reporter: Martin Kanters
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> In MNG-6981 and MNG-7102 the behavior around selecting aggregate projects has
> changed.
> Now, when an aggregate is (de)selected, the aggregate project and all its
> children will be (de)selected in the reactor.
> Before, just the aggregate was (de)selected and children were not taken into
> account.
> Because there is no good workaround currently and there is a need for it, we
> should offer a way to bring the old behavior back.
> {{\-N}} or {{\--non-recursive}} is currently used to only select one project,
> and it will not take its children into account during project collection
> (before the reactor flags are applied).
> After discussion on the mailing list, the proposed implementation is to use
> {{\--non-recursive}} together with {{\--projects}} to restore the old
> non-recursive behavior we had before.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316675#comment-17316675 ] Hudson commented on MNG-7045: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-4645+MNG-6772 #6 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-4645+MNG-6772/6/ > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Labels: up-for-grabs > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316673#comment-17316673
]
Hudson commented on MNG-6511:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-4645+MNG-6772 #6
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-4645+MNG-6772/6/
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6075) Increase the model validation level to the next minor level version
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316672#comment-17316672 ] Hudson commented on MNG-6075: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-4645+MNG-6772 #6 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-4645+MNG-6772/6/ > Increase the model validation level to the next minor level version > --- > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Critical > Fix For: 4.0.0, 4.0.0-alpha-1 > > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7112) --projects flag should honor --non-recursive flag
[
https://issues.apache.org/jira/browse/MNG-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316665#comment-17316665
]
Hudson commented on MNG-7112:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-4645 #10
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-4645/10/
> --projects flag should honor --non-recursive flag
> -
>
> Key: MNG-7112
> URL: https://issues.apache.org/jira/browse/MNG-7112
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and workspace
>Affects Versions: 4.0.x-candidate
>Reporter: Martin Kanters
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> In MNG-6981 and MNG-7102 the behavior around selecting aggregate projects has
> changed.
> Now, when an aggregate is (de)selected, the aggregate project and all its
> children will be (de)selected in the reactor.
> Before, just the aggregate was (de)selected and children were not taken into
> account.
> Because there is no good workaround currently and there is a need for it, we
> should offer a way to bring the old behavior back.
> {{\-N}} or {{\--non-recursive}} is currently used to only select one project,
> and it will not take its children into account during project collection
> (before the reactor flags are applied).
> After discussion on the mailing list, the proposed implementation is to use
> {{\--non-recursive}} together with {{\--projects}} to restore the old
> non-recursive behavior we had before.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7128) improve error message when blocked repository defined in build POM
[ https://issues.apache.org/jira/browse/MNG-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316663#comment-17316663 ] Hudson commented on MNG-7128: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-4645 #10 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-4645/10/ > improve error message when blocked repository defined in build POM > -- > > Key: MNG-7128 > URL: https://issues.apache.org/jira/browse/MNG-7128 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Maarten Mulders >Assignee: Herve Boutemy >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.1 > > > MRESOLVER-166 brings an enhanced message when the blocked repository comes > from a dependency > But when blocked repository is defined in build pom.xml, there is not > dedidated message: user has to guess that "Downloading from > maven-default-http-blocker: [http://0.0.0.0/]...; comes from such a case > > The download is not blocked as expected before even trying to download, but > the download fails because this is the intent of the chosen > [http://0.0.0.0|http://0.0.0.0/] url... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316662#comment-17316662
]
Hudson commented on MNG-6511:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-4645 #10
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-4645/10/
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6075) Increase the model validation level to the next minor level version
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316661#comment-17316661 ] Hudson commented on MNG-6075: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-4645 #10 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-4645/10/ > Increase the model validation level to the next minor level version > --- > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Critical > Fix For: 4.0.0, 4.0.0-alpha-1 > > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316664#comment-17316664 ] Hudson commented on MNG-7045: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-4645 #10 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-4645/10/ > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Labels: up-for-grabs > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316656#comment-17316656 ] Hudson commented on MNG-7045: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6727 #5 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6727/5/ > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Labels: up-for-grabs > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7128) improve error message when blocked repository defined in build POM
[ https://issues.apache.org/jira/browse/MNG-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316655#comment-17316655 ] Hudson commented on MNG-7128: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6727 #5 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6727/5/ > improve error message when blocked repository defined in build POM > -- > > Key: MNG-7128 > URL: https://issues.apache.org/jira/browse/MNG-7128 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Maarten Mulders >Assignee: Herve Boutemy >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.1 > > > MRESOLVER-166 brings an enhanced message when the blocked repository comes > from a dependency > But when blocked repository is defined in build pom.xml, there is not > dedidated message: user has to guess that "Downloading from > maven-default-http-blocker: [http://0.0.0.0/]...; comes from such a case > > The download is not blocked as expected before even trying to download, but > the download fails because this is the intent of the chosen > [http://0.0.0.0|http://0.0.0.0/] url... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316654#comment-17316654
]
Hudson commented on MNG-6511:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6727 #5
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6727/5/
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6075) Increase the model validation level to the next minor level version
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316653#comment-17316653 ] Hudson commented on MNG-6075: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6727 #5 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6727/5/ > Increase the model validation level to the next minor level version > --- > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Critical > Fix For: 4.0.0, 4.0.0-alpha-1 > > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7112) --projects flag should honor --non-recursive flag
[
https://issues.apache.org/jira/browse/MNG-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316657#comment-17316657
]
Hudson commented on MNG-7112:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6727 #5
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6727/5/
> --projects flag should honor --non-recursive flag
> -
>
> Key: MNG-7112
> URL: https://issues.apache.org/jira/browse/MNG-7112
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and workspace
>Affects Versions: 4.0.x-candidate
>Reporter: Martin Kanters
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> In MNG-6981 and MNG-7102 the behavior around selecting aggregate projects has
> changed.
> Now, when an aggregate is (de)selected, the aggregate project and all its
> children will be (de)selected in the reactor.
> Before, just the aggregate was (de)selected and children were not taken into
> account.
> Because there is no good workaround currently and there is a need for it, we
> should offer a way to bring the old behavior back.
> {{\-N}} or {{\--non-recursive}} is currently used to only select one project,
> and it will not take its children into account during project collection
> (before the reactor flags are applied).
> After discussion on the mailing list, the proposed implementation is to use
> {{\--non-recursive}} together with {{\--projects}} to restore the old
> non-recursive behavior we had before.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6075) Increase the model validation level to the next minor level version
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316645#comment-17316645 ] Hudson commented on MNG-6075: - Build unstable in Jenkins: Maven » Maven TLP » maven » MRESOLVER-157 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MRESOLVER-157/14/ > Increase the model validation level to the next minor level version > --- > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Critical > Fix For: 4.0.0, 4.0.0-alpha-1 > > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7128) improve error message when blocked repository defined in build POM
[ https://issues.apache.org/jira/browse/MNG-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316647#comment-17316647 ] Hudson commented on MNG-7128: - Build unstable in Jenkins: Maven » Maven TLP » maven » MRESOLVER-157 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MRESOLVER-157/14/ > improve error message when blocked repository defined in build POM > -- > > Key: MNG-7128 > URL: https://issues.apache.org/jira/browse/MNG-7128 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Maarten Mulders >Assignee: Herve Boutemy >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.1 > > > MRESOLVER-166 brings an enhanced message when the blocked repository comes > from a dependency > But when blocked repository is defined in build pom.xml, there is not > dedidated message: user has to guess that "Downloading from > maven-default-http-blocker: [http://0.0.0.0/]...; comes from such a case > > The download is not blocked as expected before even trying to download, but > the download fails because this is the intent of the chosen > [http://0.0.0.0|http://0.0.0.0/] url... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316646#comment-17316646
]
Hudson commented on MNG-6511:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MRESOLVER-157 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MRESOLVER-157/14/
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7112) --projects flag should honor --non-recursive flag
[
https://issues.apache.org/jira/browse/MNG-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316649#comment-17316649
]
Hudson commented on MNG-7112:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MRESOLVER-157 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MRESOLVER-157/14/
> --projects flag should honor --non-recursive flag
> -
>
> Key: MNG-7112
> URL: https://issues.apache.org/jira/browse/MNG-7112
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and workspace
>Affects Versions: 4.0.x-candidate
>Reporter: Martin Kanters
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> In MNG-6981 and MNG-7102 the behavior around selecting aggregate projects has
> changed.
> Now, when an aggregate is (de)selected, the aggregate project and all its
> children will be (de)selected in the reactor.
> Before, just the aggregate was (de)selected and children were not taken into
> account.
> Because there is no good workaround currently and there is a need for it, we
> should offer a way to bring the old behavior back.
> {{\-N}} or {{\--non-recursive}} is currently used to only select one project,
> and it will not take its children into account during project collection
> (before the reactor flags are applied).
> After discussion on the mailing list, the proposed implementation is to use
> {{\--non-recursive}} together with {{\--projects}} to restore the old
> non-recursive behavior we had before.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316643#comment-17316643 ] Hudson commented on MNG-7045: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-7032_versioncolours #9 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7032_versioncolours/9/ > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Labels: up-for-grabs > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6075) Increase the model validation level to the next minor level version
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316640#comment-17316640 ] Hudson commented on MNG-6075: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-7032_versioncolours #9 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7032_versioncolours/9/ > Increase the model validation level to the next minor level version > --- > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Critical > Fix For: 4.0.0, 4.0.0-alpha-1 > > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316648#comment-17316648 ] Hudson commented on MNG-7045: - Build unstable in Jenkins: Maven » Maven TLP » maven » MRESOLVER-157 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MRESOLVER-157/14/ > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Labels: up-for-grabs > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7112) --projects flag should honor --non-recursive flag
[
https://issues.apache.org/jira/browse/MNG-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316644#comment-17316644
]
Hudson commented on MNG-7112:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-7032_versioncolours
#9
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7032_versioncolours/9/
> --projects flag should honor --non-recursive flag
> -
>
> Key: MNG-7112
> URL: https://issues.apache.org/jira/browse/MNG-7112
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and workspace
>Affects Versions: 4.0.x-candidate
>Reporter: Martin Kanters
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> In MNG-6981 and MNG-7102 the behavior around selecting aggregate projects has
> changed.
> Now, when an aggregate is (de)selected, the aggregate project and all its
> children will be (de)selected in the reactor.
> Before, just the aggregate was (de)selected and children were not taken into
> account.
> Because there is no good workaround currently and there is a need for it, we
> should offer a way to bring the old behavior back.
> {{\-N}} or {{\--non-recursive}} is currently used to only select one project,
> and it will not take its children into account during project collection
> (before the reactor flags are applied).
> After discussion on the mailing list, the proposed implementation is to use
> {{\--non-recursive}} together with {{\--projects}} to restore the old
> non-recursive behavior we had before.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7128) improve error message when blocked repository defined in build POM
[ https://issues.apache.org/jira/browse/MNG-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316642#comment-17316642 ] Hudson commented on MNG-7128: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-7032_versioncolours #9 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7032_versioncolours/9/ > improve error message when blocked repository defined in build POM > -- > > Key: MNG-7128 > URL: https://issues.apache.org/jira/browse/MNG-7128 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Maarten Mulders >Assignee: Herve Boutemy >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.1 > > > MRESOLVER-166 brings an enhanced message when the blocked repository comes > from a dependency > But when blocked repository is defined in build pom.xml, there is not > dedidated message: user has to guess that "Downloading from > maven-default-http-blocker: [http://0.0.0.0/]...; comes from such a case > > The download is not blocked as expected before even trying to download, but > the download fails because this is the intent of the chosen > [http://0.0.0.0|http://0.0.0.0/] url... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316641#comment-17316641
]
Hudson commented on MNG-6511:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-7032_versioncolours
#9
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7032_versioncolours/9/
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7112) --projects flag should honor --non-recursive flag
[
https://issues.apache.org/jira/browse/MNG-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316629#comment-17316629
]
Hudson commented on MNG-7112:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6471 #5
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6471/5/
> --projects flag should honor --non-recursive flag
> -
>
> Key: MNG-7112
> URL: https://issues.apache.org/jira/browse/MNG-7112
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and workspace
>Affects Versions: 4.0.x-candidate
>Reporter: Martin Kanters
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> In MNG-6981 and MNG-7102 the behavior around selecting aggregate projects has
> changed.
> Now, when an aggregate is (de)selected, the aggregate project and all its
> children will be (de)selected in the reactor.
> Before, just the aggregate was (de)selected and children were not taken into
> account.
> Because there is no good workaround currently and there is a need for it, we
> should offer a way to bring the old behavior back.
> {{\-N}} or {{\--non-recursive}} is currently used to only select one project,
> and it will not take its children into account during project collection
> (before the reactor flags are applied).
> After discussion on the mailing list, the proposed implementation is to use
> {{\--non-recursive}} together with {{\--projects}} to restore the old
> non-recursive behavior we had before.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316628#comment-17316628 ] Hudson commented on MNG-7045: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6471 #5 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6471/5/ > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Labels: up-for-grabs > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6075) Increase the model validation level to the next minor level version
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316625#comment-17316625 ] Hudson commented on MNG-6075: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6471 #5 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6471/5/ > Increase the model validation level to the next minor level version > --- > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Critical > Fix For: 4.0.0, 4.0.0-alpha-1 > > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7128) improve error message when blocked repository defined in build POM
[ https://issues.apache.org/jira/browse/MNG-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316627#comment-17316627 ] Hudson commented on MNG-7128: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6471 #5 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6471/5/ > improve error message when blocked repository defined in build POM > -- > > Key: MNG-7128 > URL: https://issues.apache.org/jira/browse/MNG-7128 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Maarten Mulders >Assignee: Herve Boutemy >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.1 > > > MRESOLVER-166 brings an enhanced message when the blocked repository comes > from a dependency > But when blocked repository is defined in build pom.xml, there is not > dedidated message: user has to guess that "Downloading from > maven-default-http-blocker: [http://0.0.0.0/]...; comes from such a case > > The download is not blocked as expected before even trying to download, but > the download fails because this is the intent of the chosen > [http://0.0.0.0|http://0.0.0.0/] url... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316626#comment-17316626
]
Hudson commented on MNG-6511:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6471 #5
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6471/5/
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7112) --projects flag should honor --non-recursive flag
[
https://issues.apache.org/jira/browse/MNG-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316624#comment-17316624
]
Hudson commented on MNG-7112:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » checkstyle-next #7
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/checkstyle-next/7/
> --projects flag should honor --non-recursive flag
> -
>
> Key: MNG-7112
> URL: https://issues.apache.org/jira/browse/MNG-7112
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and workspace
>Affects Versions: 4.0.x-candidate
>Reporter: Martin Kanters
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> In MNG-6981 and MNG-7102 the behavior around selecting aggregate projects has
> changed.
> Now, when an aggregate is (de)selected, the aggregate project and all its
> children will be (de)selected in the reactor.
> Before, just the aggregate was (de)selected and children were not taken into
> account.
> Because there is no good workaround currently and there is a need for it, we
> should offer a way to bring the old behavior back.
> {{\-N}} or {{\--non-recursive}} is currently used to only select one project,
> and it will not take its children into account during project collection
> (before the reactor flags are applied).
> After discussion on the mailing list, the proposed implementation is to use
> {{\--non-recursive}} together with {{\--projects}} to restore the old
> non-recursive behavior we had before.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7128) improve error message when blocked repository defined in build POM
[ https://issues.apache.org/jira/browse/MNG-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316622#comment-17316622 ] Hudson commented on MNG-7128: - Build unstable in Jenkins: Maven » Maven TLP » maven » checkstyle-next #7 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/checkstyle-next/7/ > improve error message when blocked repository defined in build POM > -- > > Key: MNG-7128 > URL: https://issues.apache.org/jira/browse/MNG-7128 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Maarten Mulders >Assignee: Herve Boutemy >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.1 > > > MRESOLVER-166 brings an enhanced message when the blocked repository comes > from a dependency > But when blocked repository is defined in build pom.xml, there is not > dedidated message: user has to guess that "Downloading from > maven-default-http-blocker: [http://0.0.0.0/]...; comes from such a case > > The download is not blocked as expected before even trying to download, but > the download fails because this is the intent of the chosen > [http://0.0.0.0|http://0.0.0.0/] url... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316623#comment-17316623 ] Hudson commented on MNG-7045: - Build unstable in Jenkins: Maven » Maven TLP » maven » checkstyle-next #7 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/checkstyle-next/7/ > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Labels: up-for-grabs > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316621#comment-17316621
]
Hudson commented on MNG-6511:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » checkstyle-next #7
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/checkstyle-next/7/
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6075) Increase the model validation level to the next minor level version
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316620#comment-17316620 ] Hudson commented on MNG-6075: - Build unstable in Jenkins: Maven » Maven TLP » maven » checkstyle-next #7 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/checkstyle-next/7/ > Increase the model validation level to the next minor level version > --- > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Critical > Fix For: 4.0.0, 4.0.0-alpha-1 > > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7112) --projects flag should honor --non-recursive flag
[
https://issues.apache.org/jira/browse/MNG-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316568#comment-17316568
]
Hudson commented on MNG-7112:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-7122 #2
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7122/2/
> --projects flag should honor --non-recursive flag
> -
>
> Key: MNG-7112
> URL: https://issues.apache.org/jira/browse/MNG-7112
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and workspace
>Affects Versions: 4.0.x-candidate
>Reporter: Martin Kanters
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> In MNG-6981 and MNG-7102 the behavior around selecting aggregate projects has
> changed.
> Now, when an aggregate is (de)selected, the aggregate project and all its
> children will be (de)selected in the reactor.
> Before, just the aggregate was (de)selected and children were not taken into
> account.
> Because there is no good workaround currently and there is a need for it, we
> should offer a way to bring the old behavior back.
> {{\-N}} or {{\--non-recursive}} is currently used to only select one project,
> and it will not take its children into account during project collection
> (before the reactor flags are applied).
> After discussion on the mailing list, the proposed implementation is to use
> {{\--non-recursive}} together with {{\--projects}} to restore the old
> non-recursive behavior we had before.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316565#comment-17316565
]
Hudson commented on MNG-6511:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-7122 #2
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7122/2/
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316567#comment-17316567 ] Hudson commented on MNG-7045: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-7122 #2 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7122/2/ > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Labels: up-for-grabs > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7128) improve error message when blocked repository defined in build POM
[ https://issues.apache.org/jira/browse/MNG-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316566#comment-17316566 ] Hudson commented on MNG-7128: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-7122 #2 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7122/2/ > improve error message when blocked repository defined in build POM > -- > > Key: MNG-7128 > URL: https://issues.apache.org/jira/browse/MNG-7128 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Maarten Mulders >Assignee: Herve Boutemy >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.1 > > > MRESOLVER-166 brings an enhanced message when the blocked repository comes > from a dependency > But when blocked repository is defined in build pom.xml, there is not > dedidated message: user has to guess that "Downloading from > maven-default-http-blocker: [http://0.0.0.0/]...; comes from such a case > > The download is not blocked as expected before even trying to download, but > the download fails because this is the intent of the chosen > [http://0.0.0.0|http://0.0.0.0/] url... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7112) --projects flag should honor --non-recursive flag
[
https://issues.apache.org/jira/browse/MNG-7112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316551#comment-17316551
]
Hudson commented on MNG-7112:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-7063 #4
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7063/4/
> --projects flag should honor --non-recursive flag
> -
>
> Key: MNG-7112
> URL: https://issues.apache.org/jira/browse/MNG-7112
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and workspace
>Affects Versions: 4.0.x-candidate
>Reporter: Martin Kanters
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> In MNG-6981 and MNG-7102 the behavior around selecting aggregate projects has
> changed.
> Now, when an aggregate is (de)selected, the aggregate project and all its
> children will be (de)selected in the reactor.
> Before, just the aggregate was (de)selected and children were not taken into
> account.
> Because there is no good workaround currently and there is a need for it, we
> should offer a way to bring the old behavior back.
> {{\-N}} or {{\--non-recursive}} is currently used to only select one project,
> and it will not take its children into account during project collection
> (before the reactor flags are applied).
> After discussion on the mailing list, the proposed implementation is to use
> {{\--non-recursive}} together with {{\--projects}} to restore the old
> non-recursive behavior we had before.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7128) improve error message when blocked repository defined in build POM
[ https://issues.apache.org/jira/browse/MNG-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316549#comment-17316549 ] Hudson commented on MNG-7128: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-7063 #4 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7063/4/ > improve error message when blocked repository defined in build POM > -- > > Key: MNG-7128 > URL: https://issues.apache.org/jira/browse/MNG-7128 > Project: Maven > Issue Type: Bug >Affects Versions: 3.0-alpha-1 >Reporter: Maarten Mulders >Assignee: Herve Boutemy >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.1 > > > MRESOLVER-166 brings an enhanced message when the blocked repository comes > from a dependency > But when blocked repository is defined in build pom.xml, there is not > dedidated message: user has to guess that "Downloading from > maven-default-http-blocker: [http://0.0.0.0/]...; comes from such a case > > The download is not blocked as expected before even trying to download, but > the download fails because this is the intent of the chosen > [http://0.0.0.0|http://0.0.0.0/] url... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316550#comment-17316550 ] Hudson commented on MNG-7045: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-7063 #4 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7063/4/ > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Assignee: Michael Osipov >Priority: Major > Labels: up-for-grabs > Fix For: 4.0.0, 4.0.0-alpha-1 > > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6075) Increase the model validation level to the next minor level version
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316547#comment-17316547 ] Hudson commented on MNG-6075: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-7063 #4 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7063/4/ > Increase the model validation level to the next minor level version > --- > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Critical > Fix For: 4.0.0, 4.0.0-alpha-1 > > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316548#comment-17316548
]
Hudson commented on MNG-6511:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-7063 #4
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7063/4/
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEPLOY-254) Maven Deploy Plugin deploy jar twice : Maven 3.3.3
[
https://issues.apache.org/jira/browse/MDEPLOY-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316529#comment-17316529
]
Michael Osipov commented on MDEPLOY-254:
Does this still happen with Maven master?
> Maven Deploy Plugin deploy jar twice : Maven 3.3.3
> --
>
> Key: MDEPLOY-254
> URL: https://issues.apache.org/jira/browse/MDEPLOY-254
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Akshay
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: log1-mvn_clean_deploy_-Ptwice-source-jar-goal.txt,
> log2-mvn_clean_deploy_-Psource-and-shade-plugin.txt, sample-project.zip
>
>
> Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
> project ** :
> Failed to retrieve remote metadata **/maven-metadata.xml:
> Could not transfer metadata ** from/to **
> {color:#FF} Not authorized , ReasonPhrase:Unauthorized. {color}
>
> Wanted to know if the fix is out in a later version of Maven?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-dependency-plugin] sbrunov commented on pull request #129: [MDEP-693] - `dependency:analyze-only` goal fails on OpenJDK 14
sbrunov commented on pull request #129: URL: https://github.com/apache/maven-dependency-plugin/pull/129#issuecomment-815084088 Dear Sylwester Lachiewicz (@slachiewicz), Could you please release the new version of the plugin? Best regards, Sergey Brunov. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MDEPLOY-254) Maven Deploy Plugin deploy jar twice : Maven 3.3.3
[
https://issues.apache.org/jira/browse/MDEPLOY-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316502#comment-17316502
]
Alexander Kriegisch commented on MDEPLOY-254:
-
OK, weirdly enough, in https://issues.apache.org/jira/browse/MSHADE-195 which
is was closed long ago and should be resolved in Shade 2.4.3 (I am using
3.2.4), there is a hint for a workaround which works for me:
{quote}
h4. Workaround
Configure maven-source-plugin with *{{false}}*. Then the shade
plugin will find the sources and include them in the shaded sources jar, but
the sources jar won't be attached to the build twice.
{quote}
I added this option, and finally Maven Install and Maven Deploy behave the way
I want to: Only one source JAR - correctly, the shaded one - is being installed
and deployed.
> Maven Deploy Plugin deploy jar twice : Maven 3.3.3
> --
>
> Key: MDEPLOY-254
> URL: https://issues.apache.org/jira/browse/MDEPLOY-254
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Akshay
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: log1-mvn_clean_deploy_-Ptwice-source-jar-goal.txt,
> log2-mvn_clean_deploy_-Psource-and-shade-plugin.txt, sample-project.zip
>
>
> Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
> project ** :
> Failed to retrieve remote metadata **/maven-metadata.xml:
> Could not transfer metadata ** from/to **
> {color:#FF} Not authorized , ReasonPhrase:Unauthorized. {color}
>
> Wanted to know if the fix is out in a later version of Maven?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEP-742) dependency plugin does not work with JDK 16
[ https://issues.apache.org/jira/browse/MDEP-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316490#comment-17316490 ] Henning Schmiedehausen commented on MDEP-742: - Agreed. I assume it is one of the dependencies that is doing bytecode analysis. > dependency plugin does not work with JDK 16 > --- > > Key: MDEP-742 > URL: https://issues.apache.org/jira/browse/MDEP-742 > Project: Maven Dependency Plugin > Issue Type: Bug >Affects Versions: 3.1.2 >Reporter: Henning Schmiedehausen >Priority: Major > > Using OpenJDK 16 and building to java 16 bytecode: > Execution default of goal > org.apache.maven.plugins:maven-dependency-plugin:3.1.2:analyze-only failed: > Unsupported class file major version 60 > > ... that seems pretty straightforward. > Using JDK16 to compile to a lower language level works fine. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #343: SUREFIRE-1881 Adds additional debug log and fork connection timeout
Tibor17 edited a comment on pull request #343: URL: https://github.com/apache/maven-surefire/pull/343#issuecomment-815055226 The interprocess comunication between Maven process and Surefire process can be two: 1. process pipes (System.in, System.out see in the Surefire JVM) 2. the TCP connection in Surefire JVM which leaves (1) Therefore I recomended to used the `` which uses the TCP. There are two classes, `legacy` and `surefire` fork node factory. In the future we are aiming for the TCP as default factory, calling it `SurefireForkNodeFactory`. The `LegacyForkNodeFactory` uses the process pipes. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #343: SUREFIRE-1881 Adds additional debug log and fork connection timeout
Tibor17 edited a comment on pull request #343: URL: https://github.com/apache/maven-surefire/pull/343#issuecomment-815055226 The interprocess comunication between Maven process and Surefire process can be two: 1. process pipes (System.in, System.out see in the Surefire JVM) 2. the TCP connection which leaves (1) in Surefire JVM Therefore I recomended to used the `` which uses the TCP. There are two classes, `legacy` and `surefire` fork node factory. In the future we are aiming for the TCP as default factory, calling it `SurefireForkNodeFactory`. The `LegacyForkNodeFactory` uses the process pipes. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #343: SUREFIRE-1881 Adds additional debug log and fork connection timeout
Tibor17 commented on pull request #343: URL: https://github.com/apache/maven-surefire/pull/343#issuecomment-815055226 The interprocess comunication between Maven process and Surefire process can be two: 1. process pipes (System.in, System.out see in the Surefire JVM) 2. the TCP connection which leaves (1) in Surefire JVM Therefore I recomended to used the ``. There are two classes, `legacy` and `surefire` fork node factory. In the future we are aiming for the TCP as default factory. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MDEPLOY-254) Maven Deploy Plugin deploy jar twice : Maven 3.3.3
[
https://issues.apache.org/jira/browse/MDEPLOY-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316474#comment-17316474
]
Alexander Kriegisch commented on MDEPLOY-254:
-
I tried to deactivate Maven Source plugin, but in combination with Maven Shade
that means that only dependency sources will be shaded, not own ones. So
currently there is no other way than to run both Source + Shade if I want a
shaded JAR with (possibly relocated) combined sources of the module itself and
its dependencies. But then inevitably Deploy fails because it tries to deploy
two source JARs with identical names. Please, if someone knows a (not too
hacky) workaround, let me know. I cannot afford failing deployments because of
this.
Just to confirm: My build has no duplicate executions of Maven Source, both the
effective POM and the build log confirm that.
> Maven Deploy Plugin deploy jar twice : Maven 3.3.3
> --
>
> Key: MDEPLOY-254
> URL: https://issues.apache.org/jira/browse/MDEPLOY-254
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Akshay
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: log1-mvn_clean_deploy_-Ptwice-source-jar-goal.txt,
> log2-mvn_clean_deploy_-Psource-and-shade-plugin.txt, sample-project.zip
>
>
> Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
> project ** :
> Failed to retrieve remote metadata **/maven-metadata.xml:
> Could not transfer metadata ** from/to **
> {color:#FF} Not authorized , ReasonPhrase:Unauthorized. {color}
>
> Wanted to know if the fix is out in a later version of Maven?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 commented on pull request #343: SUREFIRE-1881 Adds additional debug log and fork connection timeout
Tibor17 commented on pull request #343: URL: https://github.com/apache/maven-surefire/pull/343#issuecomment-815052599 @reinhapa For those reasons your project should use `` in the Surefire plugin configuration. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] reinhapa commented on pull request #343: SUREFIRE-1881 Adds additional debug log and fork connection timeout
reinhapa commented on pull request #343: URL: https://github.com/apache/maven-surefire/pull/343#issuecomment-815027447 @Tibor17 was a great tip. Found the problem immediately and could eliminate the use of the input stream. On the other hand I know some edge cases (in other projects, where we do access the system input within tests to replay user input, could this cause issues in our scenario too? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MDEPLOY-254) Maven Deploy Plugin deploy jar twice : Maven 3.3.3
[
https://issues.apache.org/jira/browse/MDEPLOY-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316438#comment-17316438
]
Alexander Kriegisch commented on MDEPLOY-254:
-
This still happens with Maven 3.6.3 and Maven Shade with
{{true}}. The thing is, if I do not
configure Maven Source Plugin to run, I get lots of ugly conflict warnings
during non-clean builds, because Maven Shade tries re-shading an already
existing source JAR. The only way to avoid this is to even configure an
additional
{code:xml}
true
{code}
But then I get the duplicate uploads during deploy and e.g. on GitHub Packages
an error like:
{code:java}
Transfer failed for (...)xyz-sources.jar 409 Conflict
{code}
This might be a conceptual problem in Maven itself, a shortcoming in Shade or
Source, I really don't know and have no intention to get philosophical about
something other people here know way more about. what I am sure about, though,
is that this is a real problem many people are struggling with and nothing has
happened to effectively fix it. Just sweeping this under the rug and closing it
as "won't fix" because nobody dares to touch it certainly will not fix the
problem.
> Maven Deploy Plugin deploy jar twice : Maven 3.3.3
> --
>
> Key: MDEPLOY-254
> URL: https://issues.apache.org/jira/browse/MDEPLOY-254
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Akshay
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: log1-mvn_clean_deploy_-Ptwice-source-jar-goal.txt,
> log2-mvn_clean_deploy_-Psource-and-shade-plugin.txt, sample-project.zip
>
>
> Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
> project ** :
> Failed to retrieve remote metadata **/maven-metadata.xml:
> Could not transfer metadata ** from/to **
> {color:#FF} Not authorized , ReasonPhrase:Unauthorized. {color}
>
> Wanted to know if the fix is out in a later version of Maven?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEP-742) dependency plugin does not work with JDK 16
[ https://issues.apache.org/jira/browse/MDEP-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17316206#comment-17316206 ] Michael Osipov commented on MDEP-742: - The same game every six months... > dependency plugin does not work with JDK 16 > --- > > Key: MDEP-742 > URL: https://issues.apache.org/jira/browse/MDEP-742 > Project: Maven Dependency Plugin > Issue Type: Bug >Affects Versions: 3.1.2 >Reporter: Henning Schmiedehausen >Priority: Major > > Using OpenJDK 16 and building to java 16 bytecode: > Execution default of goal > org.apache.maven.plugins:maven-dependency-plugin:3.1.2:analyze-only failed: > Unsupported class file major version 60 > > ... that seems pretty straightforward. > Using JDK16 to compile to a lower language level works fine. -- This message was sent by Atlassian Jira (v8.3.4#803005)
