[GitHub] [maven-mvnd] ErQire commented on issue #552: How to use mvnd in Jenkins?
ErQire commented on issue #552: URL: https://github.com/apache/maven-mvnd/issues/552#issuecomment-1003294477 > The same question ! > > I config Global Tool Configuration in jenkins, and set Maven's Name is **mvnd**, and MAVEN_HOME is **/home/mvnd-0.7.1/mvn**, then build without mvnd, hurry, thanks Are you sure it works? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] ErQire removed a comment on issue #552: How to use mvnd in Jenkins?
ErQire removed a comment on issue #552: URL: https://github.com/apache/maven-mvnd/issues/552#issuecomment-1003294357 > 同样的问题！ > > 我在jenkins里配置了全局工具配置，设置Maven的名字是**mvnd**，MAVEN_HOME是**/home/mvnd-0.7.1/mvn**，然后build不用mvnd，快点，谢谢 Are you sure it works? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] ErQire closed issue #552: How to use mvnd in Jenkins?
ErQire closed issue #552: URL: https://github.com/apache/maven-mvnd/issues/552 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] ErQire commented on issue #552: How to use mvnd in Jenkins?
ErQire commented on issue #552: URL: https://github.com/apache/maven-mvnd/issues/552#issuecomment-1003294357 > 同样的问题！ > > 我在jenkins里配置了全局工具配置，设置Maven的名字是**mvnd**，MAVEN_HOME是**/home/mvnd-0.7.1/mvn**，然后build不用mvnd，快点，谢谢 Are you sure it works? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-invoker] dependabot[bot] opened a new pull request #36: Bump maven-site-plugin from 3.9.1 to 3.10.0
dependabot[bot] opened a new pull request #36: URL: https://github.com/apache/maven-invoker/pull/36 Bumps [maven-site-plugin](https://github.com/apache/maven-site-plugin) from 3.9.1 to 3.10.0. Commits https://github.com/apache/maven-site-plugin/commit/c56b7b2ad2baecbf4286151c645ff4ee9190f420;>c56b7b2 [maven-release-plugin] prepare release maven-site-plugin-3.10.0 https://github.com/apache/maven-site-plugin/commit/7029bab59cac4fe83b62c245e55c37bcb79d9061;>7029bab [MSITE-878] Upgrade Doxia to 1.11.1 and Doxia Tools to 1.11.1 https://github.com/apache/maven-site-plugin/commit/7f8fe7ead4e42b7797eed7eb87c878a16e10b5be;>7f8fe7e [MSITE-877] Shared GitHub Actions (https://github-redirect.dependabot.com/apache/maven-site-plugin/issues/65;>#65) https://github.com/apache/maven-site-plugin/commit/e3302845bd4fac62e7869d1afd0faadd0499becc;>e330284 require CDATA https://github.com/apache/maven-site-plugin/commit/eeba50cf6854c9cca709ae47a626d57d924e463e;>eeba50c Add PR template https://github.com/apache/maven-site-plugin/commit/7813e8f193131faec8898b54b0e59c82602ab665;>7813e8f add Sitetools' integration tool and skin model https://github.com/apache/maven-site-plugin/commit/fda2a84b09a6d08ceb26efee963f00a21e02ffc2;>fda2a84 Updated CI setup https://github.com/apache/maven-site-plugin/commit/0cd2070cf4e32086fe936ea09c5f80c7d5a988cb;>0cd2070 Bump slf4jVersion from 1.7.31 to 1.7.32 (https://github-redirect.dependabot.com/apache/maven-site-plugin/issues/58;>#58) https://github.com/apache/maven-site-plugin/commit/9f24d2bd21f3d7a741ea74b4f41aa42ee02ce625;>9f24d2b update CI url https://github.com/apache/maven-site-plugin/commit/e06aa7822797f6ee54ee4dd309d955c3822df801;>e06aa78 [MSITE-875] add 3.10.0 in history table Additional commits viewable in https://github.com/apache/maven-site-plugin/compare/maven-site-plugin-3.9.1...maven-site-plugin-3.10.0;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-javadoc-plugin] dependabot[bot] opened a new pull request #115: Bump wagonVersion from 2.4 to 3.5.1
dependabot[bot] opened a new pull request #115: URL: https://github.com/apache/maven-javadoc-plugin/pull/115 Bumps `wagonVersion` from 2.4 to 3.5.1. Updates `wagon-provider-api` from 2.4 to 3.5.1 Commits https://github.com/apache/maven-wagon/commit/a40b7196f72f23a68b765c0a9a3c6984edbc221d;>a40b719 [maven-release-plugin] prepare release wagon-3.5.1 https://github.com/apache/maven-wagon/commit/fd2ae925fab62da455df61d915126cee13a1d31b;>fd2ae92 [WAGON-623] Upgrade HttpCore to 4.4.15 https://github.com/apache/maven-wagon/commit/c9aa4c51fd256b4a949c658aabbdcc057bcc253e;>c9aa4c5 [WAGON-622] Upgrade Plexus Interactivity to 1.1 https://github.com/apache/maven-wagon/commit/3b5f142b7054962cd28b91cc9f3e2cf94e24f4f8;>3b5f142 [WAGON-621] Upgrade JUnit to 4.13.2 https://github.com/apache/maven-wagon/commit/90a952d6ab4ba676128a377aba13f0af88d26896;>90a952d [WAGON-620] Upgrade SLF4J to 1.7.32 https://github.com/apache/maven-wagon/commit/561fe11029c1aa6199d1658259f85c4bca6b0eac;>561fe11 [WAGON-619] Remove shading of JSoup https://github.com/apache/maven-wagon/commit/efbee57381490b1b93b587212022fcf769a1b209;>efbee57 [maven-release-plugin] prepare for next development iteration https://github.com/apache/maven-wagon/commit/59c3cbbcf53d43689c6bfaeb897a764aa39f7832;>59c3cbb [maven-release-plugin] prepare release wagon-3.5.0 https://github.com/apache/maven-wagon/commit/f23b6a350e1f1e6d90a539429a88ebaeb069df8d;>f23b6a3 [WAGON-618] Remove HTTP file listing with JSoup https://github.com/apache/maven-wagon/commit/bd44727b8c86ee10f783adab3c0d100a8ba1a8ea;>bd44727 Add grant deprecation notice Additional commits viewable in https://github.com/apache/maven-wagon/compare/wagon-2.4...wagon-3.5.1;>compare view Updates `wagon-http` from 2.4 to 3.5.1 Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] mstao commented on issue #553: Windows configuration mvn/conf/setting.xml does not take effect
mstao commented on issue #553: URL: https://github.com/apache/maven-mvnd/issues/553#issuecomment-1003255809 Hi, you can use `./mvn/conf/settings.xml` , such as : ``` maven.settings=E://D//software//mvnd-0.7.1-windows-amd64//mvn//conf//settings.xml ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MENFORCER-407) Enforcer 3.0.0 breaks with Maven 3.8.4
[ https://issues.apache.org/jira/browse/MENFORCER-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17467055#comment-17467055 ] Michael Osipov commented on MENFORCER-407: -- Can you provide that output since I do not have access to that project?! > Enforcer 3.0.0 breaks with Maven 3.8.4 > -- > > Key: MENFORCER-407 > URL: https://issues.apache.org/jira/browse/MENFORCER-407 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Plugin >Affects Versions: 3.0.0 >Reporter: David Pilato >Priority: Major > Fix For: waiting-for-feedback > > Attachments: enforcer-3.0.0.log, enforcer.3.0.0-M3.log > > > Here is the situation. I'm trying to [upgrade enforcer from 3.0.0-M3 to > 3.0.0|https://github.com/dadoonet/fscrawler/pull/1214]. > > Everything worked well on my laptop with Maven 3.5.3. So I looked at the > version used by Github actions and saw that it's using Maven 3.8.4. > As soon as I upgraded my local version of Maven to 3.8.4, I started to hit > the same exact issue. It seems to try to pull > net.sf.ehcache:sizeof-agent:1.0.1. > If I revert Enforcer to 3.0.0-M3 with Maven 3.8.4, I can run without any > issue mvn enforcer:enforce. > So I suspect that the combination of both upgrades is triggering something. > I noted also that 3.0.0 now tries to enforce as well dependencies marked as > provided. Might be the reason of this. > I attached the full logs when running with 3.0.0 and 3.0.0-M3. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (DOXIA-632) Remove remaining deprecated code
[
https://issues.apache.org/jira/browse/DOXIA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated DOXIA-632:
-
Description: *
{{org.apache.maven.doxia.parser.AbstractParser.getBasedir()}} cannot be removed
since there is no suitable replacement
> Remove remaining deprecated code
>
>
> Key: DOXIA-632
> URL: https://issues.apache.org/jira/browse/DOXIA-632
> Project: Maven Doxia
> Issue Type: Task
>Affects Versions: 1.11.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 2.0.0-M1
>
>
> * {{org.apache.maven.doxia.parser.AbstractParser.getBasedir()}} cannot be
> removed since there is no suitable replacement
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1873) Junit5 tag expression support for `any()` and `none()`
[
https://issues.apache.org/jira/browse/SUREFIRE-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17467053#comment-17467053
]
Yauheni Kalitska commented on SUREFIRE-1873:
Can i vote or suggest fix for this bug?
> Junit5 tag expression support for `any()` and `none()`
> --
>
> Key: SUREFIRE-1873
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1873
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 2.22.2, 3.0.0-M5
>Reporter: Daniel Robert
>Priority: Major
>
> As of JUnit5
> [5.6.0|https://junit.org/junit5/docs/5.7.0/release-notes/#release-notes-5.6.0]
> tag expression support was added for {{any()}} and {{none()}} but it does
> not seem surefire honors these.
> In 2.22.2 they seem to be silently ignored.
> In 3.0.0-M5 this message is output:
> {quote}[WARNING] Couldn't load group class 'none' in Surefire|Failsafe
> plugin. The group class is ignored!
> {quote}
> Sample configuration to run 'tests that do not have any tags':
> {code:xml}
>
> maven-surefire-plugin
>
> none()
> any()
>
>
> {code}
> Related: it's not clear the order of precedence for 'include' vs 'exclude'.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-dependency-tree] slachiewicz merged pull request #8: Bump maven-site-plugin from 3.9.1 to 3.10.0
slachiewicz merged pull request #8: URL: https://github.com/apache/maven-dependency-tree/pull/8 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MENFORCER-407) Enforcer 3.0.0 breaks with Maven 3.8.4
[
https://issues.apache.org/jira/browse/MENFORCER-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17467040#comment-17467040
]
Matt Nelson commented on MENFORCER-407:
---
{quote}
Different resolution behavior
{quote}
Adding another perspective that I'm seeing this as well. I am able to generate
{{dependency:tree}} and {{dependency:collect}} without error, and the
dependencies listed as a problem with the {{dependencyConvergence}} rule do not
show in the tree/collect outputs.
> Enforcer 3.0.0 breaks with Maven 3.8.4
> --
>
> Key: MENFORCER-407
> URL: https://issues.apache.org/jira/browse/MENFORCER-407
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.0.0
>Reporter: David Pilato
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: enforcer-3.0.0.log, enforcer.3.0.0-M3.log
>
>
> Here is the situation. I'm trying to [upgrade enforcer from 3.0.0-M3 to
> 3.0.0|https://github.com/dadoonet/fscrawler/pull/1214].
>
> Everything worked well on my laptop with Maven 3.5.3. So I looked at the
> version used by Github actions and saw that it's using Maven 3.8.4.
> As soon as I upgraded my local version of Maven to 3.8.4, I started to hit
> the same exact issue. It seems to try to pull
> net.sf.ehcache:sizeof-agent:1.0.1.
> If I revert Enforcer to 3.0.0-M3 with Maven 3.8.4, I can run without any
> issue mvn enforcer:enforce.
> So I suspect that the combination of both upgrades is triggering something.
> I noted also that 3.0.0 now tries to enforce as well dependencies marked as
> provided. Might be the reason of this.
> I attached the full logs when running with 3.0.0 and 3.0.0-M3.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (DOXIA-632) Remove remaining deprecated code
Michael Osipov created DOXIA-632: Summary: Remove remaining deprecated code Key: DOXIA-632 URL: https://issues.apache.org/jira/browse/DOXIA-632 Project: Maven Doxia Issue Type: Task Affects Versions: 1.11.1 Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 2.0.0-M1 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DOXIA-534) Remove Doxia Logging API
[ https://issues.apache.org/jira/browse/DOXIA-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17467039#comment-17467039 ] ASF GitHub Bot commented on DOXIA-534: -- michael-o opened a new pull request #80: URL: https://github.com/apache/maven-doxia/pull/80 This closes #80 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Remove Doxia Logging API > > > Key: DOXIA-534 > URL: https://issues.apache.org/jira/browse/DOXIA-534 > Project: Maven Doxia > Issue Type: Task > Components: Logging API >Affects Versions: 1.6 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.0.0-M1 > > > We should rethink whether we still need the Doxia Logging API and can replace > it with standard tools like Plexus-injected logging or SLF4J. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-dependency-tree] dependabot[bot] opened a new pull request #8: Bump maven-site-plugin from 3.9.1 to 3.10.0
dependabot[bot] opened a new pull request #8: URL: https://github.com/apache/maven-dependency-tree/pull/8 Bumps [maven-site-plugin](https://github.com/apache/maven-site-plugin) from 3.9.1 to 3.10.0. Commits https://github.com/apache/maven-site-plugin/commit/c56b7b2ad2baecbf4286151c645ff4ee9190f420;>c56b7b2 [maven-release-plugin] prepare release maven-site-plugin-3.10.0 https://github.com/apache/maven-site-plugin/commit/7029bab59cac4fe83b62c245e55c37bcb79d9061;>7029bab [MSITE-878] Upgrade Doxia to 1.11.1 and Doxia Tools to 1.11.1 https://github.com/apache/maven-site-plugin/commit/7f8fe7ead4e42b7797eed7eb87c878a16e10b5be;>7f8fe7e [MSITE-877] Shared GitHub Actions (https://github-redirect.dependabot.com/apache/maven-site-plugin/issues/65;>#65) https://github.com/apache/maven-site-plugin/commit/e3302845bd4fac62e7869d1afd0faadd0499becc;>e330284 require CDATA https://github.com/apache/maven-site-plugin/commit/eeba50cf6854c9cca709ae47a626d57d924e463e;>eeba50c Add PR template https://github.com/apache/maven-site-plugin/commit/7813e8f193131faec8898b54b0e59c82602ab665;>7813e8f add Sitetools' integration tool and skin model https://github.com/apache/maven-site-plugin/commit/fda2a84b09a6d08ceb26efee963f00a21e02ffc2;>fda2a84 Updated CI setup https://github.com/apache/maven-site-plugin/commit/0cd2070cf4e32086fe936ea09c5f80c7d5a988cb;>0cd2070 Bump slf4jVersion from 1.7.31 to 1.7.32 (https://github-redirect.dependabot.com/apache/maven-site-plugin/issues/58;>#58) https://github.com/apache/maven-site-plugin/commit/9f24d2bd21f3d7a741ea74b4f41aa42ee02ce625;>9f24d2b update CI url https://github.com/apache/maven-site-plugin/commit/e06aa7822797f6ee54ee4dd309d955c3822df801;>e06aa78 [MSITE-875] add 3.10.0 in history table Additional commits viewable in https://github.com/apache/maven-site-plugin/compare/maven-site-plugin-3.9.1...maven-site-plugin-3.10.0;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MWRAPPER-48) Error "}" was unexpected at this time (Windows 10)
[
https://issues.apache.org/jira/browse/MWRAPPER-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17467007#comment-17467007
]
Herve Boutemy commented on MWRAPPER-48:
---
no, I don't have time to create such a config
> Error "}" was unexpected at this time (Windows 10)
> --
>
> Key: MWRAPPER-48
> URL: https://issues.apache.org/jira/browse/MWRAPPER-48
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Reporter: Valentin Despa
>Priority: Major
> Attachments: demo.zip, not-working.png, working.png
>
>
> I have generated a simple project using the Spring Initializr. If I try to
> run the Maven wrapper from a workspace folder within Jenkins, the following
> error occurs:
> {{"}" was unexpected at this time}}
> If I copy the project folder and run it from a different location, it works
> with no issues.
> A similar issue has been reported on Stackoverflow as well:
> [https://stackoverflow.com/q/62028432/766177]
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] Tibor17 merged pull request #420: Bump animal-sniffer-maven-plugin from 1.17 to 1.20
Tibor17 merged pull request #420: URL: https://github.com/apache/maven-surefire/pull/420 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 opened a new pull request #420: Bump animal-sniffer-maven-plugin from 1.17 to 1.20
Tibor17 opened a new pull request #420: URL: https://github.com/apache/maven-surefire/pull/420 Bumps [animal-sniffer-maven-plugin](https://github.com/mojohaus/animal-sniffer) from 1.17 to 1.20. - [Release notes](https://github.com/mojohaus/animal-sniffer/releases) - [Commits](https://github.com/mojohaus/animal-sniffer/compare/animal-sniffer-parent-1.17...animal-sniffer-parent-1.20) --- updated-dependencies: - dependency-name: org.codehaus.mojo:animal-sniffer-maven-plugin dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SUREFIRE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean install`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 removed a comment on pull request #411: Bump animal-sniffer-maven-plugin from 1.17 to 1.20
Tibor17 removed a comment on pull request #411: URL: https://github.com/apache/maven-surefire/pull/411#issuecomment-1003187816 @slawekjaranowski This branch was deleted, so this PR cannot be reopened, we have to make it again. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #411: Bump animal-sniffer-maven-plugin from 1.17 to 1.20
Tibor17 commented on pull request #411: URL: https://github.com/apache/maven-surefire/pull/411#issuecomment-1003188234 reopening... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #411: Bump animal-sniffer-maven-plugin from 1.17 to 1.20
Tibor17 commented on pull request #411: URL: https://github.com/apache/maven-surefire/pull/411#issuecomment-1003187816 @slawekjaranowski This branch was deleted, so this PR cannot be reopened, we have to make it again. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (MINVOKER-261) Confusing error message
[
https://issues.apache.org/jira/browse/MINVOKER-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski reassigned MINVOKER-261:
Assignee: Slawomir Jaranowski
> Confusing error message
> ---
>
> Key: MINVOKER-261
> URL: https://issues.apache.org/jira/browse/MINVOKER-261
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Slawomir Jaranowski
>Priority: Minor
>
> It took me a while to figure this one out:
> java.lang.IllegalStateException: ${maven.home} is not specified as a
> directory: '/Cellar/maven/3.6.0/bin'.
>
> Better message:
> ${maven.home} is set to '/Cellar/maven/3.6.0/bin' which does not exist
> or perhaps
> ${maven.home} is set to '/Cellar/maven/3.6.0/bin' which is not a directory
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] slawekjaranowski commented on pull request #415: [SUREFIRE-1955] Switch project to Java 8
slawekjaranowski commented on pull request #415: URL: https://github.com/apache/maven-surefire/pull/415#issuecomment-1003173208 `animal-sniffer-maven-plugin` in next PR, there is one #411 - can be reopened after it -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (DOXIA-534) Remove Doxia Logging API
[ https://issues.apache.org/jira/browse/DOXIA-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned DOXIA-534: Assignee: Michael Osipov > Remove Doxia Logging API > > > Key: DOXIA-534 > URL: https://issues.apache.org/jira/browse/DOXIA-534 > Project: Maven Doxia > Issue Type: Task > Components: Logging API >Affects Versions: 1.6 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.0.0-M1 > > > We should rethink whether we still need the Doxia Logging API and can replace > it with standard tools like Plexus-injected logging or SLF4J. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (DOXIA-630) Remove all deprecated modules
[ https://issues.apache.org/jira/browse/DOXIA-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed DOXIA-630. Resolution: Fixed Fixed with [ba9b17a4903f5efd873c02e20664d563a54bef66|https://gitbox.apache.org/repos/asf?p=maven-doxia.git;a=commit;h=ba9b17a4903f5efd873c02e20664d563a54bef66]. > Remove all deprecated modules > - > > Key: DOXIA-630 > URL: https://issues.apache.org/jira/browse/DOXIA-630 > Project: Maven Doxia > Issue Type: Task > Components: Module - Confluence, Module - Docbook Simple, Module - > FO, Module - Itext, Module - Latex, Module - Rtf, Module - Xdoc, Modules >Affects Versions: 1.11.1 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.0.0-M1 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DOXIA-630) Remove all deprecated modules
[ https://issues.apache.org/jira/browse/DOXIA-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466983#comment-17466983 ] ASF GitHub Bot commented on DOXIA-630: -- asfgit closed pull request #79: URL: https://github.com/apache/maven-doxia/pull/79 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Remove all deprecated modules > - > > Key: DOXIA-630 > URL: https://issues.apache.org/jira/browse/DOXIA-630 > Project: Maven Doxia > Issue Type: Task > Components: Module - Confluence, Module - Docbook Simple, Module - > FO, Module - Itext, Module - Latex, Module - Rtf, Module - Xdoc, Modules >Affects Versions: 1.11.1 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.0.0-M1 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MSHARED-1011) Ease extension of Verifier
[
https://issues.apache.org/jira/browse/MSHARED-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466977#comment-17466977
]
Michael Osipov commented on MSHARED-1011:
-
Can you describe your usecases?
> Ease extension of Verifier
> --
>
> Key: MSHARED-1011
> URL: https://issues.apache.org/jira/browse/MSHARED-1011
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-verifier
>Reporter: Konrad Windszus
>Priority: Major
>
> {{Verifier}} is not a final class but extending custom classes from it is
> hard as crucial functionality is hidden in private methods. Particularly the
> methods
> # {{getMavenLauncher}}
> # {{findLocalRepo}} and
> # {{findDefaultMavenHome}}
> should be made protected to allow to override them in extended Verifier
> classes.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MWRAPPER-48) Error "}" was unexpected at this time (Windows 10)
[
https://issues.apache.org/jira/browse/MWRAPPER-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466967#comment-17466967
]
Valentin Despa commented on MWRAPPER-48:
[~hboutemy] did you try this from a Jenkins workspace?
> Error "}" was unexpected at this time (Windows 10)
> --
>
> Key: MWRAPPER-48
> URL: https://issues.apache.org/jira/browse/MWRAPPER-48
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Reporter: Valentin Despa
>Priority: Major
> Attachments: demo.zip, not-working.png, working.png
>
>
> I have generated a simple project using the Spring Initializr. If I try to
> run the Maven wrapper from a workspace folder within Jenkins, the following
> error occurs:
> {{"}" was unexpected at this time}}
> If I copy the project folder and run it from a different location, it works
> with no issues.
> A similar issue has been reported on Stackoverflow as well:
> [https://stackoverflow.com/q/62028432/766177]
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MWRAPPER-48) Error "}" was unexpected at this time (Windows 10)
[
https://issues.apache.org/jira/browse/MWRAPPER-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466965#comment-17466965
]
Herve Boutemy commented on MWRAPPER-48:
---
I cannot reproduce any failure like this on my Windows 10
could it be related to older powershell versions? could such a version
absolutely require ";" before the "}"?
if you are able to reproduce the issue on your machines, please test this idea
and report
> Error "}" was unexpected at this time (Windows 10)
> --
>
> Key: MWRAPPER-48
> URL: https://issues.apache.org/jira/browse/MWRAPPER-48
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Reporter: Valentin Despa
>Priority: Major
> Attachments: demo.zip, not-working.png, working.png
>
>
> I have generated a simple project using the Spring Initializr. If I try to
> run the Maven wrapper from a workspace folder within Jenkins, the following
> error occurs:
> {{"}" was unexpected at this time}}
> If I copy the project folder and run it from a different location, it works
> with no issues.
> A similar issue has been reported on Stackoverflow as well:
> [https://stackoverflow.com/q/62028432/766177]
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #400: [SUREFIRE-1964] Support for method filtering on excludesFile and includesFile
Tibor17 edited a comment on pull request #400:
URL: https://github.com/apache/maven-surefire/pull/400#issuecomment-1003142907
@imonteroperez
@slawekjaranowski
@olamy
The includes|excludes, includesFile|excludesFile end up within the
TestListResolver.
There is no need to modify the implementation of Provider, TestListResolver
and other stuff.
All we could do is to compromise the sanity check `Method filter prohibited
in includes|excludes|includesFile|excludesFile parameter`.
Below you can see the original method for includesFile. And then the sanity
check is shifted in the modified code, this is my proposal.
```
private List getIncludeList()
throws MojoFailureException
{
List includes = null;
if ( isSpecificTestSpecified() )
{
includes = new ArrayList<>();
addAll( includes, split( getTest(), "," ) );
}
else
{
if ( getIncludesFile() != null )
{
includes = readListFromFile( getIncludesFile() );
}
if ( includes == null )
{
includes = getIncludes();
}
else
{
maybeAppendList( includes, getIncludes() );
}
checkMethodFilterInIncludesExcludes( includes );
if ( includes == null || includes.isEmpty() )
{
includes = asList( getDefaultIncludes() );
}
}
return filterNulls( includes );
}
```
changed to
```
private List getIncludeList()
throws MojoFailureException
{
List includes = null;
if ( isSpecificTestSpecified() )
{
includes = new ArrayList<>();
addAll( includes, split( getTest(), "," ) );
}
else
{
includes = getIncludes();
checkMethodFilterInIncludesExcludes( includes );
if ( getIncludesFile() != null )
{
if ( includes == null )
{
includes = new ArrayList<>();
}
addAll( includes, readListFromFile( getIncludesFile() ) );
}
if ( includes == null || includes.isEmpty() )
{
includes = asList( getDefaultIncludes() );
}
}
return filterNulls( includes );
}
```
Similar with the excludesFile.
@imonteroperez
Would this help you?
Of course we do not know the IT results yet. They may fail.., not sure!
The JavaDoc of both parameters should say that the pattern allows using
#method, and the site documentation 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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #400: [SUREFIRE-1964] Support for method filtering on excludesFile and includesFile
Tibor17 edited a comment on pull request #400:
URL: https://github.com/apache/maven-surefire/pull/400#issuecomment-1003142907
@imonteroperez
@slawekjaranowski
@olamy
The includes|excludes, includesFile|excludesFile end up within the
TestListResolver.
There is no need to modify the implementation of Provider, TestListResolver
and other stuff.
All we could do is to compromise the sanity check `Method filter prohibited
in includes|excludes|includesFile|excludesFile parameter`.
Below you can see the original method for includesFile. And then the sanity
check is shifted in the modified code, this is my proposal.
```
private List getIncludeList()
throws MojoFailureException
{
List includes = null;
if ( isSpecificTestSpecified() )
{
includes = new ArrayList<>();
addAll( includes, split( getTest(), "," ) );
}
else
{
if ( getIncludesFile() != null )
{
includes = readListFromFile( getIncludesFile() );
}
if ( includes == null )
{
includes = getIncludes();
}
else
{
maybeAppendList( includes, getIncludes() );
}
checkMethodFilterInIncludesExcludes( includes );
if ( includes == null || includes.isEmpty() )
{
includes = asList( getDefaultIncludes() );
}
}
return filterNulls( includes );
}
```
changed to
```
private List getIncludeList()
throws MojoFailureException
{
List includes = null;
if ( isSpecificTestSpecified() )
{
includes = new ArrayList<>();
addAll( includes, split( getTest(), "," ) );
}
else
{
includes = getIncludes();
checkMethodFilterInIncludesExcludes( includes );
if ( getIncludesFile() != null )
{
includes = readListFromFile( getIncludesFile() );
}
if ( includes == null || includes.isEmpty() )
{
includes = asList( getDefaultIncludes() );
}
}
return filterNulls( includes );
}
```
Similar with the excludesFile.
@imonteroperez
Would this help you?
Of course we do not know the IT results yet. They may fail.., not sure!
The JavaDoc of both parameters should say that the pattern allows using
#method, and the site documentation 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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (MSHARED-1010) Allow to customize Maven home
[ https://issues.apache.org/jira/browse/MSHARED-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated MSHARED-1010: - Component/s: maven-verifier > Allow to customize Maven home > - > > Key: MSHARED-1010 > URL: https://issues.apache.org/jira/browse/MSHARED-1010 > Project: Maven Shared Components > Issue Type: New Feature > Components: maven-verifier >Reporter: Konrad Windszus >Priority: Major > > In order to run ITs against multiple versions of Maven, it would be > beneficial, if the Maven version cannot only be customised implicitly via > System properties > (https://github.com/apache/maven-verifier/blob/246edfd46a2953f18099864cffb61257c0f2d698/src/main/java/org/apache/maven/it/Verifier.java#L200-L215), > but also more explicitly via a setter method. > This is particularly crucial when multiple verifier instances are used in > multiple threads, as each may leverage a different Maven home directory. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-surefire] Tibor17 commented on pull request #400: [SUREFIRE-1964] Support for method filtering on excludesFile and includesFile
Tibor17 commented on pull request #400:
URL: https://github.com/apache/maven-surefire/pull/400#issuecomment-1003142907
@imonteroperez
@slawekjaranowski
@olamy
The includes|excludes, includesFile|excludesFile end up within the
TestListResolver.
There is no need to modify the implementation of Provider, TestListResolver
and other stuff.
All we could do is to compromise the sanity check `Method filter prohibited
in includes|excludes|includesFile|excludesFile parameter`.
Below you can see the original method for includesFile. And then the sanity
check is shifted in the modified code, this is my proposal.
```
private List getIncludeList()
throws MojoFailureException
{
List includes = null;
if ( isSpecificTestSpecified() )
{
includes = new ArrayList<>();
addAll( includes, split( getTest(), "," ) );
}
else
{
if ( getIncludesFile() != null )
{
includes = readListFromFile( getIncludesFile() );
}
if ( includes == null )
{
includes = getIncludes();
}
else
{
maybeAppendList( includes, getIncludes() );
}
checkMethodFilterInIncludesExcludes( includes );
if ( includes == null || includes.isEmpty() )
{
includes = asList( getDefaultIncludes() );
}
}
return filterNulls( includes );
}
```
changed to
```
private List getIncludeList()
throws MojoFailureException
{
List includes = null;
if ( isSpecificTestSpecified() )
{
includes = new ArrayList<>();
addAll( includes, split( getTest(), "," ) );
}
else
{
includes = getIncludes();
checkMethodFilterInIncludesExcludes( includes );
if ( getIncludesFile() != null )
{
includes = readListFromFile( getIncludesFile() );
}
if ( includes == null || includes.isEmpty() )
{
includes = asList( getDefaultIncludes() );
}
}
return filterNulls( includes );
}
```
Similar with the excludesFile.
@imonteroperez
Would this help you?
Of course we do not know the IT results yet. They may fail.., not sure!
Of course the JavaDoc of both parameters should say that the pattern allows
using #method, and the site documentation 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.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Created] (MSHARED-1011) Ease extension of Verifier
Konrad Windszus created MSHARED-1011:
Summary: Ease extension of Verifier
Key: MSHARED-1011
URL: https://issues.apache.org/jira/browse/MSHARED-1011
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-verifier
Reporter: Konrad Windszus
{{Verifier}} is not a final class but extending custom classes from it is hard
as crucial functionality is hidden in private methods. Particularly the methods
# {{getMavenLauncher}}
# {{findLocalRepo}} and
# {{findDefaultMavenHome}}
should be made protected to allow to override them in extended Verifier classes.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MSHARED-1010) Allow to customize Maven home
[ https://issues.apache.org/jira/browse/MSHARED-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated MSHARED-1010: - Issue Type: New Feature (was: Bug) > Allow to customize Maven home > - > > Key: MSHARED-1010 > URL: https://issues.apache.org/jira/browse/MSHARED-1010 > Project: Maven Shared Components > Issue Type: New Feature >Reporter: Konrad Windszus >Priority: Major > > In order to run ITs against multiple versions of Maven, it would be > beneficial, if the Maven version cannot only be customised implicitly via > System properties > (https://github.com/apache/maven-verifier/blob/246edfd46a2953f18099864cffb61257c0f2d698/src/main/java/org/apache/maven/it/Verifier.java#L200-L215), > but also more explicitly via a setter method. > This is particularly crucial when multiple verifier instances are used in > multiple threads, as each may leverage a different Maven home directory. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MSHARED-1010) Allow to customize Maven home
[ https://issues.apache.org/jira/browse/MSHARED-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated MSHARED-1010: - Description: In order to run ITs against multiple versions of Maven, it would be beneficial, if the Maven version cannot only be customised implicitly via System properties (https://github.com/apache/maven-verifier/blob/246edfd46a2953f18099864cffb61257c0f2d698/src/main/java/org/apache/maven/it/Verifier.java#L200-L215), but also more explicitly via a setter method. This is particularly crucial when multiple verifier instances are used in multiple threads, as each may leverage a different Maven home directory. was:In order to run ITs against multiple versions of Maven, it would be beneficial, if the Maven version cannot only be customised implicitly via System properties (https://github.com/apache/maven-verifier/blob/246edfd46a2953f18099864cffb61257c0f2d698/src/main/java/org/apache/maven/it/Verifier.java#L200-L215), but also more explicitly via a setter method. > Allow to customize Maven home > - > > Key: MSHARED-1010 > URL: https://issues.apache.org/jira/browse/MSHARED-1010 > Project: Maven Shared Components > Issue Type: Bug >Reporter: Konrad Windszus >Priority: Major > > In order to run ITs against multiple versions of Maven, it would be > beneficial, if the Maven version cannot only be customised implicitly via > System properties > (https://github.com/apache/maven-verifier/blob/246edfd46a2953f18099864cffb61257c0f2d698/src/main/java/org/apache/maven/it/Verifier.java#L200-L215), > but also more explicitly via a setter method. > This is particularly crucial when multiple verifier instances are used in > multiple threads, as each may leverage a different Maven home directory. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MWRAPPER-14) Make maven wrapper functional
[
https://issues.apache.org/jira/browse/MWRAPPER-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466949#comment-17466949
]
Hudson commented on MWRAPPER-14:
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5561_maven-3.8.x #3
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5561_maven-3.8.x/3/
> Make maven wrapper functional
> -
>
> Key: MWRAPPER-14
> URL: https://issues.apache.org/jira/browse/MWRAPPER-14
> Project: Maven Wrapper
> Issue Type: Task
>Affects Versions: 3.0.2
>Reporter: Tamás Cservenák
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.1.0
>
>
> Make a wrapper a normal wrapper. The wrapper is not meant to be part of any
> distribution, but a lightweight way to bootstrap maven without the need to
> install it onto target machine.
> With legacy wrapper:
> * checked out project "just works"
> * you know it builds with proper maven
> * exclude any mistake like install ancient mvn version or some distro
> mutilated mvn
> This is the main goal, and by having apache groupId, {{wrapper:wrapper}}
> should work like before.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MWRAPPER-14) Make maven wrapper functional
[
https://issues.apache.org/jira/browse/MWRAPPER-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466939#comment-17466939
]
Hudson commented on MWRAPPER-14:
Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-7374 #2
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7374/2/
> Make maven wrapper functional
> -
>
> Key: MWRAPPER-14
> URL: https://issues.apache.org/jira/browse/MWRAPPER-14
> Project: Maven Wrapper
> Issue Type: Task
>Affects Versions: 3.0.2
>Reporter: Tamás Cservenák
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.1.0
>
>
> Make a wrapper a normal wrapper. The wrapper is not meant to be part of any
> distribution, but a lightweight way to bootstrap maven without the need to
> install it onto target machine.
> With legacy wrapper:
> * checked out project "just works"
> * you know it builds with proper maven
> * exclude any mistake like install ancient mvn version or some distro
> mutilated mvn
> This is the main goal, and by having apache groupId, {{wrapper:wrapper}}
> should work like before.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7047) Validate that repo configuration does not contain any expression
[ https://issues.apache.org/jira/browse/MNG-7047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466937#comment-17466937 ] Hudson commented on MNG-7047: - Build unstable in Jenkins: Maven » Maven TLP » maven » maven-3.8.x #98 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.8.x/98/ > Validate that repo configuration does not contain any expression > > > Key: MNG-7047 > URL: https://issues.apache.org/jira/browse/MNG-7047 > Project: Maven > Issue Type: Improvement > Components: Inheritance and Interpolation >Affects Versions: 3.6.3 >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0, 4.0.0-alpha-1 > > > MNG-7046 reverts the option to allow expressions in the repository > configuration. This should be secured in the ModelValidator to prevent > regression in the future. > As of Maven 4 expressions in the repository will fail the build. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7047) Validate that repo configuration does not contain any expression
[ https://issues.apache.org/jira/browse/MNG-7047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466940#comment-17466940 ] Hudson commented on MNG-7047: - Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-7374 #2 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7374/2/ > Validate that repo configuration does not contain any expression > > > Key: MNG-7047 > URL: https://issues.apache.org/jira/browse/MNG-7047 > Project: Maven > Issue Type: Improvement > Components: Inheritance and Interpolation >Affects Versions: 3.6.3 >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0, 4.0.0-alpha-1 > > > MNG-7046 reverts the option to allow expressions in the repository > configuration. This should be secured in the ModelValidator to prevent > regression in the future. > As of Maven 4 expressions in the repository will fail the build. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MNG-6727) Using version range in parent and CI Friendly Version fails
[
https://issues.apache.org/jira/browse/MNG-6727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6727:
Fix Version/s: 3.8.x-candidate
> Using version range in parent and CI Friendly Version fails
> ---
>
> Key: MNG-6727
> URL: https://issues.apache.org/jira/browse/MNG-6727
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation, POM, Reactor and Workspace
>Affects Versions: 3.5.2, 3.6.1, 3.6.2, 3.6.3
>Reporter: Tom Kiemes
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.x-candidate
>
>
> We would like to pass a [version
> range|https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html] to
> the parent which should be possible since 3.5.0
> At the same time, we would like to use [CI friendly
> versions|https://maven.apache.org/maven-ci-friendly.html] for the artifact
> itself.
> Both on their own work well, but combined they don't.
> {{}}
> {{http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> }}{{xsi:schemaLocation="[http://maven.apache.org/POM/4.0.0]
> [http://maven.apache.org/xsd/maven-4.0.0.xsd];>}}
> {{ 4.0.0}}
> {{ }}
> {{ org.springframework.boot}}
> {{ spring-boot-starter-parent}}
> {{ [2.1,3.0)}}
> {{ }}
> {{ com.example}}
> {{ test}}
> {{ ${revision}}}
> {{ pom}}
> {{ }}
> {{ 0.0.1}}
> {{ }}
> {{}}
>
> The resulting error is:
> {{The project com.example:test:${revision} (/Users/d045390/scratch/test.pom)
> has 1 error}}
> {{[ERROR] Version must be a constant @ line 13, column 12}}
>
> Changing the version range of the parent to a fixed version e.g.
> \{{2.1.5.Release}}, building works.
> Changing the artifact version from ${revision} to a fixed version e.g. 0.0.1
> without using the {{properties}} works as well.
> So it somehow must be the combination of both features which are actually not
> really related or am I missing something?
> PS: I left the modules out for abbreviation purpose. The pom itself can still
> be used to reproduced
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (MNG-6727) Using version range in parent and CI Friendly Version fails
[
https://issues.apache.org/jira/browse/MNG-6727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-6727:
---
Assignee: Michael Osipov
> Using version range in parent and CI Friendly Version fails
> ---
>
> Key: MNG-6727
> URL: https://issues.apache.org/jira/browse/MNG-6727
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation, POM, Reactor and Workspace
>Affects Versions: 3.5.2, 3.6.1, 3.6.2, 3.6.3
>Reporter: Tom Kiemes
>Assignee: Michael Osipov
>Priority: Major
>
> We would like to pass a [version
> range|https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html] to
> the parent which should be possible since 3.5.0
> At the same time, we would like to use [CI friendly
> versions|https://maven.apache.org/maven-ci-friendly.html] for the artifact
> itself.
> Both on their own work well, but combined they don't.
> {{}}
> {{http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> }}{{xsi:schemaLocation="[http://maven.apache.org/POM/4.0.0]
> [http://maven.apache.org/xsd/maven-4.0.0.xsd];>}}
> {{ 4.0.0}}
> {{ }}
> {{ org.springframework.boot}}
> {{ spring-boot-starter-parent}}
> {{ [2.1,3.0)}}
> {{ }}
> {{ com.example}}
> {{ test}}
> {{ ${revision}}}
> {{ pom}}
> {{ }}
> {{ 0.0.1}}
> {{ }}
> {{}}
>
> The resulting error is:
> {{The project com.example:test:${revision} (/Users/d045390/scratch/test.pom)
> has 1 error}}
> {{[ERROR] Version must be a constant @ line 13, column 12}}
>
> Changing the version range of the parent to a fixed version e.g.
> \{{2.1.5.Release}}, building works.
> Changing the artifact version from ${revision} to a fixed version e.g. 0.0.1
> without using the {{properties}} works as well.
> So it somehow must be the combination of both features which are actually not
> really related or am I missing something?
> PS: I left the modules out for abbreviation purpose. The pom itself can still
> be used to reproduced
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MNG-6727) Using version range in parent and CI Friendly Version fails
[
https://issues.apache.org/jira/browse/MNG-6727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6727:
Fix Version/s: 4.0.x-candidate
> Using version range in parent and CI Friendly Version fails
> ---
>
> Key: MNG-6727
> URL: https://issues.apache.org/jira/browse/MNG-6727
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation, POM, Reactor and Workspace
>Affects Versions: 3.5.2, 3.6.1, 3.6.2, 3.6.3
>Reporter: Tom Kiemes
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.x-candidate, 3.8.x-candidate
>
>
> We would like to pass a [version
> range|https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html] to
> the parent which should be possible since 3.5.0
> At the same time, we would like to use [CI friendly
> versions|https://maven.apache.org/maven-ci-friendly.html] for the artifact
> itself.
> Both on their own work well, but combined they don't.
> {{}}
> {{http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> }}{{xsi:schemaLocation="[http://maven.apache.org/POM/4.0.0]
> [http://maven.apache.org/xsd/maven-4.0.0.xsd];>}}
> {{ 4.0.0}}
> {{ }}
> {{ org.springframework.boot}}
> {{ spring-boot-starter-parent}}
> {{ [2.1,3.0)}}
> {{ }}
> {{ com.example}}
> {{ test}}
> {{ ${revision}}}
> {{ pom}}
> {{ }}
> {{ 0.0.1}}
> {{ }}
> {{}}
>
> The resulting error is:
> {{The project com.example:test:${revision} (/Users/d045390/scratch/test.pom)
> has 1 error}}
> {{[ERROR] Version must be a constant @ line 13, column 12}}
>
> Changing the version range of the parent to a fixed version e.g.
> \{{2.1.5.Release}}, building works.
> Changing the artifact version from ${revision} to a fixed version e.g. 0.0.1
> without using the {{properties}} works as well.
> So it somehow must be the combination of both features which are actually not
> really related or am I missing something?
> PS: I left the modules out for abbreviation purpose. The pom itself can still
> be used to reproduced
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MNG-7379) SNAPSHOT versions of Custom rules appear to only come from repository.apache.org
[
https://issues.apache.org/jira/browse/MNG-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466548#comment-17466548
]
Michael Osipov edited comment on MNG-7379 at 12/30/21, 4:21 PM:
Here is your problem:
{noformat}
[DEBUG] Repositories (plugins) : [shib-thirdparty
(https://build.shibboleth.net/maven/thirdparty/, default, releases),
shib-releases (https://build.shibboleth.net/maven/releases/, default,
releases), shib-release
{noformat}
A plugin is not a dependency. Therefore, any plugin dependency well go through
a plugin repository. There is none for snapshots.
was (Author: michael-o):
Here is your problem:
{noformat}
[DEBUG] Repositories (plugins) : [shib-thirdparty
(https://build.shibboleth.net/maven/thirdparty/, default, releases),
shib-releases (https://build.shibboleth.net/maven/releases/, default,
releases), shib-release
{noformat}
A plugin is not a dependency. Therefore, any plugin dependency well go through
a plugin dependency. There is none for snapshots.
> SNAPSHOT versions of Custom rules appear to only come from
> repository.apache.org
>
>
> Key: MNG-7379
> URL: https://issues.apache.org/jira/browse/MNG-7379
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.8.4
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: C:\Program Files (x86)\apache-maven-3.6.1\bin\..
> Java version: 11.0.3, vendor: Amazon.com Inc., runtime: C:\Program
> Files\Java\jdk11.0.3
> Default locale: en_GB, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Rod Widdowson
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: RELEASE.TXT, SNAPSHOT.TXT
>
>
> We use a customer build enforcer in our build & CI process.
> It is configured in the canonical fashion
> {code:java}
>
> org.apache.maven.plugins
> maven-enforcer-plugin
>
>
> net.shibboleth.maven.enforcer.rules
> maven-dist-enforcer
> 3.0.0
>
>
>
> . {code}
> This collects the plugin from our repositories as defined with
> {{}}
> I recently wanted to start running from a SNAPSHOT version. If I build this
> locally everything works fine. But if I delete it from my local repository
> and start again it appears (from watching the denug outto want to only load
> the enforcer plugin from {{repository.apache.org}}
> This feels like a bug but I may have missed some configuration somewhere.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MNG-7379) SNAPSHOT versions of Custom rules appear to only come from repository.apache.org
[
https://issues.apache.org/jira/browse/MNG-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-7379.
---
Fix Version/s: (was: waiting-for-feedback)
(was: wontfix-candidate)
Resolution: Information Provided
> SNAPSHOT versions of Custom rules appear to only come from
> repository.apache.org
>
>
> Key: MNG-7379
> URL: https://issues.apache.org/jira/browse/MNG-7379
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.8.4
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: C:\Program Files (x86)\apache-maven-3.6.1\bin\..
> Java version: 11.0.3, vendor: Amazon.com Inc., runtime: C:\Program
> Files\Java\jdk11.0.3
> Default locale: en_GB, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Rod Widdowson
>Priority: Major
> Attachments: RELEASE.TXT, SNAPSHOT.TXT
>
>
> We use a customer build enforcer in our build & CI process.
> It is configured in the canonical fashion
> {code:java}
>
> org.apache.maven.plugins
> maven-enforcer-plugin
>
>
> net.shibboleth.maven.enforcer.rules
> maven-dist-enforcer
> 3.0.0
>
>
>
> . {code}
> This collects the plugin from our repositories as defined with
> {{}}
> I recently wanted to start running from a SNAPSHOT version. If I build this
> locally everything works fine. But if I delete it from my local repository
> and start again it appears (from watching the denug outto want to only load
> the enforcer plugin from {{repository.apache.org}}
> This feels like a bug but I may have missed some configuration somewhere.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MNG-7038) Introduce public property to point to a root directory of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466930#comment-17466930
]
Michael Osipov edited comment on MNG-7038 at 12/30/21, 4:20 PM:
I need to correct myself, {{root} is not good since {{parent}} may point to a
project outside of the reactor (parent downloaded from repo}}. Some plugins
have a property called {{runOnlyAtExecutionRoot}}. Maybe
{{project.executionRoot}} is a better term for this?!
was (Author: michael-o):
I need to correct myself, {{root} is not good since {{parent}} may point to a
project outside of the reactor (parent downloaded from repo}}. Some plugins
have a property called {{runOnlyAtExecutionRoot}}. Maybe
{{project.executionRoot}} is a better term for this.
> Introduce public property to point to a root directory of (multi-module)
> project
>
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> This is a request to expose a property *maven.multiModuleProjectDirectory*
> which is currently internal (or introduce a brand new one with analogous
> functionality).
> * For a single-module project, its value should be same as *project.basedir*
> * For multi-module project, its value should point to a project.basedir of a
> root module
> Example:
> multi-module // located at /home/me/sources
> +- module-a
> +- module B
> Sample multi-module/pom.xml:
> {{}}
> {{ }}
> {{ com.acme}}
> {{ corp-parent}}
> {{ 1.0.0-RELEASE}}
> {{ }}
> {{ com.acme}}
> {{ multi-module}}
> {{ 0.5.2-SNAPSHOT}}
> {{ }}
> {{ module-a}}
> {{ module-b}}
> {{ }}
> {{}}
> The property requested should return /home/me/sources/multi-module,
> regardless of whether it's referenced in any of the child modules (module-a,
> module-b) or in multi-module.
> Note that multi-module itself has parent (e.g. installed in a local
> repository), so the new property should be smart enough to detect it and
> still point to /home/me/sources/multi-module instead of the local repository
> where the corp-parent is installed.
> The use-case for such a property could be to have a directory for combined
> report of static analysis tools. Typical example - jacoco combined coverage
> reports.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7379) SNAPSHOT versions of Custom rules appear to only come from repository.apache.org
[
https://issues.apache.org/jira/browse/MNG-7379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466931#comment-17466931
]
Rod Widdowson commented on MNG-7379:
:facepalm:
Thanks for spending your time chasing up that (incredibly obvious) thing.
> SNAPSHOT versions of Custom rules appear to only come from
> repository.apache.org
>
>
> Key: MNG-7379
> URL: https://issues.apache.org/jira/browse/MNG-7379
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.8.4
> Environment: Apache Maven 3.6.3
> (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: C:\Program Files (x86)\apache-maven-3.6.1\bin\..
> Java version: 11.0.3, vendor: Amazon.com Inc., runtime: C:\Program
> Files\Java\jdk11.0.3
> Default locale: en_GB, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Rod Widdowson
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: RELEASE.TXT, SNAPSHOT.TXT
>
>
> We use a customer build enforcer in our build & CI process.
> It is configured in the canonical fashion
> {code:java}
>
> org.apache.maven.plugins
> maven-enforcer-plugin
>
>
> net.shibboleth.maven.enforcer.rules
> maven-dist-enforcer
> 3.0.0
>
>
>
> . {code}
> This collects the plugin from our repositories as defined with
> {{}}
> I recently wanted to start running from a SNAPSHOT version. If I build this
> locally everything works fine. But if I delete it from my local repository
> and start again it appears (from watching the denug outto want to only load
> the enforcer plugin from {{repository.apache.org}}
> This feels like a bug but I may have missed some configuration somewhere.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7038) Introduce public property to point to a root directory of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466930#comment-17466930
]
Michael Osipov commented on MNG-7038:
-
I need to correct myself, {{root} is not good since {{parent}} may point to a
project outside of the reactor (parent downloaded from repo}}. Some plugins
have a property called {{runOnlyAtExecutionRoot}}. Maybe
{{project.executionRoot}} is a better term for this.
> Introduce public property to point to a root directory of (multi-module)
> project
>
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> This is a request to expose a property *maven.multiModuleProjectDirectory*
> which is currently internal (or introduce a brand new one with analogous
> functionality).
> * For a single-module project, its value should be same as *project.basedir*
> * For multi-module project, its value should point to a project.basedir of a
> root module
> Example:
> multi-module // located at /home/me/sources
> +- module-a
> +- module B
> Sample multi-module/pom.xml:
> {{}}
> {{ }}
> {{ com.acme}}
> {{ corp-parent}}
> {{ 1.0.0-RELEASE}}
> {{ }}
> {{ com.acme}}
> {{ multi-module}}
> {{ 0.5.2-SNAPSHOT}}
> {{ }}
> {{ module-a}}
> {{ module-b}}
> {{ }}
> {{}}
> The property requested should return /home/me/sources/multi-module,
> regardless of whether it's referenced in any of the child modules (module-a,
> module-b) or in multi-module.
> Note that multi-module itself has parent (e.g. installed in a local
> repository), so the new property should be smart enough to detect it and
> still point to /home/me/sources/multi-module instead of the local repository
> where the corp-parent is installed.
> The use-case for such a property could be to have a directory for combined
> report of static analysis tools. Typical example - jacoco combined coverage
> reports.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] michael-o commented on pull request #427: [MNG-6727] Changed expression check to project.version and project.parent.version
michael-o commented on pull request #427:
URL: https://github.com/apache/maven/pull/427#issuecomment-1003094540
Just tried `${pom.version}` with `help:evaluate`, this must be also tested.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Assigned] (MRESOLVER-233) Make org.e.a.artifact.AbstractArtifact.newInstance() protected abstract
[
https://issues.apache.org/jira/browse/MRESOLVER-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MRESOLVER-233:
Assignee: Michael Osipov
> Make org.e.a.artifact.AbstractArtifact.newInstance() protected abstract
> ---
>
> Key: MRESOLVER-233
> URL: https://issues.apache.org/jira/browse/MRESOLVER-233
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Affects Versions: 1.7.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.8.0
>
>
> This method has two issues:
> * It lacks abstraction that it relies on a subtype which should be unknown
> here
> * with an abstract method every derived type can properly return again a
> derived type instead of having {{DefaultArtifact}} which loses details.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MNG-7374) Mutating RelocatedArtifact does not retain type
[
https://issues.apache.org/jira/browse/MNG-7374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-7374.
---
Resolution: Fixed
Fixed with
[46d57bdb3f54feb45d0ab22a255b9bcc6b704a27|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=46d57bdb3f54feb45d0ab22a255b9bcc6b704a27]
and with
[ef74a62451684c8c60cc9db4b6720c8edb89a165|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=ef74a62451684c8c60cc9db4b6720c8edb89a165]
for {{maven-3.8.x}} branch.
> Mutating RelocatedArtifact does not retain type
> ---
>
> Key: MNG-7374
> URL: https://issues.apache.org/jira/browse/MNG-7374
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.8.4
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.5
>
>
> When a {{RelocatedArtifact}} is provided a new version, file or properties,
> this impl relies on {{AbstractArtifact}} to create a new instance.
> Unfortunately, this uses {{DefaultArtifact}} and the original information of
> relocation is lost. This likely applies to all non-abstract impls except
> {{DefaultArtifact}}.
> {{RelocatedArtifact}} should be retained with these operations.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] asfgit merged pull request #641: [MNG-7374] Mutating RelocatedArtifact does not retain type
asfgit merged pull request #641: URL: https://github.com/apache/maven/pull/641 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] asfgit closed pull request #641: [MNG-7374] Mutating RelocatedArtifact does not retain type
asfgit closed pull request #641: URL: https://github.com/apache/maven/pull/641 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] findepi commented on pull request #407: [SUREFIRE-1967] Fix parallel test ordering to prevent high resource consumption
findepi commented on pull request #407: URL: https://github.com/apache/maven-surefire/pull/407#issuecomment-1003083429 The build was failing because i added an execution with TestNG 5.13, which happens not to work under JDK 17. This should be fixed now. @slawekjaranowski can you please let the build run again? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] michael-o opened a new pull request #143: [MRESOLVER-233] Make org.e.a.artifact.AbstractArtifact.newInstance() …
michael-o opened a new pull request #143: URL: https://github.com/apache/maven-resolver/pull/143 …protected abstract -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-compiler-plugin] slachiewicz merged pull request #80: Bump mockito-core from 4.1.0 to 4.2.0
slachiewicz merged pull request #80: URL: https://github.com/apache/maven-compiler-plugin/pull/80 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-compiler-plugin] dependabot[bot] opened a new pull request #80: Bump mockito-core from 4.1.0 to 4.2.0
dependabot[bot] opened a new pull request #80: URL: https://github.com/apache/maven-compiler-plugin/pull/80 Bumps [mockito-core](https://github.com/mockito/mockito) from 4.1.0 to 4.2.0. Release notes Sourced from https://github.com/mockito/mockito/releases;>mockito-core's releases. v4.2.0 Changelog generated by https://github.com/shipkit/shipkit-changelog;>Shipkit Changelog Gradle Plugin 4.2.0 2021-12-16 - https://github.com/mockito/mockito/compare/v4.1.0...v4.2.0;>21 commit(s) by Liam Miller-Cushon, Rafael Winterhalter, Tim van der Lippe, dependabot[bot], temp-droid Update ByteBuddy to 1.12.4 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2515;>#2515)](https://github-redirect.dependabot.com/mockito/mockito/pull/2515;>mockito/mockito#2515) Bump kotlinVersion from 1.6.0 to 1.6.10 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2514;>#2514)](https://github-redirect.dependabot.com/mockito/mockito/pull/2514;>mockito/mockito#2514) Add DoNotMock mention to main JavaDoc [(https://github-redirect.dependabot.com/mockito/mockito/issues/2512;>#2512)](https://github-redirect.dependabot.com/mockito/mockito/pull/2512;>mockito/mockito#2512) Replace ExpectedException in MissingInvocationInOrderCheckerTest [(https://github-redirect.dependabot.com/mockito/mockito/issues/2511;>#2511)](https://github-redirect.dependabot.com/mockito/mockito/pull/2511;>mockito/mockito#2511) Update Gradle to version 7.3.1 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2509;>#2509)](https://github-redirect.dependabot.com/mockito/mockito/pull/2509;>mockito/mockito#2509) Fixes https://github-redirect.dependabot.com/mockito/mockito/issues/2497;>#2497: Throw exception on invalid matchers for mockStatic [(https://github-redirect.dependabot.com/mockito/mockito/issues/2506;>#2506)](https://github-redirect.dependabot.com/mockito/mockito/pull/2506;>mockito/mockito#2506) Make sure interface types are initialized before inline mocking to avoid blocking code of static initializers. [(https://github-redirect.dependabot.com/mockito/mockito/issues/2505;>#2505)](https://github-redirect.dependabot.com/mockito/mockito/pull/2505;>mockito/mockito#2505) Bump org.eclipse.osgi from 3.17.0 to 3.17.100 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2504;>#2504)](https://github-redirect.dependabot.com/mockito/mockito/pull/2504;>mockito/mockito#2504) Bump com.diffplug.spotless from 6.0.2 to 6.0.4 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2501;>#2501)](https://github-redirect.dependabot.com/mockito/mockito/pull/2501;>mockito/mockito#2501) Bump com.diffplug.spotless from 6.0.1 to 6.0.2 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2498;>#2498)](https://github-redirect.dependabot.com/mockito/mockito/pull/2498;>mockito/mockito#2498) ArgumentMatchers not working for Mockito.mockStatic [(https://github-redirect.dependabot.com/mockito/mockito/issues/2497;>#2497)](https://github-redirect.dependabot.com/mockito/mockito/issues/2497;>mockito/mockito#2497) Bump versions.bytebuddy from 1.12.2 to 1.12.3 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2496;>#2496)](https://github-redirect.dependabot.com/mockito/mockito/pull/2496;>mockito/mockito#2496) Bump com.diffplug.spotless from 6.0.0 to 6.0.1 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2495;>#2495)](https://github-redirect.dependabot.com/mockito/mockito/pull/2495;>mockito/mockito#2495) Remove the recommendation to import ArgumentMatchers methods using Mockito [(https://github-redirect.dependabot.com/mockito/mockito/issues/2494;>#2494)](https://github-redirect.dependabot.com/mockito/mockito/pull/2494;>mockito/mockito#2494) Bump versions.junitJupiter from 5.8.1 to 5.8.2 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2491;>#2491)](https://github-redirect.dependabot.com/mockito/mockito/pull/2491;>mockito/mockito#2491) Bump junit-platform-launcher from 1.8.1 to 1.8.2 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2490;>#2490)](https://github-redirect.dependabot.com/mockito/mockito/pull/2490;>mockito/mockito#2490) Fix typo 'DoNoMock' should be 'DoNotMock' [(https://github-redirect.dependabot.com/mockito/mockito/issues/2487;>#2487)](https://github-redirect.dependabot.com/mockito/mockito/pull/2487;>mockito/mockito#2487) Bump biz.aQute.bnd.gradle from 6.0.0 to 6.1.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2486;>#2486)](https://github-redirect.dependabot.com/mockito/mockito/pull/2486;>mockito/mockito#2486) Bump biz.aQute.bnd.builder from 6.0.0 to 6.1.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2485;>#2485)](https://github-redirect.dependabot.com/mockito/mockito/pull/2485;>mockito/mockito#2485) Bump versions.bytebuddy from 1.12.1 to 1.12.2
[jira] [Commented] (MNG-7047) Validate that repo configuration does not contain any expression
[ https://issues.apache.org/jira/browse/MNG-7047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466897#comment-17466897 ] Hudson commented on MNG-7047: - Build succeeded in Jenkins: Maven » Maven TLP » maven » master #302 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/302/ > Validate that repo configuration does not contain any expression > > > Key: MNG-7047 > URL: https://issues.apache.org/jira/browse/MNG-7047 > Project: Maven > Issue Type: Improvement > Components: Inheritance and Interpolation >Affects Versions: 3.6.3 >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0, 4.0.0-alpha-1 > > > MNG-7046 reverts the option to allow expressions in the repository > configuration. This should be secured in the ModelValidator to prevent > regression in the future. > As of Maven 4 expressions in the repository will fail the build. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] hboutemy commented on pull request #641: [MNG-7374] Mutating RelocatedArtifact does not retain type
hboutemy commented on pull request #641: URL: https://github.com/apache/maven/pull/641#issuecomment-1003050980 @michael-o no problem to do the work in 2 steps, sure -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] pzygielo commented on a change in pull request #646: [MNG-7377] - ignore .vscode directories
pzygielo commented on a change in pull request #646: URL: https://github.com/apache/maven/pull/646#discussion_r776253734 ## File path: .gitignore ## @@ -15,3 +15,4 @@ out/ .java-version .checkstyle .factorypath +.vscode/ Review comment: This should go to global git config, not here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MRESOLVER-233) Make org.e.a.artifact.AbstractArtifact.newInstance() protected abstract
Michael Osipov created MRESOLVER-233:
Summary: Make org.e.a.artifact.AbstractArtifact.newInstance()
protected abstract
Key: MRESOLVER-233
URL: https://issues.apache.org/jira/browse/MRESOLVER-233
Project: Maven Resolver
Issue Type: Task
Components: Resolver
Affects Versions: 1.7.3
Reporter: Michael Osipov
Fix For: 1.8.0
This method has two issues:
* It lacks abstraction that it relies on a subtype which should be unknown here
* with an abstract method every derived type can properly return again a
derived type instead of having {{DefaultArtifact}} which loses details.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven] michael-o commented on pull request #641: [MNG-7374] Mutating RelocatedArtifact does not retain type
michael-o commented on pull request #641: URL: https://github.com/apache/maven/pull/641#issuecomment-1003048363 https://issues.apache.org/jira/browse/MRESOLVER-233 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] michael-o commented on pull request #641: [MNG-7374] Mutating RelocatedArtifact does not retain type
michael-o commented on pull request #641: URL: https://github.com/apache/maven/pull/641#issuecomment-1003047327 @hboutemy Any objections to merge this one and resolve in general with new issues? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MNG-7377) Add .vscode/ to .gitignore
[ https://issues.apache.org/jira/browse/MNG-7377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-7377. --- Resolution: Done > Add .vscode/ to .gitignore > -- > > Key: MNG-7377 > URL: https://issues.apache.org/jira/browse/MNG-7377 > Project: Maven > Issue Type: Task >Reporter: Jeff Hodges >Assignee: Michael Osipov >Priority: Major > > vscode adds a `.vscode` directory to the top of a git repo it's opened in. > This is harmless, but the apache-rat plugin configured in the maven's > top-level `pom.xml` sounds the alarm on it and doesn't even allow the code to > compile. That means anyone reading maven's code in vscode will have a failing > build > I've got a patch I'll post that ignores the `.vscode` dir in the rat's config > and in `.gitignore`. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] asfgit closed pull request #646: [MNG-7377] - ignore .vscode directories
asfgit closed pull request #646: URL: https://github.com/apache/maven/pull/646 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7377) Add .vscode/ to .gitignore
[ https://issues.apache.org/jira/browse/MNG-7377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7377: Summary: Add .vscode/ to .gitignore (was: Reading code in vscode causes maven's Apache Rat config to alarm) > Add .vscode/ to .gitignore > -- > > Key: MNG-7377 > URL: https://issues.apache.org/jira/browse/MNG-7377 > Project: Maven > Issue Type: Task >Reporter: Jeff Hodges >Assignee: Michael Osipov >Priority: Major > > vscode adds a `.vscode` directory to the top of a git repo it's opened in. > This is harmless, but the apache-rat plugin configured in the maven's > top-level `pom.xml` sounds the alarm on it and doesn't even allow the code to > compile. That means anyone reading maven's code in vscode will have a failing > build > I've got a patch I'll post that ignores the `.vscode` dir in the rat's config > and in `.gitignore`. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MNG-7377) Reading code in vscode causes maven's Apache Rat config to alarm
[ https://issues.apache.org/jira/browse/MNG-7377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7377: Issue Type: Task (was: Bug) > Reading code in vscode causes maven's Apache Rat config to alarm > > > Key: MNG-7377 > URL: https://issues.apache.org/jira/browse/MNG-7377 > Project: Maven > Issue Type: Task >Reporter: Jeff Hodges >Assignee: Michael Osipov >Priority: Major > > vscode adds a `.vscode` directory to the top of a git repo it's opened in. > This is harmless, but the apache-rat plugin configured in the maven's > top-level `pom.xml` sounds the alarm on it and doesn't even allow the code to > compile. That means anyone reading maven's code in vscode will have a failing > build > I've got a patch I'll post that ignores the `.vscode` dir in the rat's config > and in `.gitignore`. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (MNG-7377) Reading code in vscode causes maven's Apache Rat config to alarm
[ https://issues.apache.org/jira/browse/MNG-7377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MNG-7377: --- Assignee: Michael Osipov > Reading code in vscode causes maven's Apache Rat config to alarm > > > Key: MNG-7377 > URL: https://issues.apache.org/jira/browse/MNG-7377 > Project: Maven > Issue Type: Bug >Reporter: Jeff Hodges >Assignee: Michael Osipov >Priority: Major > > vscode adds a `.vscode` directory to the top of a git repo it's opened in. > This is harmless, but the apache-rat plugin configured in the maven's > top-level `pom.xml` sounds the alarm on it and doesn't even allow the code to > compile. That means anyone reading maven's code in vscode will have a failing > build > I've got a patch I'll post that ignores the `.vscode` dir in the rat's config > and in `.gitignore`. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7378) neither the Core IT link in PR template nor contributor's guide tells new contributors how to run Core IT
[ https://issues.apache.org/jira/browse/MNG-7378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466878#comment-17466878 ] Michael Osipov commented on MNG-7378: - You are right. Please propose a PR for the improvement you seem appropriate. > neither the Core IT link in PR template nor contributor's guide tells new > contributors how to run Core IT > - > > Key: MNG-7378 > URL: https://issues.apache.org/jira/browse/MNG-7378 > Project: Maven > Issue Type: Bug >Reporter: Jeff Hodges >Priority: Major > > There's a checkbox in the new pull request template for the maven repo that > says the contributor should run the Core ITs. > However, the page it links to doesn't say where to find them and the obvious > thing to do (running `mvn clean test -Prun-its` in the maven repo proper) > doesn't work because there's no `run-its` profile. > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MRESOLVER-228) Improve the maven dependency resolution speed by a skip & reconcile approach
[
https://issues.apache.org/jira/browse/MRESOLVER-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466874#comment-17466874
]
Michael Osipov commented on MRESOLVER-228:
--
Related issues: MNG-5988, MNG-5761, MNG-6357
> Improve the maven dependency resolution speed by a skip & reconcile approach
>
>
> Key: MRESOLVER-228
> URL: https://issues.apache.org/jira/browse/MRESOLVER-228
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 1.7.2
>Reporter: wei cai
>Priority: Major
> Fix For: 1.8.0
>
> Attachments: Screen Shot 2021-11-27 at 12.58.26 PM.png, Screen Shot
> 2021-11-27 at 12.58.59 PM.png, Screen Shot 2021-11-27 at 12.59.32 PM.png
>
>
> When comes to resolve the huge amount of dependencies of an enterprise level
> project, the maven resolver is very slow to resolve the dependency
> graph/tree. Take one of our app as example, it could take *10minutes+ and 16G
> memory* to print out the result of {*}mvn dependency:tree{*}.
> This is because there are many dependencies declared in the project, and some
> of the dependencies would introduce *600+* transitive dependencies, and
> exclusions are widely used to solve dependency conflicts.
> By checking the
> [code|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L500],
> we know the exclusion is also part of the cache key. This means when the
> exclusions up the tree differs, the cached resolution result for the same GAV
> won't be picked up and need s to be recalculated.
> !Screen Shot 2021-11-27 at 12.58.26 PM.png!
> From above figure, we know:
> * In 1st case, D will be resolved only once as there are no exclusions/same
> exclusions up the tree.
> * In 2nd case, the B and C have different exclusions and D needs to be
> recalculated, if D is a heavy dependency which introduce many transitive
> dependencies, all D and its children needs to be recalculated. Recalculating
> all of these nodes introduces 2 issues:
> ** Slow in resolving dependencies.
> ** Lots of DependencyNodes cached (all calculated/recalculated nodes would
> be cached) and will consume huge memory.
> To improve the speed of maven resolver's dependency resolution, I
> implemented a skip & reconcile approach. Here is the *skip* part.
> !Screen Shot 2021-11-27 at 12.58.59 PM.png!
> From above figure, the 1st R is resolved at depth 3, and the 2nd R is
> resolved again because the depth is at 2 which is lower, the 3rd R at depth 3
> and the 4th R at depth 4 are simply skipped as R is already resolved at depth
> 2. This is because the same node with deeper depth is most likely won't be
> picked up by maven as maven employs a "{*}nearest{*} transitive dependency in
> the tree depth and the *first* in resolution" strategy.
> The 3rd R and 4th R will have children set as zero and marked as skipped by
> the R at depth 2 in 2nd tree path.
>
> Here is the *reconcile* part:
> !Screen Shot 2021-11-27 at 12.59.32 PM.png!
> When there are dependency conflicts, some of the skipped nodes need to be
> reconciled.
> In above figure, there are 4 tree paths.
> * The D1 (D with version 1) in the 1st tree path is get resolved, children
> of E and R at depth 3 are resolved and cached.
> * In the 2nd tree path, when resolving E & R of H, we simply skip these 2
> nodes as they are in deeper depth (depth: 4) than the E & R in 1st tree path.
> * In the 3rd tree path, a R node with lower path is resolved, and a E node
> at depth 5 is skipped.
> * In the 4th path, a D2 (D with version 2) node is resolved, as the depth is
> lower than D1, so maven will pick D2, this means the E & R's children cached
> in tree depth 1 should be {*}discarded{*}.
> Thus we might need to reconcile the E & R nodes in 2nd, 3rd and 4th tree
> paths. Here only E in 2nd tree path needs to be reconciled. This is because:
> * R in 3rd tree path won't be picked up as there is already a R in 2nd tree
> path with a lower depth.
> * E in 3rd tree path won't be picked up as it is enough to reconcile the E
> in 2nd tree path as the E in 2nd tree path is deeper than E in 3rd tree path.
> Here is what we've updated in the maven-resolver logic:
> # Resolve dependencies by leveraging a skip approach. The node in deeper
> depth will be skipped if a node with same GAV has been resolved with a lower
> depth.
> # Cloned the nodes in step 1.
> Use maven's ConflictResolver (Transformer) to transform the cloned nodes and
> find out the conflict winners & the nodes to reconcile.
> Ex, D1 conflicts with D2 in above digram.
> E in 2nd tree path will be reconciled.
> # Reconcile all skipped nodes identified in
[jira] [Commented] (MNG-7050) Create M2_REPOSITORY env variable for Local Repository and Wrapper locations
[
https://issues.apache.org/jira/browse/MNG-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466873#comment-17466873
]
Michael Osipov commented on MNG-7050:
-
A new wrapper is out, try it. {{MAVEN_ARGS}} has been delivered, try it as
well. I think both will solve your problem.
> Create M2_REPOSITORY env variable for Local Repository and Wrapper locations
>
>
> Key: MNG-7050
> URL: https://issues.apache.org/jira/browse/MNG-7050
> Project: Maven
> Issue Type: Improvement
> Components: Core, Maven Wrapper, Settings
>Affects Versions: 3.6.3
>Reporter: Manuel Jordan
>Priority: Minor
> Labels: features
> Fix For: waiting-for-feedback
>
>
> I need do mention about Gradle to understand and find the same solution or
> approach for Maven.
> In Gradle exists the {{GRADLE_HOME}} and {{GRADLE_USER_HOME}} (repository)
> _environment variables_, for Maven the former through {{M2_HOME}} and about
> the _repository_ I use the {{settings.xml}} file to define the
> {{}} location
> For both Maven and Gradle I can define in peace the place about where is
> installed the software, for example other location than {{.m2}} and
> {{.gradle}} to a secondary disk and even with customized directory names.
> Same goal about the repository location, both for a secondary disk (remember
> for Maven through the {{settings.xml}} file)
> *Note*: therefore {{.gradle}} and {{.m2}} are empty and not used.
> In Gradle about the wrapper created, the {{gradle-wrapper.properties}} file
> has:
>
> {code:java}
> distributionBase=GRADLE_USER_HOME
> distributionPath=wrapper/dists
> distributionUrl=https\://services.gradle.org/distributions/gradle-#.#.#-bin.zip
> zipStoreBase=GRADLE_USER_HOME
> zipStorePath=wrapper/dists
> {code}
> Then the final path is: {{GRADLE_USER_HOME/wrapper/dists}}
> Therefore observe how {{GRADLE_USER_HOME}} (custom location - otherwise
> {{.gradle}} by default) is used to define the:
> * Local repository
> * Base path to install the downloaded Gradle through the wrapper
> *New Improvement*: Add for Maven an environment variable named M2_REPOSITORY
> for the _Local Repository_ and _Wrapper Installation_ locations that Maven
> should recognize automatically (*not* using the {{settings.xml}} file).
> It with the purpose to have any Maven wrapper(s) installed according to that
> _environment variable_ value (custom location - otherwise {{.m2}} by default)
> and of course applied for the Local Repository location too.
> *Observation*: If the {{settings.xml}} file exists it should override the
> M2_REPOSITORY value.
> *Therefore*: I need the {{maven-wrapper.properties}} using something like
> {{M2_REPOSITORY}} (custom location - otherwise {{.m2}} by default) according
> the developer/user in its machine.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Moved] (MWRAPPER-48) Error "}" was unexpected at this time (Windows 10)
[
https://issues.apache.org/jira/browse/MWRAPPER-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov moved MNG-7140 to MWRAPPER-48:
-
Component/s: Maven Wrapper Scripts
(was: Maven Wrapper)
Key: MWRAPPER-48 (was: MNG-7140)
Project: Maven Wrapper (was: Maven)
> Error "}" was unexpected at this time (Windows 10)
> --
>
> Key: MWRAPPER-48
> URL: https://issues.apache.org/jira/browse/MWRAPPER-48
> Project: Maven Wrapper
> Issue Type: Bug
> Components: Maven Wrapper Scripts
>Reporter: Valentin Despa
>Priority: Major
> Attachments: demo.zip, not-working.png, working.png
>
>
> I have generated a simple project using the Spring Initializr. If I try to
> run the Maven wrapper from a workspace folder within Jenkins, the following
> error occurs:
> {{"}" was unexpected at this time}}
> If I copy the project folder and run it from a different location, it works
> with no issues.
> A similar issue has been reported on Stackoverflow as well:
> [https://stackoverflow.com/q/62028432/766177]
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7088) A property which always points to pom.xml own directory
[
https://issues.apache.org/jira/browse/MNG-7088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466871#comment-17466871
]
Michael Osipov commented on MNG-7088:
-
Still waiting for response.
> A property which always points to pom.xml own directory
> ---
>
> Key: MNG-7088
> URL: https://issues.apache.org/jira/browse/MNG-7088
> Project: Maven
> Issue Type: New Feature
>Affects Versions: 3.6.3
>Reporter: Monkey
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Maven docs say that ${project.basedir} points to the directory containing the
> pom.xml file, but does not say, which pom.xml file. As it turns out in the
> example below, it can be the file in the directory where mvn is called, and
> not really the file where the property is used.
> If the problems as the one below cannot be resolved cleanly, would adding a
> property, which always points to pom.xml own directory, help?
> I am sorry for the formatting, it is the system which puts new paragraphs and
> brackets for whatever reason.
> I have a Maven child project in a directory "child". I have also a parent
> project "local-lib" in the directory "child/local-lib" which contains a
> repository with jars. The repository is declared in "child/local-lib/pom.xml"
> as
> {code:xml}
>
>
> repo
> [file:///$]}}{{{project.basedir}/repo
>
>
> {code}
>
> The child project has "child/pom.xml" where it refers to its parent as
> follows:
>
> {code:xml}
>
> someGroup
> local-lib
> 0.0.1
> ./local-lib
>
> {code}
>
> When I type "mvn clean install" in the child project, that is, in the
> directory "child", the child project attempts to search for a non-existing
> repository "child/repo", instead of "child/local-lib/repo". However,
> replacing "${project.basedir}" in "child/local-lib/pom.xml" with the full
> path to "child/local-lib" on my disk makes the child project use the correct
> repository child/local-lib/repo. This in turn, placed in
> child/local-lib/pom.xml as before, but with additional "local-lib":
>
> {code:xml}
>
>
> repo
> [file:///$]{project.basedir}/local-lib/repo
>
>
> {code}
> works this time correctly if I use maven from the directory "child", but not
> if I use directly "child/local-lib/pom.xml" from "child/local-lib". The
> latter creates a path with local-lib included twice.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-6606) Allow installation-wide parameter customization
[
https://issues.apache.org/jira/browse/MNG-6606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466866#comment-17466866
]
Michael Osipov commented on MNG-6606:
-
Still waiting for response.
> Allow installation-wide parameter customization
> ---
>
> Key: MNG-6606
> URL: https://issues.apache.org/jira/browse/MNG-6606
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Affects Versions: 3.1.1
>Reporter: Paul Benedict
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> In my use case, I would like to always print the version of Maven at every
> execution. I am not interested in a per-project case basis; nor interested in
> modifying the startup batch scripts. I want to drop in a standard
> configuration file to control all my Maven installations in the same manner.
> My request is to make {{/.mvn/maven.config}} and {{./mvn/}}{{mavenrc}} to
> also be recognized in the Maven installation root. I am not explicitly asking
> for {{${maven.root}/.mvn}} to be *the* solution, but it's the right place to
> start the problem solving.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7038) Introduce public property to point to a root directory of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466865#comment-17466865
]
Michael Osipov commented on MNG-7038:
-
I would consider that {{project.root.*}} would be most appropriate.
> Introduce public property to point to a root directory of (multi-module)
> project
>
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> This is a request to expose a property *maven.multiModuleProjectDirectory*
> which is currently internal (or introduce a brand new one with analogous
> functionality).
> * For a single-module project, its value should be same as *project.basedir*
> * For multi-module project, its value should point to a project.basedir of a
> root module
> Example:
> multi-module // located at /home/me/sources
> +- module-a
> +- module B
> Sample multi-module/pom.xml:
> {{}}
> {{ }}
> {{ com.acme}}
> {{ corp-parent}}
> {{ 1.0.0-RELEASE}}
> {{ }}
> {{ com.acme}}
> {{ multi-module}}
> {{ 0.5.2-SNAPSHOT}}
> {{ }}
> {{ module-a}}
> {{ module-b}}
> {{ }}
> {{}}
> The property requested should return /home/me/sources/multi-module,
> regardless of whether it's referenced in any of the child modules (module-a,
> module-b) or in multi-module.
> Note that multi-module itself has parent (e.g. installed in a local
> repository), so the new property should be smart enough to detect it and
> still point to /home/me/sources/multi-module instead of the local repository
> where the corp-parent is installed.
> The use-case for such a property could be to have a directory for combined
> report of static analysis tools. Typical example - jacoco combined coverage
> reports.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MRESOLVER-228) Improve the maven dependency resolution speed by a skip & reconcile approach
[
https://issues.apache.org/jira/browse/MRESOLVER-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466860#comment-17466860
]
Michael Osipov edited comment on MRESOLVER-228 at 12/30/21, 1:10 PM:
-
bq. One question is, as Ivan pointed out in MRESOLVER-133 as below, it does not
have to use a BFS strategy to solve MRESOLVER-133. Shall we still need to go to
BFS?
I think that resolving highest only should be completely decoupled from BFS.
BFS might be necessary, but resolving all versions is yet another optimization.
bq. I would keep MRESOLVER-133 out of the scope for now, as it does not seem to
be as trivial as I suggested in that comment. It also seems to change the
behavior, where as the rest only avoids unnecessary work + does the same things
in parallel.
Fully agree. Lets not mix things here.
[~ibabiankou], I fully agree with your three step plan.
Folks, if you find an alternating behavior during your work, i.e., resolution
is different then we need to discuss wether the new outcome is a consistency
bugfix or a regression. If you look at MNG, there are plenty issues related to
dependency resolution.
was (Author: michael-o):
bq. One question is, as Ivan pointed out in MRESOLVER-133 as below, it does not
have to use a BFS strategy to solve MRESOLVER-133. Shall we still need to go to
BFS?
I think that resolving highest only should be completely decoupled from BFS.
BFS might be necessary, but resolving all versions is yet another optimization.
bq. I would keep MRESOLVER-133 out of the scope for now, as it does not seem to
be as trivial as I suggested in that comment. It also seems to change the
behavior, where as the rest only avoids unnecessary work + does the same things
in parallel.
Fully agree. Lets not mix things here.
[~ibabiankou], I fully agree with your three step plan.
> Improve the maven dependency resolution speed by a skip & reconcile approach
>
>
> Key: MRESOLVER-228
> URL: https://issues.apache.org/jira/browse/MRESOLVER-228
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 1.7.2
>Reporter: wei cai
>Priority: Major
> Fix For: 1.8.0
>
> Attachments: Screen Shot 2021-11-27 at 12.58.26 PM.png, Screen Shot
> 2021-11-27 at 12.58.59 PM.png, Screen Shot 2021-11-27 at 12.59.32 PM.png
>
>
> When comes to resolve the huge amount of dependencies of an enterprise level
> project, the maven resolver is very slow to resolve the dependency
> graph/tree. Take one of our app as example, it could take *10minutes+ and 16G
> memory* to print out the result of {*}mvn dependency:tree{*}.
> This is because there are many dependencies declared in the project, and some
> of the dependencies would introduce *600+* transitive dependencies, and
> exclusions are widely used to solve dependency conflicts.
> By checking the
> [code|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L500],
> we know the exclusion is also part of the cache key. This means when the
> exclusions up the tree differs, the cached resolution result for the same GAV
> won't be picked up and need s to be recalculated.
> !Screen Shot 2021-11-27 at 12.58.26 PM.png!
> From above figure, we know:
> * In 1st case, D will be resolved only once as there are no exclusions/same
> exclusions up the tree.
> * In 2nd case, the B and C have different exclusions and D needs to be
> recalculated, if D is a heavy dependency which introduce many transitive
> dependencies, all D and its children needs to be recalculated. Recalculating
> all of these nodes introduces 2 issues:
> ** Slow in resolving dependencies.
> ** Lots of DependencyNodes cached (all calculated/recalculated nodes would
> be cached) and will consume huge memory.
> To improve the speed of maven resolver's dependency resolution, I
> implemented a skip & reconcile approach. Here is the *skip* part.
> !Screen Shot 2021-11-27 at 12.58.59 PM.png!
> From above figure, the 1st R is resolved at depth 3, and the 2nd R is
> resolved again because the depth is at 2 which is lower, the 3rd R at depth 3
> and the 4th R at depth 4 are simply skipped as R is already resolved at depth
> 2. This is because the same node with deeper depth is most likely won't be
> picked up by maven as maven employs a "{*}nearest{*} transitive dependency in
> the tree depth and the *first* in resolution" strategy.
> The 3rd R and 4th R will have children set as zero and marked as skipped by
> the R at depth 2 in 2nd tree path.
>
> Here is the *reconcile* part:
> !Screen Shot 2021-11-27 at 12.59.32 PM.png!
> When there are dependency
[jira] [Commented] (MRESOLVER-228) Improve the maven dependency resolution speed by a skip & reconcile approach
[
https://issues.apache.org/jira/browse/MRESOLVER-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466860#comment-17466860
]
Michael Osipov commented on MRESOLVER-228:
--
bq. One question is, as Ivan pointed out in MRESOLVER-133 as below, it does not
have to use a BFS strategy to solve MRESOLVER-133. Shall we still need to go to
BFS?
I think that resolving highest only should be completely decoupled from BFS.
BFS might be necessary, but resolving all versions is yet another optimization.
bq. I would keep MRESOLVER-133 out of the scope for now, as it does not seem to
be as trivial as I suggested in that comment. It also seems to change the
behavior, where as the rest only avoids unnecessary work + does the same things
in parallel.
Fully agree. Lets not mix things here.
[~ibabiankou], I fully agree with your three step plan.
> Improve the maven dependency resolution speed by a skip & reconcile approach
>
>
> Key: MRESOLVER-228
> URL: https://issues.apache.org/jira/browse/MRESOLVER-228
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 1.7.2
>Reporter: wei cai
>Priority: Major
> Fix For: 1.8.0
>
> Attachments: Screen Shot 2021-11-27 at 12.58.26 PM.png, Screen Shot
> 2021-11-27 at 12.58.59 PM.png, Screen Shot 2021-11-27 at 12.59.32 PM.png
>
>
> When comes to resolve the huge amount of dependencies of an enterprise level
> project, the maven resolver is very slow to resolve the dependency
> graph/tree. Take one of our app as example, it could take *10minutes+ and 16G
> memory* to print out the result of {*}mvn dependency:tree{*}.
> This is because there are many dependencies declared in the project, and some
> of the dependencies would introduce *600+* transitive dependencies, and
> exclusions are widely used to solve dependency conflicts.
> By checking the
> [code|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L500],
> we know the exclusion is also part of the cache key. This means when the
> exclusions up the tree differs, the cached resolution result for the same GAV
> won't be picked up and need s to be recalculated.
> !Screen Shot 2021-11-27 at 12.58.26 PM.png!
> From above figure, we know:
> * In 1st case, D will be resolved only once as there are no exclusions/same
> exclusions up the tree.
> * In 2nd case, the B and C have different exclusions and D needs to be
> recalculated, if D is a heavy dependency which introduce many transitive
> dependencies, all D and its children needs to be recalculated. Recalculating
> all of these nodes introduces 2 issues:
> ** Slow in resolving dependencies.
> ** Lots of DependencyNodes cached (all calculated/recalculated nodes would
> be cached) and will consume huge memory.
> To improve the speed of maven resolver's dependency resolution, I
> implemented a skip & reconcile approach. Here is the *skip* part.
> !Screen Shot 2021-11-27 at 12.58.59 PM.png!
> From above figure, the 1st R is resolved at depth 3, and the 2nd R is
> resolved again because the depth is at 2 which is lower, the 3rd R at depth 3
> and the 4th R at depth 4 are simply skipped as R is already resolved at depth
> 2. This is because the same node with deeper depth is most likely won't be
> picked up by maven as maven employs a "{*}nearest{*} transitive dependency in
> the tree depth and the *first* in resolution" strategy.
> The 3rd R and 4th R will have children set as zero and marked as skipped by
> the R at depth 2 in 2nd tree path.
>
> Here is the *reconcile* part:
> !Screen Shot 2021-11-27 at 12.59.32 PM.png!
> When there are dependency conflicts, some of the skipped nodes need to be
> reconciled.
> In above figure, there are 4 tree paths.
> * The D1 (D with version 1) in the 1st tree path is get resolved, children
> of E and R at depth 3 are resolved and cached.
> * In the 2nd tree path, when resolving E & R of H, we simply skip these 2
> nodes as they are in deeper depth (depth: 4) than the E & R in 1st tree path.
> * In the 3rd tree path, a R node with lower path is resolved, and a E node
> at depth 5 is skipped.
> * In the 4th path, a D2 (D with version 2) node is resolved, as the depth is
> lower than D1, so maven will pick D2, this means the E & R's children cached
> in tree depth 1 should be {*}discarded{*}.
> Thus we might need to reconcile the E & R nodes in 2nd, 3rd and 4th tree
> paths. Here only E in 2nd tree path needs to be reconciled. This is because:
> * R in 3rd tree path won't be picked up as there is already a R in 2nd tree
> path with a lower depth.
> * E in 3rd tree path won't be picked up as it is enough
[GitHub] [maven-surefire] findinpath commented on a change in pull request #407: [SUREFIRE-1967] Fix parallel test ordering to prevent high resource consumption
findinpath commented on a change in pull request #407:
URL: https://github.com/apache/maven-surefire/pull/407#discussion_r776716696
##
File path:
surefire-its/src/test/resources/surefire-1967-testng-method-parallel-ordering/pom.xml
##
@@ -0,0 +1,60 @@
+
+
+
+http://maven.apache.org/POM/4.0.0;
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
+ xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
+ 4.0.0
+
+
+org.apache.maven.surefire
+it-parent
+1.0
+../pom.xml
+
+
+ org.apache.maven.plugins.surefire
+ surefire-1967-testng-method-parallel-ordering
+ 1.0-SNAPSHOT
+ TestNG parallel ordering
+
+
+
+ org.testng
+ testng
+ ${testNgVersion}
+
+
+
+
+
+
+org.apache.maven.plugins
+maven-surefire-plugin
+${surefire.version}
+
Review comment:
I see an advantage in seeing whether we test multiple values (at least
`1` and `2` ) for the thread count.
Looking closer at `Base` class we could add a `@Before` setup and `@After`
and tear down methods to verify whether the amount of tests being executed in
parallel is indeed between `1` and the configured `threadCount`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-surefire] findepi commented on a change in pull request #407: [SUREFIRE-1967] Fix parallel test ordering to prevent high resource consumption
findepi commented on a change in pull request #407:
URL: https://github.com/apache/maven-surefire/pull/407#discussion_r776713600
##
File path:
surefire-its/src/test/resources/surefire-1967-testng-method-parallel-ordering/pom.xml
##
@@ -0,0 +1,60 @@
+
+
+
+http://maven.apache.org/POM/4.0.0;
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
+ xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
+ 4.0.0
+
+
+org.apache.maven.surefire
+it-parent
+1.0
+../pom.xml
+
+
+ org.apache.maven.plugins.surefire
+ surefire-1967-testng-method-parallel-ordering
+ 1.0-SNAPSHOT
+ TestNG parallel ordering
+
+
+
+ org.testng
+ testng
+ ${testNgVersion}
+
+
+
+
+
+
+org.apache.maven.plugins
+maven-surefire-plugin
+${surefire.version}
+
Review comment:
I understand that parameterizing threadCount would allow me to run tests
with different threadCount values. Would we actually want to run the test more
times? What additional value would it bring?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-surefire] findinpath commented on a change in pull request #407: [SUREFIRE-1967] Fix parallel test ordering to prevent high resource consumption
findinpath commented on a change in pull request #407:
URL: https://github.com/apache/maven-surefire/pull/407#discussion_r776710713
##
File path:
surefire-its/src/test/resources/surefire-1967-testng-method-parallel-ordering/pom.xml
##
@@ -0,0 +1,60 @@
+
+
+
+http://maven.apache.org/POM/4.0.0;
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
+ xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
+ 4.0.0
+
+
+org.apache.maven.surefire
+it-parent
+1.0
+../pom.xml
+
+
+ org.apache.maven.plugins.surefire
+ surefire-1967-testng-method-parallel-ordering
+ 1.0-SNAPSHOT
+ TestNG parallel ordering
+
+
+
+ org.testng
+ testng
+ ${testNgVersion}
+
+
+
+
+
+
+org.apache.maven.plugins
+maven-surefire-plugin
+${surefire.version}
+
Review comment:
You currently hardcoded the logic for checking the concurrency level in
the `Base` class to be `2`.
By using a `sysProp` for the thread count in
`Surefire1967CheckTestNgMethodParallelOrderingIT` you could test the
functionality not only with different `TestNG` versions, but also with
different `threadCount` values (serial - `1` , concurrent - `2` , and also a
greater value than the number of methods in the test suite).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-228) Improve the maven dependency resolution speed by a skip & reconcile approach
[
https://issues.apache.org/jira/browse/MRESOLVER-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466851#comment-17466851
]
Ivan Babiankou commented on MRESOLVER-228:
--
BFS is needed for the parallel artifact download, because you can only download
in parallel descriptors on the same level of the graph. It won't solve
MRESOLVER-133 because the problem that ticket want to solve is "Resolve highest
version in the range, instead resolving all versions and keeping one". We
should probably update title and description of that ticket and create separate
one for DFS > BFS.
I would keep MRESOLVER-133 out of the scope for now, as it does not seem to be
as trivial as I suggested in that comment. It also seems to change the
behavior, where as the rest only avoids unnecessary work + does the same things
in parallel.
>From what I can tell so far the outlined plan makes the most sense:
# DFS > BFS - preparation for parallel download
# Skip & Reconcile - avoid unnecessary version resolution
# Download descriptors in parallel
> Improve the maven dependency resolution speed by a skip & reconcile approach
>
>
> Key: MRESOLVER-228
> URL: https://issues.apache.org/jira/browse/MRESOLVER-228
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 1.7.2
>Reporter: wei cai
>Priority: Major
> Fix For: 1.8.0
>
> Attachments: Screen Shot 2021-11-27 at 12.58.26 PM.png, Screen Shot
> 2021-11-27 at 12.58.59 PM.png, Screen Shot 2021-11-27 at 12.59.32 PM.png
>
>
> When comes to resolve the huge amount of dependencies of an enterprise level
> project, the maven resolver is very slow to resolve the dependency
> graph/tree. Take one of our app as example, it could take *10minutes+ and 16G
> memory* to print out the result of {*}mvn dependency:tree{*}.
> This is because there are many dependencies declared in the project, and some
> of the dependencies would introduce *600+* transitive dependencies, and
> exclusions are widely used to solve dependency conflicts.
> By checking the
> [code|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L500],
> we know the exclusion is also part of the cache key. This means when the
> exclusions up the tree differs, the cached resolution result for the same GAV
> won't be picked up and need s to be recalculated.
> !Screen Shot 2021-11-27 at 12.58.26 PM.png!
> From above figure, we know:
> * In 1st case, D will be resolved only once as there are no exclusions/same
> exclusions up the tree.
> * In 2nd case, the B and C have different exclusions and D needs to be
> recalculated, if D is a heavy dependency which introduce many transitive
> dependencies, all D and its children needs to be recalculated. Recalculating
> all of these nodes introduces 2 issues:
> ** Slow in resolving dependencies.
> ** Lots of DependencyNodes cached (all calculated/recalculated nodes would
> be cached) and will consume huge memory.
> To improve the speed of maven resolver's dependency resolution, I
> implemented a skip & reconcile approach. Here is the *skip* part.
> !Screen Shot 2021-11-27 at 12.58.59 PM.png!
> From above figure, the 1st R is resolved at depth 3, and the 2nd R is
> resolved again because the depth is at 2 which is lower, the 3rd R at depth 3
> and the 4th R at depth 4 are simply skipped as R is already resolved at depth
> 2. This is because the same node with deeper depth is most likely won't be
> picked up by maven as maven employs a "{*}nearest{*} transitive dependency in
> the tree depth and the *first* in resolution" strategy.
> The 3rd R and 4th R will have children set as zero and marked as skipped by
> the R at depth 2 in 2nd tree path.
>
> Here is the *reconcile* part:
> !Screen Shot 2021-11-27 at 12.59.32 PM.png!
> When there are dependency conflicts, some of the skipped nodes need to be
> reconciled.
> In above figure, there are 4 tree paths.
> * The D1 (D with version 1) in the 1st tree path is get resolved, children
> of E and R at depth 3 are resolved and cached.
> * In the 2nd tree path, when resolving E & R of H, we simply skip these 2
> nodes as they are in deeper depth (depth: 4) than the E & R in 1st tree path.
> * In the 3rd tree path, a R node with lower path is resolved, and a E node
> at depth 5 is skipped.
> * In the 4th path, a D2 (D with version 2) node is resolved, as the depth is
> lower than D1, so maven will pick D2, this means the E & R's children cached
> in tree depth 1 should be {*}discarded{*}.
> Thus we might need to reconcile the E & R nodes in 2nd, 3rd and 4th tree
> paths. Here only E in 2nd tree path needs to
[GitHub] [maven-surefire] findepi commented on a change in pull request #407: [SUREFIRE-1967] Fix parallel test ordering to prevent high resource consumption
findepi commented on a change in pull request #407:
URL: https://github.com/apache/maven-surefire/pull/407#discussion_r776708306
##
File path:
surefire-its/src/test/resources/surefire-1967-testng-method-parallel-ordering/pom.xml
##
@@ -0,0 +1,60 @@
+
+
+
+http://maven.apache.org/POM/4.0.0;
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
+ xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
+ 4.0.0
+
+
+org.apache.maven.surefire
+it-parent
+1.0
+../pom.xml
+
+
+ org.apache.maven.plugins.surefire
+ surefire-1967-testng-method-parallel-ordering
+ 1.0-SNAPSHOT
+ TestNG parallel ordering
+
+
+
+ org.testng
+ testng
+ ${testNgVersion}
+
+
+
+
+
+
+org.apache.maven.plugins
+maven-surefire-plugin
+${surefire.version}
+
Review comment:
> The main advantage in adding this cosmetic change is that you could
easily test the behaviour with multiple values for the `threadCount`
i don't see advantage of doing this. Please help me understand.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-surefire] findinpath commented on a change in pull request #407: [SUREFIRE-1967] Fix parallel test ordering to prevent high resource consumption
findinpath commented on a change in pull request #407:
URL: https://github.com/apache/maven-surefire/pull/407#discussion_r776706980
##
File path:
surefire-its/src/test/resources/surefire-1967-testng-method-parallel-ordering/pom.xml
##
@@ -0,0 +1,60 @@
+
+
+
+http://maven.apache.org/POM/4.0.0;
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
+ xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
+ 4.0.0
+
+
+org.apache.maven.surefire
+it-parent
+1.0
+../pom.xml
+
+
+ org.apache.maven.plugins.surefire
+ surefire-1967-testng-method-parallel-ordering
+ 1.0-SNAPSHOT
+ TestNG parallel ordering
+
+
+
+ org.testng
+ testng
+ ${testNgVersion}
+
+
+
+
+
+
+org.apache.maven.plugins
+maven-surefire-plugin
+${surefire.version}
+
Review comment:
This is rather a cosmetic change proposal
`Base.java`
```
int mavenSurefireThreadCount = Integer.parseInt(System.getProperty(
"surefire.thread-count" ));
int concurrentResources = resources.incrementAndGet();
if (concurrentResources > mavenSurefireThreadCount) {
throw new IllegalStateException(String.format("Tests execute in
two threads, so there should be at most %d resources allocated, got: %d",
mavenSurefireThreadCount, concurrentResources));
}
```
`pom.xml`
```
org.apache.maven.plugins
maven-surefire-plugin
${surefire.version}
2
methods
2
```
Obviously the `2` value in `pom.xml` can be passed along (same as
`${surefire.version}`) to avoid duplication.
The main advantage in adding this cosmetic change is that you could easily
test the behaviour with multiple values for the `threadCount` (`1` , `2`, `3`
and a value greater than the number of methods being tested).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] (MRESOLVER-228) Improve the maven dependency resolution speed by a skip & reconcile approach
[ https://issues.apache.org/jira/browse/MRESOLVER-228 ]
Ivan Babiankou deleted comment on MRESOLVER-228:
--
was (Author: ibabiankou):
Didn't see the updated message... give me a sec.
> Improve the maven dependency resolution speed by a skip & reconcile approach
>
>
> Key: MRESOLVER-228
> URL: https://issues.apache.org/jira/browse/MRESOLVER-228
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 1.7.2
>Reporter: wei cai
>Priority: Major
> Fix For: 1.8.0
>
> Attachments: Screen Shot 2021-11-27 at 12.58.26 PM.png, Screen Shot
> 2021-11-27 at 12.58.59 PM.png, Screen Shot 2021-11-27 at 12.59.32 PM.png
>
>
> When comes to resolve the huge amount of dependencies of an enterprise level
> project, the maven resolver is very slow to resolve the dependency
> graph/tree. Take one of our app as example, it could take *10minutes+ and 16G
> memory* to print out the result of {*}mvn dependency:tree{*}.
> This is because there are many dependencies declared in the project, and some
> of the dependencies would introduce *600+* transitive dependencies, and
> exclusions are widely used to solve dependency conflicts.
> By checking the
> [code|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L500],
> we know the exclusion is also part of the cache key. This means when the
> exclusions up the tree differs, the cached resolution result for the same GAV
> won't be picked up and need s to be recalculated.
> !Screen Shot 2021-11-27 at 12.58.26 PM.png!
> From above figure, we know:
> * In 1st case, D will be resolved only once as there are no exclusions/same
> exclusions up the tree.
> * In 2nd case, the B and C have different exclusions and D needs to be
> recalculated, if D is a heavy dependency which introduce many transitive
> dependencies, all D and its children needs to be recalculated. Recalculating
> all of these nodes introduces 2 issues:
> ** Slow in resolving dependencies.
> ** Lots of DependencyNodes cached (all calculated/recalculated nodes would
> be cached) and will consume huge memory.
> To improve the speed of maven resolver's dependency resolution, I
> implemented a skip & reconcile approach. Here is the *skip* part.
> !Screen Shot 2021-11-27 at 12.58.59 PM.png!
> From above figure, the 1st R is resolved at depth 3, and the 2nd R is
> resolved again because the depth is at 2 which is lower, the 3rd R at depth 3
> and the 4th R at depth 4 are simply skipped as R is already resolved at depth
> 2. This is because the same node with deeper depth is most likely won't be
> picked up by maven as maven employs a "{*}nearest{*} transitive dependency in
> the tree depth and the *first* in resolution" strategy.
> The 3rd R and 4th R will have children set as zero and marked as skipped by
> the R at depth 2 in 2nd tree path.
>
> Here is the *reconcile* part:
> !Screen Shot 2021-11-27 at 12.59.32 PM.png!
> When there are dependency conflicts, some of the skipped nodes need to be
> reconciled.
> In above figure, there are 4 tree paths.
> * The D1 (D with version 1) in the 1st tree path is get resolved, children
> of E and R at depth 3 are resolved and cached.
> * In the 2nd tree path, when resolving E & R of H, we simply skip these 2
> nodes as they are in deeper depth (depth: 4) than the E & R in 1st tree path.
> * In the 3rd tree path, a R node with lower path is resolved, and a E node
> at depth 5 is skipped.
> * In the 4th path, a D2 (D with version 2) node is resolved, as the depth is
> lower than D1, so maven will pick D2, this means the E & R's children cached
> in tree depth 1 should be {*}discarded{*}.
> Thus we might need to reconcile the E & R nodes in 2nd, 3rd and 4th tree
> paths. Here only E in 2nd tree path needs to be reconciled. This is because:
> * R in 3rd tree path won't be picked up as there is already a R in 2nd tree
> path with a lower depth.
> * E in 3rd tree path won't be picked up as it is enough to reconcile the E
> in 2nd tree path as the E in 2nd tree path is deeper than E in 3rd tree path.
> Here is what we've updated in the maven-resolver logic:
> # Resolve dependencies by leveraging a skip approach. The node in deeper
> depth will be skipped if a node with same GAV has been resolved with a lower
> depth.
> # Cloned the nodes in step 1.
> Use maven's ConflictResolver (Transformer) to transform the cloned nodes and
> find out the conflict winners & the nodes to reconcile.
> Ex, D1 conflicts with D2 in above digram.
> E in 2nd tree path will be reconciled.
> # Reconcile all skipped nodes identified in above step.
>
> After we enabled the resolver patch
[jira] [Comment Edited] (MRESOLVER-228) Improve the maven dependency resolution speed by a skip & reconcile approach
[
https://issues.apache.org/jira/browse/MRESOLVER-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466839#comment-17466839
]
Ivan Babiankou edited comment on MRESOLVER-228 at 12/30/21, 12:06 PM:
--
Didn't see the updated message... give me a sec.
was (Author: ibabiankou):
Awesome, sounds like a plan. [~wecai] I'm happy to help reviewing the PRs ;)
Please mention me when you have something.
DFS > BFS will not solve MRESOLVER-133 the problem that ticket want to solve:
Resolve highest version in the range, instead resolving all versions and
keeping one. We should probably update title and description of that ticket and
create separate for DFS > BFS
> Improve the maven dependency resolution speed by a skip & reconcile approach
>
>
> Key: MRESOLVER-228
> URL: https://issues.apache.org/jira/browse/MRESOLVER-228
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 1.7.2
>Reporter: wei cai
>Priority: Major
> Fix For: 1.8.0
>
> Attachments: Screen Shot 2021-11-27 at 12.58.26 PM.png, Screen Shot
> 2021-11-27 at 12.58.59 PM.png, Screen Shot 2021-11-27 at 12.59.32 PM.png
>
>
> When comes to resolve the huge amount of dependencies of an enterprise level
> project, the maven resolver is very slow to resolve the dependency
> graph/tree. Take one of our app as example, it could take *10minutes+ and 16G
> memory* to print out the result of {*}mvn dependency:tree{*}.
> This is because there are many dependencies declared in the project, and some
> of the dependencies would introduce *600+* transitive dependencies, and
> exclusions are widely used to solve dependency conflicts.
> By checking the
> [code|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L500],
> we know the exclusion is also part of the cache key. This means when the
> exclusions up the tree differs, the cached resolution result for the same GAV
> won't be picked up and need s to be recalculated.
> !Screen Shot 2021-11-27 at 12.58.26 PM.png!
> From above figure, we know:
> * In 1st case, D will be resolved only once as there are no exclusions/same
> exclusions up the tree.
> * In 2nd case, the B and C have different exclusions and D needs to be
> recalculated, if D is a heavy dependency which introduce many transitive
> dependencies, all D and its children needs to be recalculated. Recalculating
> all of these nodes introduces 2 issues:
> ** Slow in resolving dependencies.
> ** Lots of DependencyNodes cached (all calculated/recalculated nodes would
> be cached) and will consume huge memory.
> To improve the speed of maven resolver's dependency resolution, I
> implemented a skip & reconcile approach. Here is the *skip* part.
> !Screen Shot 2021-11-27 at 12.58.59 PM.png!
> From above figure, the 1st R is resolved at depth 3, and the 2nd R is
> resolved again because the depth is at 2 which is lower, the 3rd R at depth 3
> and the 4th R at depth 4 are simply skipped as R is already resolved at depth
> 2. This is because the same node with deeper depth is most likely won't be
> picked up by maven as maven employs a "{*}nearest{*} transitive dependency in
> the tree depth and the *first* in resolution" strategy.
> The 3rd R and 4th R will have children set as zero and marked as skipped by
> the R at depth 2 in 2nd tree path.
>
> Here is the *reconcile* part:
> !Screen Shot 2021-11-27 at 12.59.32 PM.png!
> When there are dependency conflicts, some of the skipped nodes need to be
> reconciled.
> In above figure, there are 4 tree paths.
> * The D1 (D with version 1) in the 1st tree path is get resolved, children
> of E and R at depth 3 are resolved and cached.
> * In the 2nd tree path, when resolving E & R of H, we simply skip these 2
> nodes as they are in deeper depth (depth: 4) than the E & R in 1st tree path.
> * In the 3rd tree path, a R node with lower path is resolved, and a E node
> at depth 5 is skipped.
> * In the 4th path, a D2 (D with version 2) node is resolved, as the depth is
> lower than D1, so maven will pick D2, this means the E & R's children cached
> in tree depth 1 should be {*}discarded{*}.
> Thus we might need to reconcile the E & R nodes in 2nd, 3rd and 4th tree
> paths. Here only E in 2nd tree path needs to be reconciled. This is because:
> * R in 3rd tree path won't be picked up as there is already a R in 2nd tree
> path with a lower depth.
> * E in 3rd tree path won't be picked up as it is enough to reconcile the E
> in 2nd tree path as the E in 2nd tree path is deeper than E in 3rd tree path.
> Here is what we've updated in the maven-resolver
[jira] [Commented] (MRESOLVER-228) Improve the maven dependency resolution speed by a skip & reconcile approach
[
https://issues.apache.org/jira/browse/MRESOLVER-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466839#comment-17466839
]
Ivan Babiankou commented on MRESOLVER-228:
--
Awesome, sounds like a plan. [~wecai] I'm happy to help reviewing the PRs ;)
Please mention me when you have something.
DFS > BFS will not solve MRESOLVER-133 the problem that ticket want to solve:
Resolve highest version in the range, instead resolving all versions and
keeping one. We should probably update title and description of that ticket and
create separate for DFS > BFS
> Improve the maven dependency resolution speed by a skip & reconcile approach
>
>
> Key: MRESOLVER-228
> URL: https://issues.apache.org/jira/browse/MRESOLVER-228
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 1.7.2
>Reporter: wei cai
>Priority: Major
> Fix For: 1.8.0
>
> Attachments: Screen Shot 2021-11-27 at 12.58.26 PM.png, Screen Shot
> 2021-11-27 at 12.58.59 PM.png, Screen Shot 2021-11-27 at 12.59.32 PM.png
>
>
> When comes to resolve the huge amount of dependencies of an enterprise level
> project, the maven resolver is very slow to resolve the dependency
> graph/tree. Take one of our app as example, it could take *10minutes+ and 16G
> memory* to print out the result of {*}mvn dependency:tree{*}.
> This is because there are many dependencies declared in the project, and some
> of the dependencies would introduce *600+* transitive dependencies, and
> exclusions are widely used to solve dependency conflicts.
> By checking the
> [code|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L500],
> we know the exclusion is also part of the cache key. This means when the
> exclusions up the tree differs, the cached resolution result for the same GAV
> won't be picked up and need s to be recalculated.
> !Screen Shot 2021-11-27 at 12.58.26 PM.png!
> From above figure, we know:
> * In 1st case, D will be resolved only once as there are no exclusions/same
> exclusions up the tree.
> * In 2nd case, the B and C have different exclusions and D needs to be
> recalculated, if D is a heavy dependency which introduce many transitive
> dependencies, all D and its children needs to be recalculated. Recalculating
> all of these nodes introduces 2 issues:
> ** Slow in resolving dependencies.
> ** Lots of DependencyNodes cached (all calculated/recalculated nodes would
> be cached) and will consume huge memory.
> To improve the speed of maven resolver's dependency resolution, I
> implemented a skip & reconcile approach. Here is the *skip* part.
> !Screen Shot 2021-11-27 at 12.58.59 PM.png!
> From above figure, the 1st R is resolved at depth 3, and the 2nd R is
> resolved again because the depth is at 2 which is lower, the 3rd R at depth 3
> and the 4th R at depth 4 are simply skipped as R is already resolved at depth
> 2. This is because the same node with deeper depth is most likely won't be
> picked up by maven as maven employs a "{*}nearest{*} transitive dependency in
> the tree depth and the *first* in resolution" strategy.
> The 3rd R and 4th R will have children set as zero and marked as skipped by
> the R at depth 2 in 2nd tree path.
>
> Here is the *reconcile* part:
> !Screen Shot 2021-11-27 at 12.59.32 PM.png!
> When there are dependency conflicts, some of the skipped nodes need to be
> reconciled.
> In above figure, there are 4 tree paths.
> * The D1 (D with version 1) in the 1st tree path is get resolved, children
> of E and R at depth 3 are resolved and cached.
> * In the 2nd tree path, when resolving E & R of H, we simply skip these 2
> nodes as they are in deeper depth (depth: 4) than the E & R in 1st tree path.
> * In the 3rd tree path, a R node with lower path is resolved, and a E node
> at depth 5 is skipped.
> * In the 4th path, a D2 (D with version 2) node is resolved, as the depth is
> lower than D1, so maven will pick D2, this means the E & R's children cached
> in tree depth 1 should be {*}discarded{*}.
> Thus we might need to reconcile the E & R nodes in 2nd, 3rd and 4th tree
> paths. Here only E in 2nd tree path needs to be reconciled. This is because:
> * R in 3rd tree path won't be picked up as there is already a R in 2nd tree
> path with a lower depth.
> * E in 3rd tree path won't be picked up as it is enough to reconcile the E
> in 2nd tree path as the E in 2nd tree path is deeper than E in 3rd tree path.
> Here is what we've updated in the maven-resolver logic:
> # Resolve dependencies by leveraging a skip approach. The node in deeper
> depth will be skipped if a node with same GAV has
[jira] [Comment Edited] (MRESOLVER-228) Improve the maven dependency resolution speed by a skip & reconcile approach
[
https://issues.apache.org/jira/browse/MRESOLVER-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466825#comment-17466825
]
wei cai edited comment on MRESOLVER-228 at 12/30/21, 11:52 AM:
---
[~michael-o] [~ibabiankou]
Cool! Have read the comments in
[https://github.com/apache/maven-resolver/pull/142.]
Looks like we now have a road map:
* DFS -> BFS to make sure dependency tree no changes, might solve MRESOLVER-133
* BFS + Skip & Reconcile to make sure dependency tree no changes which is for
MRESOLVER-228
* Download artifacts in parallel which is for MRESOLVER-7
One question is, as Ivan pointed out in MRESOLVER-133 as below, it does not
have to use a BFS strategy to solve MRESOLVER-133. Shall we still need to go to
BFS?
---
This loop should iterate over reversed list of versions, it should only try to
get artifact descriptor and break as soon as got one successfully. If no
versions are available, then the build could be failed with appropriate message.
---
If we do not need to go with BFS, the road map would be:
* Ivan's proposal to solve MRESOLVER-133
* DFS + Skip & Reconcile to make sure dependency tree no changes which is for
MRESOLVER-228
PR: [https://github.com/apache/maven-resolver/pull/136] already implemented
this.
* Download artifacts in parallel which is for MRESOLVER-7
If we need go with BFS, I already did a BFS experiment before I submitted the
PR of DFS + Skip & Reconcile approach for MRESOLVER-228, let me prepare the
very first PR, the PR should include pure BFS solution, no skip, no reconcile,
then I will go with the BFS + Skip & Reconcile as the 2nd PR.
was (Author: wecai):
[~michael-o] [~ibabiankou]
Cool! Have read the comments in
[https://github.com/apache/maven-resolver/pull/142.]
Looks like we now have a road map:
* DFS -> BFS to make sure dependency tree no changes, might solve MRESOLVER-133
* BFS + Skip & Reconcile to make sure dependency tree no changes which is for
MRESOLVER-228
* Download artifacts in parallel which is for MRESOLVER-7
I already did a BFS experiment before I submitted the PR of DFS + Skip &
Reconcile approach for MRESOLVER-228, let me prepare the very first PR, the PR
should include pure BFS solution, no skip, no reconcile, then I will go with
the BFS + Skip & Reconcile.
> Improve the maven dependency resolution speed by a skip & reconcile approach
>
>
> Key: MRESOLVER-228
> URL: https://issues.apache.org/jira/browse/MRESOLVER-228
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 1.7.2
>Reporter: wei cai
>Priority: Major
> Fix For: 1.8.0
>
> Attachments: Screen Shot 2021-11-27 at 12.58.26 PM.png, Screen Shot
> 2021-11-27 at 12.58.59 PM.png, Screen Shot 2021-11-27 at 12.59.32 PM.png
>
>
> When comes to resolve the huge amount of dependencies of an enterprise level
> project, the maven resolver is very slow to resolve the dependency
> graph/tree. Take one of our app as example, it could take *10minutes+ and 16G
> memory* to print out the result of {*}mvn dependency:tree{*}.
> This is because there are many dependencies declared in the project, and some
> of the dependencies would introduce *600+* transitive dependencies, and
> exclusions are widely used to solve dependency conflicts.
> By checking the
> [code|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L500],
> we know the exclusion is also part of the cache key. This means when the
> exclusions up the tree differs, the cached resolution result for the same GAV
> won't be picked up and need s to be recalculated.
> !Screen Shot 2021-11-27 at 12.58.26 PM.png!
> From above figure, we know:
> * In 1st case, D will be resolved only once as there are no exclusions/same
> exclusions up the tree.
> * In 2nd case, the B and C have different exclusions and D needs to be
> recalculated, if D is a heavy dependency which introduce many transitive
> dependencies, all D and its children needs to be recalculated. Recalculating
> all of these nodes introduces 2 issues:
> ** Slow in resolving dependencies.
> ** Lots of DependencyNodes cached (all calculated/recalculated nodes would
> be cached) and will consume huge memory.
> To improve the speed of maven resolver's dependency resolution, I
> implemented a skip & reconcile approach. Here is the *skip* part.
> !Screen Shot 2021-11-27 at 12.58.59 PM.png!
> From above figure, the 1st R is resolved at depth 3, and the 2nd R is
> resolved again because the depth is at 2
[GitHub] [maven-surefire] Tibor17 commented on pull request #415: [SUREFIRE-1955] Switch project to Java 8
Tibor17 commented on pull request #415: URL: https://github.com/apache/maven-surefire/pull/415#issuecomment-1002992437 @slawekjaranowski The plugin `animal-sniffer-maven-plugin` has a newer version `1.20`. It is used to check the JDK API signatures. We can update the version here or in another PR. It's up to you. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (MRESOLVER-228) Improve the maven dependency resolution speed by a skip & reconcile approach
[
https://issues.apache.org/jira/browse/MRESOLVER-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466825#comment-17466825
]
wei cai edited comment on MRESOLVER-228 at 12/30/21, 11:30 AM:
---
[~michael-o] [~ibabiankou]
Cool! Have read the comments in
[https://github.com/apache/maven-resolver/pull/142.]
Looks like we now have a road map:
* DFS -> BFS to make sure dependency tree no changes, might solve MRESOLVER-133
* BFS + Skip & Reconcile to make sure dependency tree no changes which is for
MRESOLVER-228
* Download artifacts in parallel which is for MRESOLVER-7
I already did a BFS experiment before I submitted the PR of DFS + Skip &
Reconcile approach for MRESOLVER-228, let me prepare the very first PR, the PR
should include pure BFS solution, no skip, no reconcile, then I will go with
the BFS + Skip & Reconcile.
was (Author: wecai):
[~michael-o] [~ibabiankou]
Cool! Have read the comments in
[https://github.com/apache/maven-resolver/pull/142.]
Looks like we now have a road map:
* DFS -> BFS to make sure dependency tree no changes, might solve MRESOLVER-133
* BFS + Skip & Reconcile to make sure dependency tree no changes which is for
MRESOLVER-228
* Download artifacts in parallel which is for MRESOLVER-7
I already get a BFS solution implementation, let me prepare the very first PR.
> Improve the maven dependency resolution speed by a skip & reconcile approach
>
>
> Key: MRESOLVER-228
> URL: https://issues.apache.org/jira/browse/MRESOLVER-228
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 1.7.2
>Reporter: wei cai
>Priority: Major
> Fix For: 1.8.0
>
> Attachments: Screen Shot 2021-11-27 at 12.58.26 PM.png, Screen Shot
> 2021-11-27 at 12.58.59 PM.png, Screen Shot 2021-11-27 at 12.59.32 PM.png
>
>
> When comes to resolve the huge amount of dependencies of an enterprise level
> project, the maven resolver is very slow to resolve the dependency
> graph/tree. Take one of our app as example, it could take *10minutes+ and 16G
> memory* to print out the result of {*}mvn dependency:tree{*}.
> This is because there are many dependencies declared in the project, and some
> of the dependencies would introduce *600+* transitive dependencies, and
> exclusions are widely used to solve dependency conflicts.
> By checking the
> [code|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L500],
> we know the exclusion is also part of the cache key. This means when the
> exclusions up the tree differs, the cached resolution result for the same GAV
> won't be picked up and need s to be recalculated.
> !Screen Shot 2021-11-27 at 12.58.26 PM.png!
> From above figure, we know:
> * In 1st case, D will be resolved only once as there are no exclusions/same
> exclusions up the tree.
> * In 2nd case, the B and C have different exclusions and D needs to be
> recalculated, if D is a heavy dependency which introduce many transitive
> dependencies, all D and its children needs to be recalculated. Recalculating
> all of these nodes introduces 2 issues:
> ** Slow in resolving dependencies.
> ** Lots of DependencyNodes cached (all calculated/recalculated nodes would
> be cached) and will consume huge memory.
> To improve the speed of maven resolver's dependency resolution, I
> implemented a skip & reconcile approach. Here is the *skip* part.
> !Screen Shot 2021-11-27 at 12.58.59 PM.png!
> From above figure, the 1st R is resolved at depth 3, and the 2nd R is
> resolved again because the depth is at 2 which is lower, the 3rd R at depth 3
> and the 4th R at depth 4 are simply skipped as R is already resolved at depth
> 2. This is because the same node with deeper depth is most likely won't be
> picked up by maven as maven employs a "{*}nearest{*} transitive dependency in
> the tree depth and the *first* in resolution" strategy.
> The 3rd R and 4th R will have children set as zero and marked as skipped by
> the R at depth 2 in 2nd tree path.
>
> Here is the *reconcile* part:
> !Screen Shot 2021-11-27 at 12.59.32 PM.png!
> When there are dependency conflicts, some of the skipped nodes need to be
> reconciled.
> In above figure, there are 4 tree paths.
> * The D1 (D with version 1) in the 1st tree path is get resolved, children
> of E and R at depth 3 are resolved and cached.
> * In the 2nd tree path, when resolving E & R of H, we simply skip these 2
> nodes as they are in deeper depth (depth: 4) than the E & R in 1st tree path.
> * In the 3rd tree path, a R node with lower path is resolved, and a E node
> at depth 5 is skipped.
> * In the 4th path, a D2
[jira] [Commented] (MRESOLVER-228) Improve the maven dependency resolution speed by a skip & reconcile approach
[
https://issues.apache.org/jira/browse/MRESOLVER-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17466825#comment-17466825
]
wei cai commented on MRESOLVER-228:
---
[~michael-o] [~ibabiankou]
Cool! Have read the comments in
[https://github.com/apache/maven-resolver/pull/142.]
Looks like we now have a road map:
* DFS -> BFS to make sure dependency tree no changes, might solve MRESOLVER-133
* BFS + Skip & Reconcile to make sure dependency tree no changes which is for
MRESOLVER-228
* Download artifacts in parallel which is for MRESOLVER-7
I already get a BFS solution implementation, let me prepare the very first PR.
> Improve the maven dependency resolution speed by a skip & reconcile approach
>
>
> Key: MRESOLVER-228
> URL: https://issues.apache.org/jira/browse/MRESOLVER-228
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 1.7.2
>Reporter: wei cai
>Priority: Major
> Fix For: 1.8.0
>
> Attachments: Screen Shot 2021-11-27 at 12.58.26 PM.png, Screen Shot
> 2021-11-27 at 12.58.59 PM.png, Screen Shot 2021-11-27 at 12.59.32 PM.png
>
>
> When comes to resolve the huge amount of dependencies of an enterprise level
> project, the maven resolver is very slow to resolve the dependency
> graph/tree. Take one of our app as example, it could take *10minutes+ and 16G
> memory* to print out the result of {*}mvn dependency:tree{*}.
> This is because there are many dependencies declared in the project, and some
> of the dependencies would introduce *600+* transitive dependencies, and
> exclusions are widely used to solve dependency conflicts.
> By checking the
> [code|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L500],
> we know the exclusion is also part of the cache key. This means when the
> exclusions up the tree differs, the cached resolution result for the same GAV
> won't be picked up and need s to be recalculated.
> !Screen Shot 2021-11-27 at 12.58.26 PM.png!
> From above figure, we know:
> * In 1st case, D will be resolved only once as there are no exclusions/same
> exclusions up the tree.
> * In 2nd case, the B and C have different exclusions and D needs to be
> recalculated, if D is a heavy dependency which introduce many transitive
> dependencies, all D and its children needs to be recalculated. Recalculating
> all of these nodes introduces 2 issues:
> ** Slow in resolving dependencies.
> ** Lots of DependencyNodes cached (all calculated/recalculated nodes would
> be cached) and will consume huge memory.
> To improve the speed of maven resolver's dependency resolution, I
> implemented a skip & reconcile approach. Here is the *skip* part.
> !Screen Shot 2021-11-27 at 12.58.59 PM.png!
> From above figure, the 1st R is resolved at depth 3, and the 2nd R is
> resolved again because the depth is at 2 which is lower, the 3rd R at depth 3
> and the 4th R at depth 4 are simply skipped as R is already resolved at depth
> 2. This is because the same node with deeper depth is most likely won't be
> picked up by maven as maven employs a "{*}nearest{*} transitive dependency in
> the tree depth and the *first* in resolution" strategy.
> The 3rd R and 4th R will have children set as zero and marked as skipped by
> the R at depth 2 in 2nd tree path.
>
> Here is the *reconcile* part:
> !Screen Shot 2021-11-27 at 12.59.32 PM.png!
> When there are dependency conflicts, some of the skipped nodes need to be
> reconciled.
> In above figure, there are 4 tree paths.
> * The D1 (D with version 1) in the 1st tree path is get resolved, children
> of E and R at depth 3 are resolved and cached.
> * In the 2nd tree path, when resolving E & R of H, we simply skip these 2
> nodes as they are in deeper depth (depth: 4) than the E & R in 1st tree path.
> * In the 3rd tree path, a R node with lower path is resolved, and a E node
> at depth 5 is skipped.
> * In the 4th path, a D2 (D with version 2) node is resolved, as the depth is
> lower than D1, so maven will pick D2, this means the E & R's children cached
> in tree depth 1 should be {*}discarded{*}.
> Thus we might need to reconcile the E & R nodes in 2nd, 3rd and 4th tree
> paths. Here only E in 2nd tree path needs to be reconciled. This is because:
> * R in 3rd tree path won't be picked up as there is already a R in 2nd tree
> path with a lower depth.
> * E in 3rd tree path won't be picked up as it is enough to reconcile the E
> in 2nd tree path as the E in 2nd tree path is deeper than E in 3rd tree path.
> Here is what we've updated in the maven-resolver logic:
> # Resolve dependencies by leveraging a skip approach. The node
[GitHub] [maven] mthmulders commented on pull request #643: [MNG-5561] Plugin relocation loses configuration
mthmulders commented on pull request #643: URL: https://github.com/apache/maven/pull/643#issuecomment-1002980811 > @mthmulders Should I remove the `@Override`? I don't see a reason for that... If it is a valid override (and it is), I think it makes sense to keep the annotation there. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] michael-o edited a comment on pull request #643: [MNG-5561] Plugin relocation loses configuration
michael-o edited a comment on pull request #643: URL: https://github.com/apache/maven/pull/643#issuecomment-1002980003 @mthmulders Should I remove the `@Override`? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] michael-o commented on pull request #643: [MNG-5561] Plugin relocation loses configuration
michael-o commented on pull request #643: URL: https://github.com/apache/maven/pull/643#issuecomment-1002980003 @mthmulders Should I remove the `@Override`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] michael-o commented on a change in pull request #643: [MNG-5561] Plugin relocation loses configuration
michael-o commented on a change in pull request #643: URL: https://github.com/apache/maven/pull/643#discussion_r776673637 ## File path: maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RelocatedArtifact.java ## @@ -86,6 +86,39 @@ public String getVersion() } } +@Override Review comment: Yes, we are using the new object. Checked myself and tripped over. I can drop the `@Override`, no issue. Another issue was also that the outcome was *not* a `RelocatedArtifact`, but a `DefaultArtifact`. This means that the original information was lost. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] yxxcrtd commented on issue #554: macOS Monterey doesn't work with mvnd
yxxcrtd commented on issue #554: URL: https://github.com/apache/maven-mvnd/issues/554#issuecomment-1002978057 how to fix -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] michael-o commented on a change in pull request #643: [MNG-5561] Plugin relocation loses configuration
michael-o commented on a change in pull request #643: URL: https://github.com/apache/maven/pull/643#discussion_r776673637 ## File path: maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RelocatedArtifact.java ## @@ -86,6 +86,39 @@ public String getVersion() } } +@Override Review comment: Yes, we are using the new object. Checked myself and tripped over. I can drop the `@Override`, no issue. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] mthmulders commented on a change in pull request #643: [MNG-5561] Plugin relocation loses configuration
mthmulders commented on a change in pull request #643: URL: https://github.com/apache/maven/pull/643#discussion_r776671359 ## File path: maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RelocatedArtifact.java ## @@ -86,6 +86,39 @@ public String getVersion() } } +@Override Review comment: On a related note, why is it necessary to override these setters? I can see that in certain conditions, they will create a new instance of the `RelocatedArtifact` class rather than mutating the existing one. In general: yay for immutability! But the Maven codebase usually assumes a `setX` method to mutate the object it is called upon and ignores the return value (if any). So what problem does it solve, and are we sure that whenever we invoke it, we continue with the new object rather than the (unmodified) original object? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] michael-o commented on a change in pull request #643: [MNG-5561] Plugin relocation loses configuration
michael-o commented on a change in pull request #643:
URL: https://github.com/apache/maven/pull/643#discussion_r776670895
##
File path:
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RelocatedArtifact.java
##
@@ -86,6 +86,39 @@ public String getVersion()
}
}
+@Override
+public Artifact setVersion( String version )
+{
+ String current = getVersion();
+ if ( current.equals( version ) || ( version == null &&
current.length() <= 0 ) )
Review comment:
Negative (black) magic.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] mthmulders commented on a change in pull request #643: [MNG-5561] Plugin relocation loses configuration
mthmulders commented on a change in pull request #643:
URL: https://github.com/apache/maven/pull/643#discussion_r776670249
##
File path:
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RelocatedArtifact.java
##
@@ -86,6 +86,39 @@ public String getVersion()
}
}
+@Override
+public Artifact setVersion( String version )
+{
+ String current = getVersion();
+ if ( current.equals( version ) || ( version == null &&
current.length() <= 0 ) )
Review comment:
It's the first time I encounter it... Just being curious
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] michael-o commented on a change in pull request #643: [MNG-5561] Plugin relocation loses configuration
michael-o commented on a change in pull request #643:
URL: https://github.com/apache/maven/pull/643#discussion_r776669482
##
File path:
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RelocatedArtifact.java
##
@@ -86,6 +86,39 @@ public String getVersion()
}
}
+@Override
+public Artifact setVersion( String version )
+{
+ String current = getVersion();
+ if ( current.equals( version ) || ( version == null &&
current.length() <= 0 ) )
Review comment:
It can't. You see this pattern everywhere in Maven space. I simply
copied the code from the parent class. I intentionally did not want to change
it in this spot. It should be changed all at once everywhere.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
