[jira] [Commented] (MRESOLVER-379) Problem when relocations and ranges are used in collection
[
https://issues.apache.org/jira/browse/MRESOLVER-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739275#comment-17739275
]
wei cai commented on MRESOLVER-379:
---
[~cstamas]
If run mvn dependency:tree, both df & bf prints
{code:java}
A1
+- C3 {code}
Not quite get the issue, but the above behavior makes sense, user declare a
dependency with version range, it actually means it would depend on one
specific version, print all available versions is not necessary.
MNG-3454 is a bit different, it says a dependency was relocated another
dependency with different version like A 1.0 -> B 2.0
> Problem when relocations and ranges are used in collection
> --
>
> Key: MRESOLVER-379
> URL: https://issues.apache.org/jira/browse/MRESOLVER-379
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
>
> Affects both old DF and new BF collectors.
> Example:
> * A1 -> B[1,3]
> * B1 relocated to C1
> * B2 relocated to C2
> * B3 relocated to C3
> In this example, as output of collection dirty tree (verbose) I'd expect:
> {noformat}
> A1
> +- C1
> +- C2
> +- C3
> {noformat}
> But none of the DF or BF produce this, moreover, they produce DIFFERENT
> outputs:
> DF does this:
> {noformat}
> A1
> +- C1
> {noformat}
> BF does this:
> {noformat}
> A1
> +- C3
> {noformat}
> Cause is probably as BF "reverse sort" versions, but none will return proper
> range.
> Real life example: MRESOLVER-376, where junit:junit-dep:[4.9,) range "maps
> itself" onto junit:junit versions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7827) Fix org.apache.maven.plugin.logging.Log deprecation message and AbstractMojo#getLog fallback
[ https://issues.apache.org/jira/browse/MNG-7827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739223#comment-17739223 ] ASF GitHub Bot commented on MNG-7827: - rmannibucau commented on PR #1187: URL: https://github.com/apache/maven/pull/1187#issuecomment-1615094336 @cstamas this is only one of the 4-5 explaining why we must not leak our default impl and where we didnt find an agreement in terms of api leak yes. Note we dont want to change the logging, just keep the one we had and fix the bug introduced in the javadoc which doesnt reflects discussion outcomes. Technically, there are multiple cons leaking slf4j but community wise a vote wouldnt pass but in force so both are bad. Last is that maven didnt migrate its api to slf4j in plugin - never, we miss several steps to say it is done so current absusive comment is even wrong - so let's fix it, will impact nobody as of today and not mislead mojo dev. > Fix org.apache.maven.plugin.logging.Log deprecation message and > AbstractMojo#getLog fallback > > > Key: MNG-7827 > URL: https://issues.apache.org/jira/browse/MNG-7827 > Project: Maven > Issue Type: Improvement > Components: Plugin API >Affects Versions: 4.0.0-alpha-7 >Reporter: Romain Manni-Bucau >Priority: Major > > In maven 4 an official Log API was created and using SLF4J as primary logging > solution is not recommended nor the official way so javadoc and impl should > be aligned to reflcet that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-indexer] slachiewicz merged pull request #311: Bump spring-core from 5.3.26 to 5.3.27 in /indexer-examples/indexer-examples-spring
slachiewicz merged PR #311: URL: https://github.com/apache/maven-indexer/pull/311 -- 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-doap-plugin] dependabot[bot] commented on pull request #11: Bump aetherVersion from 1.0.0.v20140518 to 1.1.0
dependabot[bot] commented on PR #11: URL: https://github.com/apache/maven-doap-plugin/pull/11#issuecomment-1615091687 OK, I won't notify you about any of these dependencies again, unless you re-open this PR. 😢 -- 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-doap-plugin] dependabot[bot] closed pull request #11: Bump aetherVersion from 1.0.0.v20140518 to 1.1.0
dependabot[bot] closed pull request #11: Bump aetherVersion from 1.0.0.v20140518 to 1.1.0 URL: https://github.com/apache/maven-doap-plugin/pull/11 -- 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-antrun-plugin] dependabot[bot] closed pull request #78: Bump plexus-utils from 3.4.2 to 3.5.1
dependabot[bot] closed pull request #78: Bump plexus-utils from 3.4.2 to 3.5.1 URL: https://github.com/apache/maven-antrun-plugin/pull/78 -- 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-antrun-plugin] dependabot[bot] commented on pull request #71: Bump maven-shared-resources from 4 to 5
dependabot[bot] commented on PR #71: URL: https://github.com/apache/maven-antrun-plugin/pull/71#issuecomment-1615088364 Looks like org.apache.maven.shared:maven-shared-resources is no longer a dependency, so this is no longer needed. -- 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] (MANTRUN-239) Update parent pom to 39
[ https://issues.apache.org/jira/browse/MANTRUN-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MANTRUN-239. Resolution: Fixed > Update parent pom to 39 > --- > > Key: MANTRUN-239 > URL: https://issues.apache.org/jira/browse/MANTRUN-239 > Project: Maven Antrun Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-antrun-plugin] dependabot[bot] closed pull request #79: Bump maven-plugin-plugin from 3.6.4 to 3.8.2
dependabot[bot] closed pull request #79: Bump maven-plugin-plugin from 3.6.4 to 3.8.2 URL: https://github.com/apache/maven-antrun-plugin/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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-antrun-plugin] dependabot[bot] closed pull request #71: Bump maven-shared-resources from 4 to 5
dependabot[bot] closed pull request #71: Bump maven-shared-resources from 4 to 5 URL: https://github.com/apache/maven-antrun-plugin/pull/71 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-antrun-plugin] dependabot[bot] closed pull request #82: Bump modello-maven-plugin from 2.0.0 to 2.1.2
dependabot[bot] closed pull request #82: Bump modello-maven-plugin from 2.0.0 to 2.1.2 URL: https://github.com/apache/maven-antrun-plugin/pull/82 -- 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] (MANTRUN-239) Update parent pom to 39
[ https://issues.apache.org/jira/browse/MANTRUN-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739220#comment-17739220 ] ASF GitHub Bot commented on MANTRUN-239: slachiewicz merged PR #80: URL: https://github.com/apache/maven-antrun-plugin/pull/80 > Update parent pom to 39 > --- > > Key: MANTRUN-239 > URL: https://issues.apache.org/jira/browse/MANTRUN-239 > Project: Maven Antrun Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 3.2.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6829) Remove commons-lang3 dependency
[
https://issues.apache.org/jira/browse/MNG-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739216#comment-17739216
]
ASF GitHub Bot commented on MNG-6829:
-
slachiewicz merged PR #34:
URL: https://github.com/apache/maven-archiver/pull/34
> Remove commons-lang3 dependency
> ---
>
> Key: MNG-6829
> URL: https://issues.apache.org/jira/browse/MNG-6829
> Project: Maven
> Issue Type: Sub-task
> Components: Bootstrap & Build
>Affects Versions: 3.6.3
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Labels: close-pending
> Fix For: 4.0.x-candidate
>
> Attachments: dtPKn.xlsx
>
>
> Currently we use {{commons-lang3}} for the following classes
> * {{StringUtils}} can be replaced by usage of either {{plexus-utils}} or
> {{maven-shared-utils}} or as I tested with self implementation
> * {{SystemUtils}} is only used in some tests which can simply replaced by
> using JUnit Jupiter with all the support it has.
> * {{Validate}} is a precondition class which checks for parameters etc. can
> be implemented very easily (done already to see how it works). Later this
> could be made part of {{maven-shared-utils}}.
> * Currently the {{StringUtils.substringAfterLast( resourceName, "/" )}} is
> used in {{ConsoleMavenTransferListener}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-scm] dependabot[bot] commented on pull request #178: Bump jgitVersion from 5.13.1.202206130422-r to 6.6.0.202305301015-r
dependabot[bot] commented on PR #178: URL: https://github.com/apache/maven-scm/pull/178#issuecomment-1615071959 OK, I won't notify you about version 6.x.x again, unless you re-open this PR. 😢 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-scm] dependabot[bot] closed pull request #178: Bump jgitVersion from 5.13.1.202206130422-r to 6.6.0.202305301015-r
dependabot[bot] closed pull request #178: Bump jgitVersion from 5.13.1.202206130422-r to 6.6.0.202305301015-r URL: https://github.com/apache/maven-scm/pull/178 -- 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-indexer] dependabot[bot] commented on pull request #316: Bump guice from 5.1.0 to 7.0.0
dependabot[bot] commented on PR #316: URL: https://github.com/apache/maven-indexer/pull/316#issuecomment-1615071001 OK, I won't notify you about version 7.x.x again, unless you re-open this PR. 😢 -- 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-indexer] dependabot[bot] closed pull request #316: Bump guice from 5.1.0 to 7.0.0
dependabot[bot] closed pull request #316: Bump guice from 5.1.0 to 7.0.0 URL: https://github.com/apache/maven-indexer/pull/316 -- 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-shade-plugin] dependabot[bot] commented on pull request #192: Bump guice from 5.1.0 to 6.0.0
dependabot[bot] commented on PR #192: URL: https://github.com/apache/maven-shade-plugin/pull/192#issuecomment-1615069339 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-shade-plugin] slachiewicz closed pull request #192: Bump guice from 5.1.0 to 6.0.0
slachiewicz closed pull request #192: Bump guice from 5.1.0 to 6.0.0 URL: https://github.com/apache/maven-shade-plugin/pull/192 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7827) Fix org.apache.maven.plugin.logging.Log deprecation message and AbstractMojo#getLog fallback
[ https://issues.apache.org/jira/browse/MNG-7827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739214#comment-17739214 ] ASF GitHub Bot commented on MNG-7827: - cstamas commented on PR #1187: URL: https://github.com/apache/maven/pull/1187#issuecomment-1615066953 > 1. Drop the irrelevant documentation we never agreed upon to use SLF4J (api) for plugins Then your memory is lossy :smile: See https://lists.apache.org/thread/bh9vr9fwt2cqf3ltg88jm1fh5y0d57b0 Please, stop with this "change the logging..." madness. > Fix org.apache.maven.plugin.logging.Log deprecation message and > AbstractMojo#getLog fallback > > > Key: MNG-7827 > URL: https://issues.apache.org/jira/browse/MNG-7827 > Project: Maven > Issue Type: Improvement > Components: Plugin API >Affects Versions: 4.0.0-alpha-7 >Reporter: Romain Manni-Bucau >Priority: Major > > In maven 4 an official Log API was created and using SLF4J as primary logging > solution is not recommended nor the official way so javadoc and impl should > be aligned to reflcet that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-doxia-sitetools] slachiewicz closed pull request #97: Bump htmlunit from 2.67.0 to 2.70.0
slachiewicz closed pull request #97: Bump htmlunit from 2.67.0 to 2.70.0 URL: https://github.com/apache/maven-doxia-sitetools/pull/97 -- 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-doxia-sitetools] dependabot[bot] commented on pull request #97: Bump htmlunit from 2.67.0 to 2.70.0
dependabot[bot] commented on PR #97: URL: https://github.com/apache/maven-doxia-sitetools/pull/97#issuecomment-1615055081 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7532) Revert MNG-6931 deprecation since list shows no consensus on that
[ https://issues.apache.org/jira/browse/MNG-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739208#comment-17739208 ] ASF GitHub Bot commented on MNG-7532: - slachiewicz commented on PR #793: URL: https://github.com/apache/maven/pull/793#issuecomment-1615050966 For Maven 5 sounds good, hope we someone will deliver new better API and bridges to existing frameworks. > Revert MNG-6931 deprecation since list shows no consensus on that > - > > Key: MNG-7532 > URL: https://issues.apache.org/jira/browse/MNG-7532 > Project: Maven > Issue Type: Task >Reporter: Romain Manni-Bucau >Priority: Major > > There are several threads on the dev list asking for the drop of slf4j and at > least keeping a logging abstraction for not internal dev (= core can use > slf4j but not mojo/extensions). > Work is being done to abstract plugin api so let's keep the > deprecation/replacement of our Log API in this track and keep it the official > way for now. > one of the multiple refs: > https://www.mail-archive.com/dev@maven.apache.org/msg123452.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas closed pull request #297: [MRESOLVER-369] Introduce update check policy scope
cstamas closed pull request #297: [MRESOLVER-369] Introduce update check policy scope URL: https://github.com/apache/maven-resolver/pull/297 -- 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-369) Expose configuration for update check manager where to apply policy
[
https://issues.apache.org/jira/browse/MRESOLVER-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739205#comment-17739205
]
ASF GitHub Bot commented on MRESOLVER-369:
--
cstamas commented on PR #297:
URL: https://github.com/apache/maven-resolver/pull/297#issuecomment-1615039292
MRESOLVER-377 is proper fix
> Expose configuration for update check manager where to apply policy
> ---
>
> Key: MRESOLVER-369
> URL: https://issues.apache.org/jira/browse/MRESOLVER-369
> Project: Maven Resolver
> Issue Type: New Feature
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Currently, DefaultUpdateCheckManager ALWAYS applies policy to both, artifacts
> and metadata. This causes problems when we want to "discover new versions"
> (or similar use case, that relies on fresh metadata), but metadata is never
> updated due remote repository update policy of "never", so only -U make it
> work as expected. -U OTOH is like shooting with cannon onto bird, as it
> updates many many more as well, not only the one metadata we are interested
> in.
> Moreover, since Maven3 artifacts are immutable.
> So, add a config like {{aether.updateCheckManager.applyUpdatePolicy}} that
> accepts values "all" (like today) and "metadata" (does not applies policy to
> artifacts, if artifact present, no update needed).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-369) Expose configuration for update check manager where to apply policy
[
https://issues.apache.org/jira/browse/MRESOLVER-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739206#comment-17739206
]
ASF GitHub Bot commented on MRESOLVER-369:
--
cstamas closed pull request #297: [MRESOLVER-369] Introduce update check policy
scope
URL: https://github.com/apache/maven-resolver/pull/297
> Expose configuration for update check manager where to apply policy
> ---
>
> Key: MRESOLVER-369
> URL: https://issues.apache.org/jira/browse/MRESOLVER-369
> Project: Maven Resolver
> Issue Type: New Feature
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Currently, DefaultUpdateCheckManager ALWAYS applies policy to both, artifacts
> and metadata. This causes problems when we want to "discover new versions"
> (or similar use case, that relies on fresh metadata), but metadata is never
> updated due remote repository update policy of "never", so only -U make it
> work as expected. -U OTOH is like shooting with cannon onto bird, as it
> updates many many more as well, not only the one metadata we are interested
> in.
> Moreover, since Maven3 artifacts are immutable.
> So, add a config like {{aether.updateCheckManager.applyUpdatePolicy}} that
> accepts values "all" (like today) and "metadata" (does not applies policy to
> artifacts, if artifact present, no update needed).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MRESOLVER-369) Expose configuration for update check manager where to apply policy
[
https://issues.apache.org/jira/browse/MRESOLVER-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MRESOLVER-369.
-
Resolution: Won't Fix
MRESOLVER-377 is proper fix
> Expose configuration for update check manager where to apply policy
> ---
>
> Key: MRESOLVER-369
> URL: https://issues.apache.org/jira/browse/MRESOLVER-369
> Project: Maven Resolver
> Issue Type: New Feature
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Currently, DefaultUpdateCheckManager ALWAYS applies policy to both, artifacts
> and metadata. This causes problems when we want to "discover new versions"
> (or similar use case, that relies on fresh metadata), but metadata is never
> updated due remote repository update policy of "never", so only -U make it
> work as expected. -U OTOH is like shooting with cannon onto bird, as it
> updates many many more as well, not only the one metadata we are interested
> in.
> Moreover, since Maven3 artifacts are immutable.
> So, add a config like {{aether.updateCheckManager.applyUpdatePolicy}} that
> accepts values "all" (like today) and "metadata" (does not applies policy to
> artifacts, if artifact present, no update needed).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-381) Undo MRESOLVER-373 as it was fixed by other means
[ https://issues.apache.org/jira/browse/MRESOLVER-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-381: -- Component/s: Resolver > Undo MRESOLVER-373 as it was fixed by other means > - > > Key: MRESOLVER-381 > URL: https://issues.apache.org/jira/browse/MRESOLVER-381 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.14 > > > The MRESOLVER-373 made two important operations serialized (again, since > existence of locks), but the proper fix was actually this one (also part of > MRESOLVER-373): > https://github.com/apache/maven-resolver/commit/4fb1cf93b478ab1eeb563c3e69ad888017265e54 > And given that artifacts and metadata does not use same lock name, the code > undone would work. Still, errors would occur again, with "static" name mapper > (maps always to same name), hence some smarter change is needed: when > artifact resolver invokes metadata resolver, maybe it needs to unlock and > then invoke? > The ultimate goal: to not serialize on "happy path", but make it use "shared" > locking so multiple thread can work together. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-integration-testing] slachiewicz commented on pull request #146: Bump ant from 1.7.1 to 1.10.11 in /core-it-support/core-it-plugins/maven-it-plugin-ant-based
slachiewicz commented on PR #146: URL: https://github.com/apache/maven-integration-testing/pull/146#issuecomment-1615025269 @dependabot rebase -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-381) Undo MRESOLVER-373 as it was fixed by other means
[ https://issues.apache.org/jira/browse/MRESOLVER-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739197#comment-17739197 ] ASF GitHub Bot commented on MRESOLVER-381: -- cstamas opened a new pull request, #314: URL: https://github.com/apache/maven-resolver/pull/314 Partially undo MRESOLVER-346: 1acec9baf6fcb8eb010d64e8009778a13a88d38e Also, make existing "static" name mapper obey the rule (distinguish between artifacts and metadata) and make not about this on NameMapper interface as we.. --- https://issues.apache.org/jira/browse/MRESOLVER-381 > Undo MRESOLVER-373 as it was fixed by other means > - > > Key: MRESOLVER-381 > URL: https://issues.apache.org/jira/browse/MRESOLVER-381 > Project: Maven Resolver > Issue Type: Task >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.14 > > > The MRESOLVER-373 made two important operations serialized (again, since > existence of locks), but the proper fix was actually this one (also part of > MRESOLVER-373): > https://github.com/apache/maven-resolver/commit/4fb1cf93b478ab1eeb563c3e69ad888017265e54 > And given that artifacts and metadata does not use same lock name, the code > undone would work. Still, errors would occur again, with "static" name mapper > (maps always to same name), hence some smarter change is needed: when > artifact resolver invokes metadata resolver, maybe it needs to unlock and > then invoke? > The ultimate goal: to not serialize on "happy path", but make it use "shared" > locking so multiple thread can work together. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas opened a new pull request, #314: [MRESOLVER-381] Make "happy path" shared locking again
cstamas opened a new pull request, #314: URL: https://github.com/apache/maven-resolver/pull/314 Partially undo MRESOLVER-346: 1acec9baf6fcb8eb010d64e8009778a13a88d38e Also, make existing "static" name mapper obey the rule (distinguish between artifacts and metadata) and make not about this on NameMapper interface as we.. --- https://issues.apache.org/jira/browse/MRESOLVER-381 -- 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] slachiewicz commented on pull request #298: Bump jetty-server from 9.4.51.v20230217 to 11.0.14 in /maven-resolver-transport-http
slachiewicz commented on PR #298: URL: https://github.com/apache/maven-resolver/pull/298#issuecomment-1615006260 @dependabot ignore this major version Java 11 -- 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] dependabot[bot] commented on pull request #298: Bump jetty-server from 9.4.51.v20230217 to 11.0.14 in /maven-resolver-transport-http
dependabot[bot] commented on PR #298: URL: https://github.com/apache/maven-resolver/pull/298#issuecomment-1615006317 OK, I won't notify you about version 11.x.x again, unless you re-open this PR. 😢 -- 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] dependabot[bot] closed pull request #298: Bump jetty-server from 9.4.51.v20230217 to 11.0.14 in /maven-resolver-transport-http
dependabot[bot] closed pull request #298: Bump jetty-server from 9.4.51.v20230217 to 11.0.14 in /maven-resolver-transport-http URL: https://github.com/apache/maven-resolver/pull/298 -- 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] (MRESOLVER-381) Undo MRESOLVER-373 as it was fixed by other means
[ https://issues.apache.org/jira/browse/MRESOLVER-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-381: -- Description: The MRESOLVER-373 made two important operations serialized (again, since existence of locks), but the proper fix was actually this one (also part of MRESOLVER-373): https://github.com/apache/maven-resolver/commit/4fb1cf93b478ab1eeb563c3e69ad888017265e54 And given that artifacts and metadata does not use same lock name, the code undone would work. Still, errors would occur again, with "static" name mapper (maps always to same name), hence some smarter change is needed: when artifact resolver invokes metadata resolver, maybe it needs to unlock and then invoke? The ultimate goal: to not serialize on "happy path", but make it use "shared" locking so multiple thread can work together. was: The MRESOLVER-373 made two important operations serialized (again, since existence of locks), but the proper fix was actually this one (also part of MRESOLVER-373): https://github.com/apache/maven-resolver/commit/4fb1cf93b478ab1eeb563c3e69ad888017265e54 And given that artifacts and metadata does not use same lock name, the code undone would work. Still, errors would occur again, with "static" name mapper (maps always to same name), hence some smarter change is needed: when artifact resolver invokes metadata resolver, maybe it needs to unlock and then invoke? The ultimate goal: to not serialize on "happy path", but make it use "shared" locking. > Undo MRESOLVER-373 as it was fixed by other means > - > > Key: MRESOLVER-381 > URL: https://issues.apache.org/jira/browse/MRESOLVER-381 > Project: Maven Resolver > Issue Type: Task >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.14 > > > The MRESOLVER-373 made two important operations serialized (again, since > existence of locks), but the proper fix was actually this one (also part of > MRESOLVER-373): > https://github.com/apache/maven-resolver/commit/4fb1cf93b478ab1eeb563c3e69ad888017265e54 > And given that artifacts and metadata does not use same lock name, the code > undone would work. Still, errors would occur again, with "static" name mapper > (maps always to same name), hence some smarter change is needed: when > artifact resolver invokes metadata resolver, maybe it needs to unlock and > then invoke? > The ultimate goal: to not serialize on "happy path", but make it use "shared" > locking so multiple thread can work together. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-381) Undo MRESOLVER-373 as it was fixed by other means
[ https://issues.apache.org/jira/browse/MRESOLVER-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-381: -- Description: The MRESOLVER-373 made two important operations serialized (again, since existence of locks), but the proper fix was actually this one (also part of MRESOLVER-373): https://github.com/apache/maven-resolver/commit/4fb1cf93b478ab1eeb563c3e69ad888017265e54 And given that artifacts and metadata does not use same lock name, the code undone would work. Still, errors would occur again, with "static" name mapper (maps always to same name), hence some smarter change is needed: when artifact resolver invokes metadata resolver, maybe it needs to unlock and then invoke? The ultimate goal: to not serialize on "happy path", but make it use "shared" locking. was: The MRESOLVER-373 made two important operations serialized (again, since existence of locks), but the proper fix was actually this one (also part of MRESOLVER-373): https://github.com/apache/maven-resolver/commit/4fb1cf93b478ab1eeb563c3e69ad888017265e54 And given that artifacts and metadata does not use same lock name, the code undone would work. Still, errors would occur again, with "static" name mapper (maps always to same name), hence some smarter change is needed: when artifact resolver invokes metadata resolver, maybe it needs to unlock and then invoke? > Undo MRESOLVER-373 as it was fixed by other means > - > > Key: MRESOLVER-381 > URL: https://issues.apache.org/jira/browse/MRESOLVER-381 > Project: Maven Resolver > Issue Type: Task >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.14 > > > The MRESOLVER-373 made two important operations serialized (again, since > existence of locks), but the proper fix was actually this one (also part of > MRESOLVER-373): > https://github.com/apache/maven-resolver/commit/4fb1cf93b478ab1eeb563c3e69ad888017265e54 > And given that artifacts and metadata does not use same lock name, the code > undone would work. Still, errors would occur again, with "static" name mapper > (maps always to same name), hence some smarter change is needed: when > artifact resolver invokes metadata resolver, maybe it needs to unlock and > then invoke? > The ultimate goal: to not serialize on "happy path", but make it use "shared" > locking. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-381) Undo MRESOLVER-373 as it was fixed by other means
Tamas Cservenak created MRESOLVER-381: - Summary: Undo MRESOLVER-373 as it was fixed by other means Key: MRESOLVER-381 URL: https://issues.apache.org/jira/browse/MRESOLVER-381 Project: Maven Resolver Issue Type: Task Reporter: Tamas Cservenak Fix For: 1.9.14 The MRESOLVER-373 made two important operations serialized (again, since existence of locks), but the proper fix was actually this one (also part of MRESOLVER-373): https://github.com/apache/maven-resolver/commit/4fb1cf93b478ab1eeb563c3e69ad888017265e54 And given that artifacts and metadata does not use same lock name, the code undone would work. Still, errors would occur again, with "static" name mapper (maps always to same name), hence some smarter change is needed: when artifact resolver invokes metadata resolver, maybe it needs to unlock and then invoke? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-380) Lock diagnostic: attempted step is recorded, but on failed attempt is not removed
[
https://issues.apache.org/jira/browse/MRESOLVER-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739177#comment-17739177
]
ASF GitHub Bot commented on MRESOLVER-380:
--
cstamas opened a new pull request, #313:
URL: https://github.com/apache/maven-resolver/pull/313
And logged thread diag does not distinguish: "waits for X" or "has X".
---
https://issues.apache.org/jira/browse/MRESOLVER-380
> Lock diagnostic: attempted step is recorded, but on failed attempt is not
> removed
> -
>
> Key: MRESOLVER-380
> URL: https://issues.apache.org/jira/browse/MRESOLVER-380
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.14
>
>
> Hence, diagnostic may end up showing "impossible" states, like this one:
> {noformat}
> 2023-06-30T16:26:31.9073057Z [INFO] Name:
> artifact:com.fasterxml.jackson.core:jackson-annotations:2.10.3
> 2023-06-30T16:26:31.9073415Z [INFO] RefCount: 5
> 2023-06-30T16:26:31.9074303Z [INFO]
> Thread[dependency-version-check-worker-6,5,main] -> [exclusive, exclusive,
> exclusive, exclusive]
> 2023-06-30T16:26:31.9074965Z [INFO]
> Thread[dependency-version-check-worker-0,5,main] -> [exclusive, exclusive,
> exclusive, exclusive]
> 2023-06-30T16:26:31.9075806Z [INFO]
> Thread[dependency-version-check-worker-4,5,main] -> [exclusive]
> 2023-06-30T16:26:31.9076452Z [INFO]
> Thread[dependency-version-check-worker-5,5,main] -> [exclusive, exclusive,
> exclusive, exclusive]
> 2023-06-30T16:26:31.9077202Z [INFO]
> Thread[dependency-version-check-worker-2,5,main] -> [exclusive, exclusive]
> 2023-06-30T16:26:31.900Z [INFO]
> Thread[dependency-version-check-worker-9,5,main] -> [exclusive, exclusive]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] cstamas opened a new pull request, #313: [MRESOLVER-380] Failed attempts are not removed
cstamas opened a new pull request, #313: URL: https://github.com/apache/maven-resolver/pull/313 And logged thread diag does not distinguish: "waits for X" or "has X". --- https://issues.apache.org/jira/browse/MRESOLVER-380 -- 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-380) Lock diagnostic: attempted step is recorded, but on failed attempt is not removed
Tamas Cservenak created MRESOLVER-380:
-
Summary: Lock diagnostic: attempted step is recorded, but on
failed attempt is not removed
Key: MRESOLVER-380
URL: https://issues.apache.org/jira/browse/MRESOLVER-380
Project: Maven Resolver
Issue Type: Bug
Components: Resolver
Reporter: Tamas Cservenak
Fix For: 1.9.14
Hence, diagnostic may end up showing "impossible" states, like this one:
{noformat}
2023-06-30T16:26:31.9073057Z [INFO] Name:
artifact:com.fasterxml.jackson.core:jackson-annotations:2.10.3
2023-06-30T16:26:31.9073415Z [INFO] RefCount: 5
2023-06-30T16:26:31.9074303Z [INFO]
Thread[dependency-version-check-worker-6,5,main] -> [exclusive, exclusive,
exclusive, exclusive]
2023-06-30T16:26:31.9074965Z [INFO]
Thread[dependency-version-check-worker-0,5,main] -> [exclusive, exclusive,
exclusive, exclusive]
2023-06-30T16:26:31.9075806Z [INFO]
Thread[dependency-version-check-worker-4,5,main] -> [exclusive]
2023-06-30T16:26:31.9076452Z [INFO]
Thread[dependency-version-check-worker-5,5,main] -> [exclusive, exclusive,
exclusive, exclusive]
2023-06-30T16:26:31.9077202Z [INFO]
Thread[dependency-version-check-worker-2,5,main] -> [exclusive, exclusive]
2023-06-30T16:26:31.900Z [INFO]
Thread[dependency-version-check-worker-9,5,main] -> [exclusive, exclusive]
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-49) Allow caching for pom package projects
[
https://issues.apache.org/jira/browse/MBUILDCACHE-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739131#comment-17739131
]
Felix Simmendinger commented on MBUILDCACHE-49:
---
It is not only the build logic. The comment in the
{{org.apache.maven.buildcache.checksum.MavenProjectInput#getMutableDependencies}}
that it is sufficient to cache effective poms is wrong. In our project, we
have a pom module that serves as a dependency holder for runtime dependencies
to be managed by a command-line client to enable/disable extensions to an
application. With the extension ignoring to cache pom dependencies, the
depenency tracking is broken and changes to transitive dependencies referenced
by this pom project won't trigger a rebuild of the application module.
{code:java}
app
|
-
|\
libs `- module-x (type jar)
| (runtime scope, snapshot from same project)
extension-dependencies (type pom)
| (runtime scope, snapshot from same project)
`- extension-a (type jar, snapshot from same project){code}
if i change a line in extension-a, app won't be rebuild.
> Allow caching for pom package projects
> --
>
> Key: MBUILDCACHE-49
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-49
> Project: Maven Build Cache Extension
> Issue Type: New Feature
>Affects Versions: 1.0.0
>Reporter: Tomáš Mrázek
>Priority: Major
>
> In class `MavenProjectInput` and method `calculateChecksum()` at line `207`
> is check for pom project and if true, input files are skipped. What was the
> reason behind ignoring pom projects? I've seen plenty of pom projects with
> some build logic where caching does make a sense. For example some resource
> transformations or building external projects via exec-maven-plugin. In those
> cases both source and target files exist but different packaing other than
> pom does not make a lot of sense.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJAVADOC-754) Plugin depends on plexus-container-default, which is EOL
[ https://issues.apache.org/jira/browse/MJAVADOC-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated MJAVADOC-754: Description: Running with Maven 3.9.2 on Mac OS X, I see the following warning emitted by Maven about the javadoc plugin. [WARNING] * org.apache.maven.plugins:maven-javadoc-plugin:3.5.0 [WARNING] Declared at location(s): [WARNING] * io.kroxylicious:kroxylicious-parent:0.3.0-SNAPSHOT (pom.xml) @ line 489 [WARNING] * io.kroxylicious:kroxylicious-test-tools:0.3.0-SNAPSHOT (kroxylicious-test-tools/pom.xml) @ line 175 [WARNING] * io.kroxylicious:performance-tests:0.3.0-SNAPSHOT (performance-tests/pom.xml) @ line 96 [WARNING] Used in module(s): [WARNING] * io.kroxylicious:kroxylicious-parent:0.3.0-SNAPSHOT (pom.xml) [WARNING] * io.kroxylicious:kroxylicious-api:0.3.0-SNAPSHOT (api/kroxylicious-api/pom.xml) [WARNING] * io.kroxylicious:kroxylicious-krpc-plugin:0.3.0-SNAPSHOT (krpc-code-gen/pom.xml) [WARNING] * io.kroxylicious:kroxylicious-filter-api:0.3.0-SNAPSHOT (api/kroxylicious-filter-api/pom.xml) [WARNING] * io.kroxylicious:kroxylicious-unit-test:0.3.0-SNAPSHOT (kroxylicious-unit-test/pom.xml) [WARNING] * io.kroxylicious:kroxylicious:0.3.0-SNAPSHOT (kroxylicious/pom.xml) [WARNING] * io.kroxylicious:kroxylicious-test-tools:0.3.0-SNAPSHOT (kroxylicious-test-tools/pom.xml) [WARNING] * io.kroxylicious:kroxylicious-additional-filters:0.3.0-SNAPSHOT (kroxylicious-additional-filters/pom.xml) [WARNING] * io.kroxylicious:kroxylicious-multitenant:0.3.0-SNAPSHOT (kroxylicious-additional-filters/kroxylicious-multitenant/pom.xml) [WARNING] * io.kroxylicious:kroxylicious-schema-validation:0.3.0-SNAPSHOT (kroxylicious-additional-filters/kroxylicious-schema-validation/pom.xml) [WARNING] * io.kroxylicious:integrationtests:0.3.0-SNAPSHOT (integrationtests/pom.xml) [WARNING] * io.kroxylicious:kroxylicious-sample:0.3.0-SNAPSHOT (kroxylicious-sample/pom.xml) [WARNING] * io.kroxylicious:performance-tests:0.3.0-SNAPSHOT (performance-tests/dependency-reduced-pom.xml) [WARNING] Plugin issue(s): [WARNING] * Plugin depends on plexus-container-default, which is EOL Judging by the statements made by: [https://codehaus-plexus.github.io/plexus-containers/plexus-container-default/ |https://codehaus-plexus.github.io/plexus-containers/plexus-container-default/]the component is indeed EOL. Is there a plan to migrate the plugin to a replacement dependency? Thank you. was: Running with Maven 3.9.2 on Mac OS X, I see the following warning emitted by Maven about the javadoc plugin. [WARNING] * org.apache.maven.plugins:maven-javadoc-plugin:3.5.0 [WARNING] Declared at location(s): [WARNING] * io.kroxylicious:kroxylicious-parent:0.3.0-SNAPSHOT (pom.xml) @ line 489 [WARNING] * io.kroxylicious:kroxylicious-test-tools:0.3.0-SNAPSHOT (kroxylicious-test-tools/pom.xml) @ line 175 [WARNING] * io.kroxylicious:performance-tests:0.3.0-SNAPSHOT (performance-tests/pom.xml) @ line 96 [WARNING] Used in module(s): [WARNING] * io.kroxylicious:kroxylicious-parent:0.3.0-SNAPSHOT (pom.xml) [WARNING] * io.kroxylicious:kroxylicious-api:0.3.0-SNAPSHOT (api/kroxylicious-api/pom.xml) [WARNING] * io.kroxylicious:kroxylicious-krpc-plugin:0.3.0-SNAPSHOT (krpc-code-gen/pom.xml) [WARNING] * io.kroxylicious:kroxylicious-filter-api:0.3.0-SNAPSHOT (api/kroxylicious-filter-api/pom.xml) [WARNING] * io.kroxylicious:kroxylicious-unit-test:0.3.0-SNAPSHOT (kroxylicious-unit-test/pom.xml) [WARNING] * io.kroxylicious:kroxylicious:0.3.0-SNAPSHOT (kroxylicious/pom.xml) [WARNING] * io.kroxylicious:kroxylicious-test-tools:0.3.0-SNAPSHOT (kroxylicious-test-tools/pom.xml) [WARNING] * io.kroxylicious:kroxylicious-additional-filters:0.3.0-SNAPSHOT (kroxylicious-additional-filters/pom.xml) [WARNING] * io.kroxylicious:kroxylicious-multitenant:0.3.0-SNAPSHOT (kroxylicious-additional-filters/kroxylicious-multitenant/pom.xml) [WARNING] * io.kroxylicious:kroxylicious-schema-validation:0.3.0-SNAPSHOT (kroxylicious-additional-filters/kroxylicious-schema-validation/pom.xml) [WARNING] * io.kroxylicious:integrationtests:0.3.0-SNAPSHOT (integrationtests/pom.xml) [WARNING] * io.kroxylicious:kroxylicious-sample:0.3.0-SNAPSHOT (kroxylicious-sample/pom.xml) [WARNING] * io.kroxylicious:performance-tests:0.3.0-SNAPSHOT (performance-tests/dependency-reduced-pom.xml) [WARNING] Plugin issue(s): [WARNING] * Plugin depends on plexus-container-default, which is EOL Judging by the statements made by: [https://codehaus-plexus.github.io/plexus-containers/plexus-container-default/ |https://codehaus-plexus.github.io/plexus-containers/plexus-container-default/]the component is indeed EOL. Is there a plan to migrate the plugin to a replacement dependenecy? Thank you. > Plugin depends on plexus-container-default, which is EOL >
[jira] [Updated] (MJAVADOC-754) Plugin depends on plexus-container-default, which is EOL
[ https://issues.apache.org/jira/browse/MJAVADOC-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated MJAVADOC-754: Environment: mvn --version Apache Maven 3.9.2 (c9616018c7a021c1c39be70fb2843d6f5f9b8a1c) Maven home: /usr/local/Cellar/maven/3.9.2/libexec Java version: 20.0.1, vendor: Homebrew, runtime: /usr/local/Cellar/openjdk/20.0.1/libexec/openjdk.jdk/Contents/Home Default locale: en_GB, platform encoding: UTF-8 OS name: "mac os x", version: "13.4.1", arch: "x86_64", family: "mac" > Plugin depends on plexus-container-default, which is EOL > > > Key: MJAVADOC-754 > URL: https://issues.apache.org/jira/browse/MJAVADOC-754 > Project: Maven Javadoc Plugin > Issue Type: Bug > Environment: mvn --version > Apache Maven 3.9.2 (c9616018c7a021c1c39be70fb2843d6f5f9b8a1c) > Maven home: /usr/local/Cellar/maven/3.9.2/libexec > Java version: 20.0.1, vendor: Homebrew, runtime: > /usr/local/Cellar/openjdk/20.0.1/libexec/openjdk.jdk/Contents/Home > Default locale: en_GB, platform encoding: UTF-8 > OS name: "mac os x", version: "13.4.1", arch: "x86_64", family: "mac" >Reporter: Keith Wall >Priority: Major > > Running with Maven 3.9.2 on Mac OS X, I see the following warning emitted by > Maven about the javadoc plugin. > > [WARNING] * org.apache.maven.plugins:maven-javadoc-plugin:3.5.0 > [WARNING] Declared at location(s): > [WARNING] * io.kroxylicious:kroxylicious-parent:0.3.0-SNAPSHOT (pom.xml) @ > line 489 > [WARNING] * io.kroxylicious:kroxylicious-test-tools:0.3.0-SNAPSHOT > (kroxylicious-test-tools/pom.xml) @ line 175 > [WARNING] * io.kroxylicious:performance-tests:0.3.0-SNAPSHOT > (performance-tests/pom.xml) @ line 96 > [WARNING] Used in module(s): > [WARNING] * io.kroxylicious:kroxylicious-parent:0.3.0-SNAPSHOT (pom.xml) > [WARNING] * io.kroxylicious:kroxylicious-api:0.3.0-SNAPSHOT > (api/kroxylicious-api/pom.xml) > [WARNING] * io.kroxylicious:kroxylicious-krpc-plugin:0.3.0-SNAPSHOT > (krpc-code-gen/pom.xml) > [WARNING] * io.kroxylicious:kroxylicious-filter-api:0.3.0-SNAPSHOT > (api/kroxylicious-filter-api/pom.xml) > [WARNING] * io.kroxylicious:kroxylicious-unit-test:0.3.0-SNAPSHOT > (kroxylicious-unit-test/pom.xml) > [WARNING] * io.kroxylicious:kroxylicious:0.3.0-SNAPSHOT > (kroxylicious/pom.xml) > [WARNING] * io.kroxylicious:kroxylicious-test-tools:0.3.0-SNAPSHOT > (kroxylicious-test-tools/pom.xml) > [WARNING] * io.kroxylicious:kroxylicious-additional-filters:0.3.0-SNAPSHOT > (kroxylicious-additional-filters/pom.xml) > [WARNING] * io.kroxylicious:kroxylicious-multitenant:0.3.0-SNAPSHOT > (kroxylicious-additional-filters/kroxylicious-multitenant/pom.xml) > [WARNING] * io.kroxylicious:kroxylicious-schema-validation:0.3.0-SNAPSHOT > (kroxylicious-additional-filters/kroxylicious-schema-validation/pom.xml) > [WARNING] * io.kroxylicious:integrationtests:0.3.0-SNAPSHOT > (integrationtests/pom.xml) > [WARNING] * io.kroxylicious:kroxylicious-sample:0.3.0-SNAPSHOT > (kroxylicious-sample/pom.xml) > [WARNING] * io.kroxylicious:performance-tests:0.3.0-SNAPSHOT > (performance-tests/dependency-reduced-pom.xml) > [WARNING] Plugin issue(s): > [WARNING] * Plugin depends on plexus-container-default, which is EOL > > Judging by the statements made by: > [https://codehaus-plexus.github.io/plexus-containers/plexus-container-default/ > > |https://codehaus-plexus.github.io/plexus-containers/plexus-container-default/]the > component is indeed EOL. > Is there a plan to migrate the plugin to a replacement dependenecy? > Thank you. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MJAVADOC-754) Plugin depends on plexus-container-default, which is EOL
Keith Wall created MJAVADOC-754: --- Summary: Plugin depends on plexus-container-default, which is EOL Key: MJAVADOC-754 URL: https://issues.apache.org/jira/browse/MJAVADOC-754 Project: Maven Javadoc Plugin Issue Type: Bug Reporter: Keith Wall Running with Maven 3.9.2 on Mac OS X, I see the following warning emitted by Maven about the javadoc plugin. [WARNING] * org.apache.maven.plugins:maven-javadoc-plugin:3.5.0 [WARNING] Declared at location(s): [WARNING] * io.kroxylicious:kroxylicious-parent:0.3.0-SNAPSHOT (pom.xml) @ line 489 [WARNING] * io.kroxylicious:kroxylicious-test-tools:0.3.0-SNAPSHOT (kroxylicious-test-tools/pom.xml) @ line 175 [WARNING] * io.kroxylicious:performance-tests:0.3.0-SNAPSHOT (performance-tests/pom.xml) @ line 96 [WARNING] Used in module(s): [WARNING] * io.kroxylicious:kroxylicious-parent:0.3.0-SNAPSHOT (pom.xml) [WARNING] * io.kroxylicious:kroxylicious-api:0.3.0-SNAPSHOT (api/kroxylicious-api/pom.xml) [WARNING] * io.kroxylicious:kroxylicious-krpc-plugin:0.3.0-SNAPSHOT (krpc-code-gen/pom.xml) [WARNING] * io.kroxylicious:kroxylicious-filter-api:0.3.0-SNAPSHOT (api/kroxylicious-filter-api/pom.xml) [WARNING] * io.kroxylicious:kroxylicious-unit-test:0.3.0-SNAPSHOT (kroxylicious-unit-test/pom.xml) [WARNING] * io.kroxylicious:kroxylicious:0.3.0-SNAPSHOT (kroxylicious/pom.xml) [WARNING] * io.kroxylicious:kroxylicious-test-tools:0.3.0-SNAPSHOT (kroxylicious-test-tools/pom.xml) [WARNING] * io.kroxylicious:kroxylicious-additional-filters:0.3.0-SNAPSHOT (kroxylicious-additional-filters/pom.xml) [WARNING] * io.kroxylicious:kroxylicious-multitenant:0.3.0-SNAPSHOT (kroxylicious-additional-filters/kroxylicious-multitenant/pom.xml) [WARNING] * io.kroxylicious:kroxylicious-schema-validation:0.3.0-SNAPSHOT (kroxylicious-additional-filters/kroxylicious-schema-validation/pom.xml) [WARNING] * io.kroxylicious:integrationtests:0.3.0-SNAPSHOT (integrationtests/pom.xml) [WARNING] * io.kroxylicious:kroxylicious-sample:0.3.0-SNAPSHOT (kroxylicious-sample/pom.xml) [WARNING] * io.kroxylicious:performance-tests:0.3.0-SNAPSHOT (performance-tests/dependency-reduced-pom.xml) [WARNING] Plugin issue(s): [WARNING] * Plugin depends on plexus-container-default, which is EOL Judging by the statements made by: [https://codehaus-plexus.github.io/plexus-containers/plexus-container-default/ |https://codehaus-plexus.github.io/plexus-containers/plexus-container-default/]the component is indeed EOL. Is there a plan to migrate the plugin to a replacement dependenecy? Thank you. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (DOXIASITETOOLS-309) Add resource bundle property "External Links" to site-renderer.properties
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed DOXIASITETOOLS-309. - Resolution: Fixed Fixed with [c5659f12b54a614b6a90178013d7d05f90c9d6cf|https://gitbox.apache.org/repos/asf?p=maven-doxia-sitetools.git&a=commit&h=c5659f12b54a614b6a90178013d7d05f90c9d6cf]. > Add resource bundle property "External Links" to site-renderer.properties > - > > Key: DOXIASITETOOLS-309 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-309 > Project: Maven Doxia Sitetools > Issue Type: Task > Components: Site renderer >Affects Versions: 2.0.0-M10 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.0.0-M11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (DOXIASITETOOLS-310) Add resource bundle property "Edit" to site-renderer.properties
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed DOXIASITETOOLS-310. - Resolution: Fixed Fixed with [5b9f9909fcf341606aff3dbc8c5056c93c51aa5d|https://gitbox.apache.org/repos/asf?p=maven-doxia-sitetools.git&a=commit&h=5b9f9909fcf341606aff3dbc8c5056c93c51aa5d]. > Add resource bundle property "Edit" to site-renderer.properties > --- > > Key: DOXIASITETOOLS-310 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-310 > Project: Maven Doxia Sitetools > Issue Type: Task > Components: Site renderer >Affects Versions: 2.0.0-M10 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.0.0-M11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739053#comment-17739053
]
ASF GitHub Bot commented on MRESOLVER-376:
--
snjeza commented on PR #309:
URL: https://github.com/apache/maven-resolver/pull/309#issuecomment-1614550741
> I think this PR is to be superseded by this "proper fix":
https://github.com/apache/maven-resolver/pull/311
@snjeza @caiwei-ebay2
LGTM
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-377) Introduce metadata update policy
[ https://issues.apache.org/jira/browse/MRESOLVER-377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-377: -- Fix Version/s: 1.10.0 (was: 1.9.14) > Introduce metadata update policy > > > Key: MRESOLVER-377 > URL: https://issues.apache.org/jira/browse/MRESOLVER-377 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.10.0 > > > Basically double the update policy, from RemoteRepository all way where > needed, and make Resolver support separate "data" updatePolicy and "metadata" > updatePolicy. > Maven does not have to make use of this (setting updatePolicy == > metadataUpdatePolicy results in functionality like today, where there is only > one policy). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-379) Problem when relocations and ranges are used in collection
[
https://issues.apache.org/jira/browse/MRESOLVER-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739031#comment-17739031
]
Tamas Cservenak edited comment on MRESOLVER-379 at 6/30/23 11:12 AM:
-
Seems related, as it is exactly what happens it seems: MNG-3454
Note: this issue is Maven2, but Maven3/Resolver was done by strictly mimicking
Maven2 behavior to lessen breakages and ease migration.
Based on issue, this can be considered as edge case and just have it documented?
was (Author: cstamas):
Seems related, as it is exactly what happens it seems: MNG-3454
Note: this issue is Maven2, but Maven3/Resolver was done by strictly mimicking
Maven2 behavior to lessen breakages and ease migration.
> Problem when relocations and ranges are used in collection
> --
>
> Key: MRESOLVER-379
> URL: https://issues.apache.org/jira/browse/MRESOLVER-379
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
>
> Affects both old DF and new BF collectors.
> Example:
> * A1 -> B[1,3]
> * B1 relocated to C1
> * B2 relocated to C2
> * B3 relocated to C3
> In this example, as output of collection dirty tree (verbose) I'd expect:
> {noformat}
> A1
> +- C1
> +- C2
> +- C3
> {noformat}
> But none of the DF or BF produce this, moreover, they produce DIFFERENT
> outputs:
> DF does this:
> {noformat}
> A1
> +- C1
> {noformat}
> BF does this:
> {noformat}
> A1
> +- C3
> {noformat}
> Cause is probably as BF "reverse sort" versions, but none will return proper
> range.
> Real life example: MRESOLVER-376, where junit:junit-dep:[4.9,) range "maps
> itself" onto junit:junit versions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-379) Problem when relocations and ranges are used in collection
[
https://issues.apache.org/jira/browse/MRESOLVER-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739031#comment-17739031
]
Tamas Cservenak commented on MRESOLVER-379:
---
Seems related, as it is exactly what happens it seems: MNG-3454
Note: this issue is Maven2, but Maven3/Resolver was done by strictly mimicking
Maven2 behavior to lessen breakages and ease migration.
> Problem when relocations and ranges are used in collection
> --
>
> Key: MRESOLVER-379
> URL: https://issues.apache.org/jira/browse/MRESOLVER-379
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
>
> Affects both old DF and new BF collectors.
> Example:
> * A1 -> B[1,3]
> * B1 relocated to C1
> * B2 relocated to C2
> * B3 relocated to C3
> In this example, as output of collection dirty tree (verbose) I'd expect:
> {noformat}
> A1
> +- C1
> +- C2
> +- C3
> {noformat}
> But none of the DF or BF produce this, moreover, they produce DIFFERENT
> outputs:
> DF does this:
> {noformat}
> A1
> +- C1
> {noformat}
> BF does this:
> {noformat}
> A1
> +- C3
> {noformat}
> Cause is probably as BF "reverse sort" versions, but none will return proper
> range.
> Real life example: MRESOLVER-376, where junit:junit-dep:[4.9,) range "maps
> itself" onto junit:junit versions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MDEP-879) Wanted: analyze-report-only goal
[
https://issues.apache.org/jira/browse/MDEP-879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739027#comment-17739027
]
Slawomir Jaranowski commented on MDEP-879:
--
PR are welcome.
> Wanted: analyze-report-only goal
>
>
> Key: MDEP-879
> URL: https://issues.apache.org/jira/browse/MDEP-879
> Project: Maven Dependency Plugin
> Issue Type: New Feature
>Reporter: Karsten Spang
>Priority: Major
> Labels: up-for-grabs
>
> I would like to have a report goal that does not trigger test-compile.
> I have several projects using generated sources. Since the sources are
> re-generated before the compile step, the compiler plugin does not skip over
> code already compiled. This takes unnecessary time when running {{mvn clean
> verify site}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MDEP-879) Wanted: analyze-report-only goal
[
https://issues.apache.org/jira/browse/MDEP-879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MDEP-879:
-
Labels: up-for-grabs (was: )
> Wanted: analyze-report-only goal
>
>
> Key: MDEP-879
> URL: https://issues.apache.org/jira/browse/MDEP-879
> Project: Maven Dependency Plugin
> Issue Type: New Feature
>Reporter: Karsten Spang
>Priority: Major
> Labels: up-for-grabs
>
> I would like to have a report goal that does not trigger test-compile.
> I have several projects using generated sources. Since the sources are
> re-generated before the compile step, the compiler plugin does not skip over
> code already compiled. This takes unnecessary time when running {{mvn clean
> verify site}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SUREFIRE-2184) debugForkedProcess should implicitly set forkCount to 1
Konrad Windszus created SUREFIRE-2184:
-
Summary: debugForkedProcess should implicitly set forkCount to 1
Key: SUREFIRE-2184
URL: https://issues.apache.org/jira/browse/SUREFIRE-2184
Project: Maven Surefire
Issue Type: Improvement
Components: process forking
Affects Versions: 3.1.2
Reporter: Konrad Windszus
Very often the parameter
[{{debugForkedProcess}}|https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#debugForkedProcess]
is set through Maven CLI. When used in combination with
[{{forkCount}}|https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#forkcount]
> 1 this always leads to issues as the debug port is obviously blocked if it
is already taken for one fork. Therefore it would be good to implicitly set the
{{forkCount}} to 1 in case {{debugForkedProcess}} is set (with a WARNING in the
log)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MDEP-879) Wanted: analyze-report-only goal
Karsten Spang created MDEP-879:
--
Summary: Wanted: analyze-report-only goal
Key: MDEP-879
URL: https://issues.apache.org/jira/browse/MDEP-879
Project: Maven Dependency Plugin
Issue Type: New Feature
Reporter: Karsten Spang
I would like to have a report goal that does not trigger test-compile.
I have several projects using generated sources. Since the sources are
re-generated before the compile step, the compiler plugin does not skip over
code already compiled. This takes unnecessary time when running {{mvn clean
verify site}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-379) Problem when relocations and ranges are used in collection
[
https://issues.apache.org/jira/browse/MRESOLVER-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-379:
--
Description:
Affects both old DF and new BF collectors.
Example:
* A1 -> B[1,3]
* B1 relocated to C1
* B2 relocated to C2
* B3 relocated to C3
In this example, as output of collection dirty tree (verbose) I'd expect:
{noformat}
A1
+- C1
+- C2
+- C3
{noformat}
But none of the DF or BF produce this, moreover, they produce DIFFERENT outputs:
DF does this:
{noformat}
A1
+- C1
{noformat}
BF does this:
{noformat}
A1
+- C3
{noformat}
Cause is probably as BF "reverse sort" versions, but none will return proper
range.
Real life example: MRESOLVER-376, where junit:junit-dep:[4.9,) range "maps
itself" onto junit:junit versions.
was:
Affects both old DF and new BF collectors.
Example:
* A1 -> B[1,3]
* B1 relocated to C1
* B2 relocated to C2
* B3 relocated to C3
In this example, as output of collection dirty tree I'd expect:
{noformat}
A1
+- C1
+- C2
+- C3
{noformat}
But none of the DF or BF produce this, moreover, they produce DIFFERENT outputs:
DF does this:
{noformat}
A1
+- C1
{noformat}
BF does this:
{noformat}
A1
+- C3
{noformat}
Cause is probably as BF "reverse sort" versions, but none will return proper
range.
Real life example: MRESOLVER-376, where junit:junit-dep:[4.9,) range "maps
itself" onto junit:junit versions.
> Problem when relocations and ranges are used in collection
> --
>
> Key: MRESOLVER-379
> URL: https://issues.apache.org/jira/browse/MRESOLVER-379
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
>
> Affects both old DF and new BF collectors.
> Example:
> * A1 -> B[1,3]
> * B1 relocated to C1
> * B2 relocated to C2
> * B3 relocated to C3
> In this example, as output of collection dirty tree (verbose) I'd expect:
> {noformat}
> A1
> +- C1
> +- C2
> +- C3
> {noformat}
> But none of the DF or BF produce this, moreover, they produce DIFFERENT
> outputs:
> DF does this:
> {noformat}
> A1
> +- C1
> {noformat}
> BF does this:
> {noformat}
> A1
> +- C3
> {noformat}
> Cause is probably as BF "reverse sort" versions, but none will return proper
> range.
> Real life example: MRESOLVER-376, where junit:junit-dep:[4.9,) range "maps
> itself" onto junit:junit versions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-379) Problem when relocations and ranges are used in collection
[
https://issues.apache.org/jira/browse/MRESOLVER-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739019#comment-17739019
]
Tamas Cservenak edited comment on MRESOLVER-379 at 6/30/23 10:17 AM:
-
Yes, "dirty tree", the "verbose" output. I used this existing (and passing) UT
as "template":
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.13/maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/collect/DependencyCollectorDelegateTestSupport.java#L501
That produces for BF this verbose tree:
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.13/maven-resolver-impl/src/test/resources/artifact-descriptions/transitiveDepsUseRangesDirtyTreeResult_BF.txt
While DF produce this verbose tree:
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.13/maven-resolver-impl/src/test/resources/artifact-descriptions/transitiveDepsUseRangesDirtyTreeResult_DF.txt
Only difference between BF and DF is version ordering (which is okay, see fix
MRESOLVER-345).
I basically copy-pasted this UT w/ data and created this UT:
https://github.com/apache/maven-resolver/pull/312
It reproduces the SOError on master, and on "fixed" branch makes BF behave as
in this issue (that is somehow consistent with DF sans version selected)
was (Author: cstamas):
Yes, "dirty tree", the "verbose" output. I used this existing (and passing) UT
as "template":
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.13/maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/collect/DependencyCollectorDelegateTestSupport.java#L501
That produces for BF this verbose tree:
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.13/maven-resolver-impl/src/test/resources/artifact-descriptions/transitiveDepsUseRangesDirtyTreeResult_BF.txt
While DF produce this verbose tree:
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.13/maven-resolver-impl/src/test/resources/artifact-descriptions/transitiveDepsUseRangesDirtyTreeResult_DF.txt
Only difference between BF and DF is version ordering.
I basically copy-pasted this UT w/ data and created this UT:
https://github.com/apache/maven-resolver/pull/312
It reproduces the SOError on master, and on "fixed" branch makes BF behave as
in this issue (that is somehow consistent with DF sans version selected)
> Problem when relocations and ranges are used in collection
> --
>
> Key: MRESOLVER-379
> URL: https://issues.apache.org/jira/browse/MRESOLVER-379
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
>
> Affects both old DF and new BF collectors.
> Example:
> * A1 -> B[1,3]
> * B1 relocated to C1
> * B2 relocated to C2
> * B3 relocated to C3
> In this example, as output of collection dirty tree I'd expect:
> {noformat}
> A1
> +- C1
> +- C2
> +- C3
> {noformat}
> But none of the DF or BF produce this, moreover, they produce DIFFERENT
> outputs:
> DF does this:
> {noformat}
> A1
> +- C1
> {noformat}
> BF does this:
> {noformat}
> A1
> +- C3
> {noformat}
> Cause is probably as BF "reverse sort" versions, but none will return proper
> range.
> Real life example: MRESOLVER-376, where junit:junit-dep:[4.9,) range "maps
> itself" onto junit:junit versions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-379) Problem when relocations and ranges are used in collection
[
https://issues.apache.org/jira/browse/MRESOLVER-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739019#comment-17739019
]
Tamas Cservenak edited comment on MRESOLVER-379 at 6/30/23 10:16 AM:
-
Yes, "dirty tree", the "verbose" output. I used this existing (and passing) UT
as "template":
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.13/maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/collect/DependencyCollectorDelegateTestSupport.java#L501
That produces for BF this verbose tree:
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.13/maven-resolver-impl/src/test/resources/artifact-descriptions/transitiveDepsUseRangesDirtyTreeResult_BF.txt
While DF produce this verbose tree:
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.13/maven-resolver-impl/src/test/resources/artifact-descriptions/transitiveDepsUseRangesDirtyTreeResult_DF.txt
Only difference between BF and DF is version ordering.
I basically copy-pasted this UT w/ data and created this UT:
https://github.com/apache/maven-resolver/pull/312
It reproduces the SOError on master, and on "fixed" branch makes BF behave as
in this issue (that is somehow consistent with DF sans version selected)
was (Author: cstamas):
Yes, "dirty tree", the "verbose" output. I used this existing (and passing) UT
as "template":
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.13/maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/collect/DependencyCollectorDelegateTestSupport.java#L501
That produces for BF this verbose tree:
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.13/maven-resolver-impl/src/test/resources/artifact-descriptions/transitiveDepsUseRangesDirtyTreeResult_BF.txt
While DF produce this verbose tree:
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.13/maven-resolver-impl/src/test/resources/artifact-descriptions/transitiveDepsUseRangesDirtyTreeResult_DF.txt
Only difference between BF and DF is version ordering.
> Problem when relocations and ranges are used in collection
> --
>
> Key: MRESOLVER-379
> URL: https://issues.apache.org/jira/browse/MRESOLVER-379
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
>
> Affects both old DF and new BF collectors.
> Example:
> * A1 -> B[1,3]
> * B1 relocated to C1
> * B2 relocated to C2
> * B3 relocated to C3
> In this example, as output of collection dirty tree I'd expect:
> {noformat}
> A1
> +- C1
> +- C2
> +- C3
> {noformat}
> But none of the DF or BF produce this, moreover, they produce DIFFERENT
> outputs:
> DF does this:
> {noformat}
> A1
> +- C1
> {noformat}
> BF does this:
> {noformat}
> A1
> +- C3
> {noformat}
> Cause is probably as BF "reverse sort" versions, but none will return proper
> range.
> Real life example: MRESOLVER-376, where junit:junit-dep:[4.9,) range "maps
> itself" onto junit:junit versions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-379) Problem when relocations and ranges are used in collection
[
https://issues.apache.org/jira/browse/MRESOLVER-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739019#comment-17739019
]
Tamas Cservenak commented on MRESOLVER-379:
---
Yes, "dirty tree", the "verbose" output. I used this existing (and passing) UT
as "template":
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.13/maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/collect/DependencyCollectorDelegateTestSupport.java#L501
That produces for BF this verbose tree:
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.13/maven-resolver-impl/src/test/resources/artifact-descriptions/transitiveDepsUseRangesDirtyTreeResult_BF.txt
While DF produce this verbose tree:
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.13/maven-resolver-impl/src/test/resources/artifact-descriptions/transitiveDepsUseRangesDirtyTreeResult_DF.txt
Only difference between BF and DF is version ordering.
> Problem when relocations and ranges are used in collection
> --
>
> Key: MRESOLVER-379
> URL: https://issues.apache.org/jira/browse/MRESOLVER-379
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
>
> Affects both old DF and new BF collectors.
> Example:
> * A1 -> B[1,3]
> * B1 relocated to C1
> * B2 relocated to C2
> * B3 relocated to C3
> In this example, as output of collection dirty tree I'd expect:
> {noformat}
> A1
> +- C1
> +- C2
> +- C3
> {noformat}
> But none of the DF or BF produce this, moreover, they produce DIFFERENT
> outputs:
> DF does this:
> {noformat}
> A1
> +- C1
> {noformat}
> BF does this:
> {noformat}
> A1
> +- C3
> {noformat}
> Cause is probably as BF "reverse sort" versions, but none will return proper
> range.
> Real life example: MRESOLVER-376, where junit:junit-dep:[4.9,) range "maps
> itself" onto junit:junit versions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-379) Problem when relocations and ranges are used in collection
[
https://issues.apache.org/jira/browse/MRESOLVER-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-379:
--
Description:
Affects both old DF and new BF collectors.
Example:
* A1 -> B[1,3]
* B1 relocated to C1
* B2 relocated to C2
* B3 relocated to C3
In this example, as output of collection dirty tree I'd expect:
{noformat}
A1
+- C1
+- C2
+- C3
{noformat}
But none of the DF or BF produce this, moreover, they produce DIFFERENT outputs:
DF does this:
{noformat}
A1
+- C1
{noformat}
BF does this:
{noformat}
A1
+- C3
{noformat}
Cause is probably as BF "reverse sort" versions, but none will return proper
range.
Real life example: MRESOLVER-376, where junit:junit-dep:[4.9,) range "maps
itself" onto junit:junit versions.
was:
Affects both old DF and new BF collectors.
Example:
* A1 -> B[1,3]
* B1 relocated to C1
* B2 relocated to C2
* B3 relocated to C3
In this example, as output of collection dirty tree I'd expect:
{noformat}
A1
+ - C1
+ - C2
+ - C3
{noformat}
But none of the DF or BF produce this, moreover, they produce DIFFERENT outputs:
DF does this:
{noformat}
A1
+ - C1
{noformat}
BF does this:
{noformat}
A1
+ - C3
{noformat}
Cause is probably as BF "reverse sort" versions, but none will return proper
range.
> Problem when relocations and ranges are used in collection
> --
>
> Key: MRESOLVER-379
> URL: https://issues.apache.org/jira/browse/MRESOLVER-379
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
>
> Affects both old DF and new BF collectors.
> Example:
> * A1 -> B[1,3]
> * B1 relocated to C1
> * B2 relocated to C2
> * B3 relocated to C3
> In this example, as output of collection dirty tree I'd expect:
> {noformat}
> A1
> +- C1
> +- C2
> +- C3
> {noformat}
> But none of the DF or BF produce this, moreover, they produce DIFFERENT
> outputs:
> DF does this:
> {noformat}
> A1
> +- C1
> {noformat}
> BF does this:
> {noformat}
> A1
> +- C3
> {noformat}
> Cause is probably as BF "reverse sort" versions, but none will return proper
> range.
> Real life example: MRESOLVER-376, where junit:junit-dep:[4.9,) range "maps
> itself" onto junit:junit versions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-379) Problem when relocations and ranges are used in collection
[
https://issues.apache.org/jira/browse/MRESOLVER-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739017#comment-17739017
]
wei cai commented on MRESOLVER-379:
---
[~cstamas]
Do you mean the verbose mode? If not in verbose mode, tree should just print
out the winner
> Problem when relocations and ranges are used in collection
> --
>
> Key: MRESOLVER-379
> URL: https://issues.apache.org/jira/browse/MRESOLVER-379
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
>
> Affects both old DF and new BF collectors.
> Example:
> * A1 -> B[1,3]
> * B1 relocated to C1
> * B2 relocated to C2
> * B3 relocated to C3
> In this example, as output of collection dirty tree I'd expect:
> {noformat}
> A1
> + - C1
> + - C2
> + - C3
> {noformat}
> But none of the DF or BF produce this, moreover, they produce DIFFERENT
> outputs:
> DF does this:
> {noformat}
> A1
> + - C1
> {noformat}
> BF does this:
> {noformat}
> A1
> + - C3
> {noformat}
> Cause is probably as BF "reverse sort" versions, but none will return proper
> range.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-377) Introduce metadata update policy
[ https://issues.apache.org/jira/browse/MRESOLVER-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739015#comment-17739015 ] ASF GitHub Bot commented on MRESOLVER-377: -- cstamas commented on PR #308: URL: https://github.com/apache/maven-resolver/pull/308#issuecomment-1614438371 Really does not matter, as if you do updatePolicy == metadataUpdatePolicy, you are back to "old behaviour", like this PR did not exist even. But agree, it could go to 1.10 as well... > Introduce metadata update policy > > > Key: MRESOLVER-377 > URL: https://issues.apache.org/jira/browse/MRESOLVER-377 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.14 > > > Basically double the update policy, from RemoteRepository all way where > needed, and make Resolver support separate "data" updatePolicy and "metadata" > updatePolicy. > Maven does not have to make use of this (setting updatePolicy == > metadataUpdatePolicy results in functionality like today, where there is only > one policy). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739014#comment-17739014
]
ASF GitHub Bot commented on MRESOLVER-376:
--
cstamas commented on PR #311:
URL: https://github.com/apache/maven-resolver/pull/311#issuecomment-1614435562
Created bug to examing range+redirect case
https://issues.apache.org/jira/browse/MRESOLVER-379
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on pull request #311: [MRESOLVER-376] Alt fix
cstamas commented on PR #311: URL: https://github.com/apache/maven-resolver/pull/311#issuecomment-1614435562 Created bug to examing range+redirect case https://issues.apache.org/jira/browse/MRESOLVER-379 -- 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-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739012#comment-17739012
]
ASF GitHub Bot commented on MRESOLVER-376:
--
cstamas commented on PR #312:
URL: https://github.com/apache/maven-resolver/pull/312#issuecomment-1614435013
Created bug to examing range+redirect case
https://issues.apache.org/jira/browse/MRESOLVER-379
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739013#comment-17739013
]
ASF GitHub Bot commented on MRESOLVER-376:
--
cstamas commented on PR #309:
URL: https://github.com/apache/maven-resolver/pull/309#issuecomment-1614435311
Created bug to examing range+redirect case
https://issues.apache.org/jira/browse/MRESOLVER-379
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-379) Problem when relocations and ranges are used in collection
[
https://issues.apache.org/jira/browse/MRESOLVER-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-379:
--
Description:
Affects both old DF and new BF collectors.
Example:
* A1 -> B[1,3]
* B1 relocated to C1
* B2 relocated to C2
* B3 relocated to C3
In this example, as output of collection dirty tree I'd expect:
{noformat}
A1
+ - C1
+ - C2
+ - C3
{noformat}
But none of the DF or BF produce this, moreover, they produce DIFFERENT outputs:
DF does this:
{noformat}
A1
+ - C1
{noformat}
BF does this:
{noformat}
A1
+ - C3
{noformat}
Cause is probably as BF "reverse sort" versions, but none will return proper
range.
was:
Affects both old DF and new BF collectors.
Example:
* A1 -> B[1,3]
* B1 -relocated-> C1
* B2 -relocated-> C2
* B3 -relocated-> C3
In this example, as output of collection dirty tree I'd expect:
{noformat}
A1
+ - C1
+ - C2
+ - C3
{noformat}
But none of the DF or BF produce this, moreover, they produce DIFFERENT outputs:
DF does this:
{noformat}
A1
+ - C1
{noformat}
BF does this:
{noformat}
A1
+ - C3
{noformat}
Cause is probably as BF "reverse sort" versions, but none will return proper
range.
> Problem when relocations and ranges are used in collection
> --
>
> Key: MRESOLVER-379
> URL: https://issues.apache.org/jira/browse/MRESOLVER-379
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
>
> Affects both old DF and new BF collectors.
> Example:
> * A1 -> B[1,3]
> * B1 relocated to C1
> * B2 relocated to C2
> * B3 relocated to C3
> In this example, as output of collection dirty tree I'd expect:
> {noformat}
> A1
> + - C1
> + - C2
> + - C3
> {noformat}
> But none of the DF or BF produce this, moreover, they produce DIFFERENT
> outputs:
> DF does this:
> {noformat}
> A1
> + - C1
> {noformat}
> BF does this:
> {noformat}
> A1
> + - C3
> {noformat}
> Cause is probably as BF "reverse sort" versions, but none will return proper
> range.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOLVER-379) Problem when relocations and ranges are used in collection
Tamas Cservenak created MRESOLVER-379:
-
Summary: Problem when relocations and ranges are used in collection
Key: MRESOLVER-379
URL: https://issues.apache.org/jira/browse/MRESOLVER-379
Project: Maven Resolver
Issue Type: Bug
Components: Resolver
Reporter: Tamas Cservenak
Affects both old DF and new BF collectors.
Example:
* A1 -> B[1,3]
* B1 -relocated-> C1
* B2 -relocated-> C2
* B3 -relocated-> C3
In this example, as output of collection dirty tree I'd expect:
{noformat}
A1
+ - C1
+ - C2
+ - C3
{noformat}
But none of the DF or BF produce this, moreover, they produce DIFFERENT outputs:
DF does this:
{noformat}
A1
+ - C1
{noformat}
BF does this:
{noformat}
A1
+ - C3
{noformat}
Cause is probably as BF "reverse sort" versions, but none will return proper
range.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739011#comment-17739011
]
ASF GitHub Bot commented on MRESOLVER-376:
--
cstamas closed pull request #309: [MRESOLVER-376] Bugfix for relocated artifacts
URL: https://github.com/apache/maven-resolver/pull/309
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739010#comment-17739010
]
ASF GitHub Bot commented on MRESOLVER-376:
--
cstamas commented on PR #309:
URL: https://github.com/apache/maven-resolver/pull/309#issuecomment-1614428957
Superseded by #311
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] cstamas closed pull request #309: [MRESOLVER-376] Bugfix for relocated artifacts
cstamas closed pull request #309: [MRESOLVER-376] Bugfix for relocated artifacts URL: https://github.com/apache/maven-resolver/pull/309 -- 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-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739004#comment-17739004
]
ASF GitHub Bot commented on MRESOLVER-376:
--
cstamas commented on PR #312:
URL: https://github.com/apache/maven-resolver/pull/312#issuecomment-1614417987
Here is UT failure (same stack trace as in issue):
```
[INFO] Running
org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollectorTest
Error: Tests run: 42, Failures: 0, Errors: 2, Skipped: 1, Time elapsed:
0.346 s <<< FAILURE! - in
org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollectorTest
Error:
org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollectorTest.testTransitiveDepsUseRangesAndRelocationDirtyTree[0]
Time elapsed: 0.023 s <<< ERROR!
java.lang.StackOverflowError
at java.base/java.lang.StringBuilder.(StringBuilder.java:119)
at
org.eclipse.aether.util.artifact.ArtifactIdUtils.concat(ArtifactIdUtils.java:123)
at
org.eclipse.aether.util.artifact.ArtifactIdUtils.toId(ArtifactIdUtils.java:66)
at
org.eclipse.aether.util.artifact.ArtifactIdUtils.toId(ArtifactIdUtils.java:45)
at
org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollector$ParallelDescriptorResolver.find(BfDependencyCollector.java:500)
at
org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollector.processDependency(BfDependencyCollector.java:215)
at
org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollector.processDependency(BfDependencyCollector.java:271)
at
org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollector.processDependency(BfDependencyCollector.java:271)
at
org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollector.processDependency(BfDependencyCollector.java:271)
at
org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollector.processDependency(BfDependencyCollector.java:271)
at
org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollector.processDependency(BfDependencyCollector.java:271)
```
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on pull request #312: [MRESOLVER-376] UT for bug
cstamas commented on PR #312: URL: https://github.com/apache/maven-resolver/pull/312#issuecomment-1614417987 Here is UT failure (same stack trace as in issue): ``` [INFO] Running org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollectorTest Error: Tests run: 42, Failures: 0, Errors: 2, Skipped: 1, Time elapsed: 0.346 s <<< FAILURE! - in org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollectorTest Error: org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollectorTest.testTransitiveDepsUseRangesAndRelocationDirtyTree[0] Time elapsed: 0.023 s <<< ERROR! java.lang.StackOverflowError at java.base/java.lang.StringBuilder.(StringBuilder.java:119) at org.eclipse.aether.util.artifact.ArtifactIdUtils.concat(ArtifactIdUtils.java:123) at org.eclipse.aether.util.artifact.ArtifactIdUtils.toId(ArtifactIdUtils.java:66) at org.eclipse.aether.util.artifact.ArtifactIdUtils.toId(ArtifactIdUtils.java:45) at org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollector$ParallelDescriptorResolver.find(BfDependencyCollector.java:500) at org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollector.processDependency(BfDependencyCollector.java:215) at org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollector.processDependency(BfDependencyCollector.java:271) at org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollector.processDependency(BfDependencyCollector.java:271) at org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollector.processDependency(BfDependencyCollector.java:271) at org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollector.processDependency(BfDependencyCollector.java:271) at org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollector.processDependency(BfDependencyCollector.java:271) ``` -- 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-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739001#comment-17739001
]
ASF GitHub Bot commented on MRESOLVER-376:
--
cstamas opened a new pull request, #312:
URL: https://github.com/apache/maven-resolver/pull/312
This UT on master makes old DF work, while BF break with SOEx.
If same UT ran on fixed branch, both pass.
Still, seems combo of range+relocation has some other issues as well, as all
this works only partially, as the range is not resolved, only first applicant
(lowest version in DF and highest version in BF as it sort-reverse the
versions).
---
https://issues.apache.org/jira/browse/MRESOLVER-376
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739002#comment-17739002
]
ASF GitHub Bot commented on MRESOLVER-376:
--
cstamas commented on PR #312:
URL: https://github.com/apache/maven-resolver/pull/312#issuecomment-1614415246
@caiwei-ebay ping
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17739000#comment-17739000
]
ASF GitHub Bot commented on MRESOLVER-376:
--
caiwei-ebay2 commented on PR #309:
URL: https://github.com/apache/maven-resolver/pull/309#issuecomment-1614413759
@cstamas
With the details you shared and combined with debugging, I fully understand
the case. This case is happened with version range + relocation, this is why I
cannot reproduce the issue with a relocation artifact like
`
mysql
mysql-connector-java
8.0.33
`
Both fixes are good. And I prefder the fix in 311, I have tried that and it
worked like a charm.
https://github.com/apache/maven-resolver/pull/311
Thanks again for your quick triaging and fix!
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on pull request #312: [MRESOLVER-376] UT for bug
cstamas commented on PR #312: URL: https://github.com/apache/maven-resolver/pull/312#issuecomment-1614415246 @caiwei-ebay ping -- 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-378) Update parent POM to 40
[ https://issues.apache.org/jira/browse/MRESOLVER-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738976#comment-17738976 ] ASF GitHub Bot commented on MRESOLVER-378: -- slawekjaranowski commented on PR #310: URL: https://github.com/apache/maven-resolver/pull/310#issuecomment-1614372326 We can remove version for install/deploy plugin > Update parent POM to 40 > --- > > Key: MRESOLVER-378 > URL: https://issues.apache.org/jira/browse/MRESOLVER-378 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.14 > > > To get all the latest plugins. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738969#comment-17738969
]
ASF GitHub Bot commented on MRESOLVER-376:
--
cstamas commented on PR #311:
URL: https://github.com/apache/maven-resolver/pull/311#issuecomment-1614358855
Btw: here is a simple reproducer
https://gist.github.com/cstamas/cce5cfd94f6fa24a40c9239ca7040230
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738968#comment-17738968
]
Tamas Cservenak commented on MRESOLVER-376:
---
Here is a simple reproducer:
https://gist.github.com/cstamas/cce5cfd94f6fa24a40c9239ca7040230
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on pull request #311: [MRESOLVER-376] Alt fix
cstamas commented on PR #311: URL: https://github.com/apache/maven-resolver/pull/311#issuecomment-1614358855 Btw: here is a simple reproducer https://gist.github.com/cstamas/cce5cfd94f6fa24a40c9239ca7040230 -- 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-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738965#comment-17738965
]
ASF GitHub Bot commented on MRESOLVER-376:
--
cstamas commented on PR #309:
URL: https://github.com/apache/maven-resolver/pull/309#issuecomment-1614346729
I think this PR is to be superseded by this "proper fix":
https://github.com/apache/maven-resolver/pull/311
@snjeza @caiwei-ebay2
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738964#comment-17738964
]
ASF GitHub Bot commented on MRESOLVER-376:
--
cstamas opened a new pull request, #311:
URL: https://github.com/apache/maven-resolver/pull/311
Solve the mixup of Artifact used as key, as in case of relocation A1 -> A2,
when A1 descriptor is read, the result will have A2 artifact set.
So, in code, we must go for "originally asked" A1 artifact, as in case of
relocation, the descriptor will hold A1 relocation target, that is A2, causing
endless loop.
---
https://issues.apache.org/jira/browse/MRESOLVER-376
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (SUREFIRE-2178) classpathDependencyExcludes should support classifiers
[
https://issues.apache.org/jira/browse/SUREFIRE-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed SUREFIRE-2178.
-
> classpathDependencyExcludes should support classifiers
> --
>
> Key: SUREFIRE-2178
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2178
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.2.0
>
>
> Currently each item for parameter {{classpathDependencyExcludes}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#classpathDependencyExcludes)
> only supports the format
> {code}:{code}
> That makes it impossible to exclude dependencies having a classifier.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2178) classpathDependencyExcludes should support classifiers
[
https://issues.apache.org/jira/browse/SUREFIRE-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated SUREFIRE-2178:
--
Fix Version/s: 3.2.0
(was: 3.x-candidate)
> classpathDependencyExcludes should support classifiers
> --
>
> Key: SUREFIRE-2178
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2178
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.2.0
>
>
> Currently each item for parameter {{classpathDependencyExcludes}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#classpathDependencyExcludes)
> only supports the format
> {code}:{code}
> That makes it impossible to exclude dependencies having a classifier.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2182) Log starter implementation on DEBUG level
[ https://issues.apache.org/jira/browse/SUREFIRE-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated SUREFIRE-2182: -- Fix Version/s: 3.2.0 (was: 3.x-candidate) > Log starter implementation on DEBUG level > - > > Key: SUREFIRE-2182 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2182 > Project: Maven Surefire > Issue Type: Improvement >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.2.0 > > > In order to ease debugging classpath issues the fork configuration determined > by > [AbstractSurefireMojo.createForkConfiguration(...)|https://github.com/apache/maven-surefire/blob/0998f10bb486f79f40d2d4262798b1f53a5ff286/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L2216] > should be logged with debug level for when using the fork starter. Similarly > a DEBUG log entry should be emitted when the in-process starter is being used. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SUREFIRE-2179) additionalClasspathElements should support Maven coordinates
[
https://issues.apache.org/jira/browse/SUREFIRE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed SUREFIRE-2179.
-
> additionalClasspathElements should support Maven coordinates
>
>
> Key: SUREFIRE-2179
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2179
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.2.0
>
>
> Currently the parameter {{additionalClasspathElements}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#additionalclasspathelements)
> only supports file paths. That usually requires to add an additional step to
> first download the necessary artifact to a temporary folder with another
> Mojo. In addition {{additionalClasspathElements}} only support full paths to
> JARs but no wildcards which makes configuration very verbose.
> For these reasons there should be an additional parameter supporting Maven
> coordinates which are then resolved automatically (even transitively) and
> added to the test execution classpath.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2179) additionalClasspathElements should support Maven coordinates
[
https://issues.apache.org/jira/browse/SUREFIRE-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated SUREFIRE-2179:
--
Fix Version/s: 3.2.0
(was: 3.x-candidate)
> additionalClasspathElements should support Maven coordinates
>
>
> Key: SUREFIRE-2179
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2179
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading
>Affects Versions: 3.1.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.2.0
>
>
> Currently the parameter {{additionalClasspathElements}}
> (https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#additionalclasspathelements)
> only supports file paths. That usually requires to add an additional step to
> first download the necessary artifact to a temporary folder with another
> Mojo. In addition {{additionalClasspathElements}} only support full paths to
> JARs but no wildcards which makes configuration very verbose.
> For these reasons there should be an additional parameter supporting Maven
> coordinates which are then resolved automatically (even transitively) and
> added to the test execution classpath.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738961#comment-17738961
]
ASF GitHub Bot commented on MRESOLVER-376:
--
cstamas commented on PR #309:
URL: https://github.com/apache/maven-resolver/pull/309#issuecomment-1614328597
The more i think, I believe this PR
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on pull request #309: [MRESOLVER-376] Bugfix for relocated artifacts
cstamas commented on PR #309: URL: https://github.com/apache/maven-resolver/pull/309#issuecomment-1614327105 So, IMHO the problem is somewhere around here: https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.13/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L425 You do `args.resolver.cacheVersionRangeDescriptor(dr.artifact, dr))` BUT: * `dr` is A1 descriptor * `dr.artifact` is A2 (RelocatedArtifact) -- 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-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738960#comment-17738960
]
ASF GitHub Bot commented on MRESOLVER-376:
--
cstamas commented on PR #309:
URL: https://github.com/apache/maven-resolver/pull/309#issuecomment-1614327105
So, IMHO the problem is somewhere around here:
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.13/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L425
You do `args.resolver.cacheVersionRangeDescriptor(dr.artifact, dr))` BUT:
* `dr` is A1 descriptor
* `dr.artifact` is A2 (RelocatedArtifact)
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-mvnd] Bismarcharis opened a new issue, #863: mvnd is incompatible with revision，versions-maven-plugin is 2.7
Bismarcharis opened a new issue, #863:
URL: https://github.com/apache/maven-mvnd/issues/863
Hello
I am using versions-maven-plugin 2.7 to use the revision function，but i am
executing mvnd compile, the following error occoured
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for com.kuaikan.comic:comic:${revision}:
The following artifacts could not be resolved:
com.kuaikan:kk-rootpom:pom:1.0.6.BOOT.RELEASE (present, but unavailable):
com.kuaikan:kk-rootpom:pom:1.0.6.BOOT.RELEASE was not found in
https://repo.maven.apache.org/maven2 during a previous attempt. This failure
was cached in the local repository and resolution is not reattempted until the
update interval of central has elapsed or updates are forced and
'parent.relativePath' points at wrong local POM @ line 7, column 13
@
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738949#comment-17738949
]
ASF GitHub Bot commented on MRESOLVER-376:
--
cstamas commented on PR #309:
URL: https://github.com/apache/maven-resolver/pull/309#issuecomment-1614311710
What patch actually does:
* introduces `replace` boolean flag, that is `false` always,
* EXCEPT when it is about relocation, as then it assumes
* that A1 descriptor is cached under A2 key
* so when it goes to get "real" A2 descriptor, it simply "forces" and
replaces it
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738948#comment-17738948
]
ASF GitHub Bot commented on MRESOLVER-376:
--
cstamas commented on PR #309:
URL: https://github.com/apache/maven-resolver/pull/309#issuecomment-1614309073
Yes, please reproduce, it is really consistent (in JIRA there is a commit
hash to use, if they changed anything in git)
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on pull request #309: [MRESOLVER-376] Bugfix for relocated artifacts
cstamas commented on PR #309: URL: https://github.com/apache/maven-resolver/pull/309#issuecomment-1614309073 Yes, please reproduce, it is really consistent (in JIRA there is a commit hash to use, if they changed anything in git) -- 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-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738946#comment-17738946
]
ASF GitHub Bot commented on MRESOLVER-376:
--
cstamas commented on PR #309:
URL: https://github.com/apache/maven-resolver/pull/309#issuecomment-1614307240
> From my original implementation, it is like this: A1 will be relocates to
A2, so first we resolve A1, we cache A2's descriptor with A2's key, next
resolve A2, A2 is already there.
So problem is:
* "we first resolve A1" -> but DescriptorReader will return A2 as
descriptor.artifact (RelocatedArtifact implementation)
* you stuff this into a map (and use key descriptor.artifact, that is A2)
* "next resolver A2" -> and you get A1 descriptor (that relocates to A2...
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-376) StackOverflowError at BfDependencyCollector.processDependency
[
https://issues.apache.org/jira/browse/MRESOLVER-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738943#comment-17738943
]
ASF GitHub Bot commented on MRESOLVER-376:
--
cstamas commented on PR #309:
URL: https://github.com/apache/maven-resolver/pull/309#issuecomment-1614300205
Things to be aware:
* RelocatedArtifact (implemented in Maven)
https://github.com/apache/maven/blob/maven-3.9.x/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RelocatedArtifact.java
* ArtifactDescriptorReader (also implemented in Maven):
https://github.com/apache/maven/blob/maven-3.9.x/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java#L299-L308
* async resolver has a Map that uses
computeIfAbsent, hence if key once added, will not be re-added during resolution
Steps happening:
* BF asks for `junit:junit-dep:4.11` descriptor async resolution
* descriptor reader returns `ArtifactDescriptorResult` that carries
`RelocatedArtifact` as d.artifact (that contains GAVs for relocation target
`junit:junit:4.11`) while descriptor contains `junit:junit-dep:4.11` data, so
even redirects are there
* this descriptor is being put into map (computeIfAbsent) as
`junit:junit:4.11` -> `ArtifactDescriptorResult` (that of `junit:junit-dep:4.11`
* next, relocation target `junit:junit:4.11` descriptor is asked, but the
entry above is returned (that is actually descriptor of `junit;junit-dep:4.11`
that AGAIN contains relocation
* and so on, relocation target is being asked for over and over again, but
the resolver map returns relocated artifact descriptor over and over again, so
"constant relocation loop happens".
@caiwei-ebay2 yes, very simple to reproduce, and this above is what I saw
during debug (and locally added some logging). Problem is that
`RelocatedArtifact` is completely opaque in resolver (as it is implemented in
maven-resolver-provider), as IMHO simplest would be something like this (but
there is no such method either):
```
Artifact key = artifactDescriptor.artifact
if (key instance of RelocatedArtifact) {
key = ((RelocatedArtifact) key).getOriginalArtifact();
}
```
Ultimately, problem is this "mixup" that in the map, the relocated artifact
descriptor is stored under relocation target key, and here a loop starts, as
relocation target mapping will again return relocated artifact descriptor.
> StackOverflowError at BfDependencyCollector.processDependency
> -
>
> Key: MRESOLVER-376
> URL: https://issues.apache.org/jira/browse/MRESOLVER-376
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Snjezana Peco
>Priority: Major
> Fix For: 1.9.14
>
>
> Steps to reproduce:
> {code:java}
> $ mvn -v
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f))
> $ git clone g...@github.com:snowflakedb/snowflake-kafka-connector.git
> $ cd snowflake-kafka-connector
> $ mvn clean verify -Daether.dependencyCollector.impl=bf {code}
>
> A related issue -
> [https://github.com/redhat-developer/vscode-java/issues/3085]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on pull request #309: [MRESOLVER-376] Bugfix for relocated artifacts
cstamas commented on PR #309:
URL: https://github.com/apache/maven-resolver/pull/309#issuecomment-1614300205
Things to be aware:
* RelocatedArtifact (implemented in Maven)
https://github.com/apache/maven/blob/maven-3.9.x/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RelocatedArtifact.java
* ArtifactDescriptorReader (also implemented in Maven):
https://github.com/apache/maven/blob/maven-3.9.x/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultArtifactDescriptorReader.java#L299-L308
* async resolver has a Map that uses
computeIfAbsent, hence if key once added, will not be re-added during resolution
Steps happening:
* BF asks for `junit:junit-dep:4.11` descriptor async resolution
* descriptor reader returns `ArtifactDescriptorResult` that carries
`RelocatedArtifact` as d.artifact (that contains GAVs for relocation target
`junit:junit:4.11`) while descriptor contains `junit:junit-dep:4.11` data, so
even redirects are there
* this descriptor is being put into map (computeIfAbsent) as
`junit:junit:4.11` -> `ArtifactDescriptorResult` (that of `junit:junit-dep:4.11`
* next, relocation target `junit:junit:4.11` descriptor is asked, but the
entry above is returned (that is actually descriptor of `junit;junit-dep:4.11`
that AGAIN contains relocation
* and so on, relocation target is being asked for over and over again, but
the resolver map returns relocated artifact descriptor over and over again, so
"constant relocation loop happens".
@caiwei-ebay2 yes, very simple to reproduce, and this above is what I saw
during debug (and locally added some logging). Problem is that
`RelocatedArtifact` is completely opaque in resolver (as it is implemented in
maven-resolver-provider), as IMHO simplest would be something like this (but
there is no such method either):
```
Artifact key = artifactDescriptor.artifact
if (key instance of RelocatedArtifact) {
key = ((RelocatedArtifact) key).getOriginalArtifact();
}
```
Ultimately, problem is this "mixup" that in the map, the relocated artifact
descriptor is stored under relocation target key, and here a loop starts, as
relocation target mapping will again return relocated artifact descriptor.
--
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-377) Introduce metadata update policy
[ https://issues.apache.org/jira/browse/MRESOLVER-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17738931#comment-17738931 ] ASF GitHub Bot commented on MRESOLVER-377: -- gnodet commented on PR #308: URL: https://github.com/apache/maven-resolver/pull/308#issuecomment-1614270769 Shouldn't that be targeted for 1.10 ? > Introduce metadata update policy > > > Key: MRESOLVER-377 > URL: https://issues.apache.org/jira/browse/MRESOLVER-377 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.9.14 > > > Basically double the update policy, from RemoteRepository all way where > needed, and make Resolver support separate "data" updatePolicy and "metadata" > updatePolicy. > Maven does not have to make use of this (setting updatePolicy == > metadataUpdatePolicy results in functionality like today, where there is only > one policy). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] gnodet commented on pull request #308: [MRESOLVER-377] Introduce metadataUpdatePolicy
gnodet commented on PR #308: URL: https://github.com/apache/maven-resolver/pull/308#issuecomment-1614270769 Shouldn't that be targeted for 1.10 ? -- 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
