[jira] [Commented] (MRELEASE-1103) decryption of server password in settings.xml failed (works with 2.5.3)
[ https://issues.apache.org/jira/browse/MRELEASE-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605656#comment-17605656 ] Robert Seidel commented on MRELEASE-1103: - Problematic commit is this one [https://github.com/apache/maven-release/commit/dafdd7f49d4f96f4d3c9e9b525d6150c40b4784b] it has removed the calculation of the correct settings file here maven-release-manager/src/main/java/org/apache/maven/shared/release/exec/AbstractMavenExecutor.java so it uses the wrong default from plexus... > decryption of server password in settings.xml failed (works with 2.5.3) > --- > > Key: MRELEASE-1103 > URL: https://issues.apache.org/jira/browse/MRELEASE-1103 > Project: Maven Release Plugin > Issue Type: Bug >Affects Versions: 3.0.0-M6 >Reporter: Robert Seidel >Priority: Major > > A server section was defined in the settings.xml at > with id, username and password to connect to a > Bitbucket server. > In the pom.xml the id was referenced in the properties via project.scm.id. > With 2.5.3 the build is running fine, but with 3.0.06-M6 the following > happens: > *11:35:40* [INFO] [WARNING] The requested profile "distribute" could not be > activated because it does not exist. > *11:35:40* [INFO] 11/17 prepare:scm-commit-release > *11:35:40* [INFO] Checking in modified POMs... > *11:35:40* [WARNING] Failed to decrypt password/passphrase for server > bitbucket-prod, using auth token as is: decrypt failed > and in the aftermath: > *11:35:41* [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-release-plugin:3.0.0-M6:prepare (default-cli) > on project ExamplePom: Unable to commit files > *11:35:41* [ERROR] Provider message: > *11:35:41* [ERROR] The git-push command failed. > *11:35:41* [ERROR] Command output: > *11:35:41* [ERROR] fatal: Authentication failed for > '[https://prod.bitbucket/scm/cp/examplepom.git/|https://git.aeb.com/bitbucket/scm/cp/aebparentpom.git/]' > > JDK used was Adoptium 17 (but with 11 the same problem occured). > Maven used was 3.8.6. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MASSEMBLY-941) file permissions removed during assembly:single since 3.2.0
[ https://issues.apache.org/jira/browse/MASSEMBLY-941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17509731#comment-17509731 ] Piotr Zygielo edited comment on MASSEMBLY-941 at 9/16/22 7:08 AM: -- This seems to be documented/caused here: https://github.com/codehaus-plexus/plexus-archiver/blob/a4a6b0771148b90221f9e02c0fff9299d45e8520/src/main/java/org/codehaus/plexus/archiver/AbstractArchiver.java#L1326 was (Author: pzygielo): This seems to be documented/caused here: https://github.com/codehaus-plexus/plexus-archiver/blob/master/src/main/java/org/codehaus/plexus/archiver/AbstractArchiver.java#L1326 > file permissions removed during assembly:single since 3.2.0 > --- > > Key: MASSEMBLY-941 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-941 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 3.2.0, 3.3.0 >Reporter: Christopher Tubbs >Priority: Critical > > Since 3.2.0, existing file permissions seem to be ignored when creating a > tarball assembly, and files stored in the assembly do not have their original > file permissions preserved. > Using version 3.1.1 of this plugin and earlier, when creating a tar.gz, > existing file permissions are normally preserved. This is now broken in > 3.2.0, unless the component descriptor explicitly sets the fileModes. > This was discovered trying to prepare a release candidate for Apache Accumulo > using the apache-23.pom parent POM's predefined `source-release-tar` > descriptor using the `single` goal. We noticed that the resulting > source-release tarball had stripped all the executable permissions from our > scripts, instead of preserving them. This makes the resulting source release > more difficult to build from source. > A source-release assembly, and any other assembly that does not specify the > file permissions explicitly, should preserve the existing file permissions, > just as it used to with 3.1.1 and earlier. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MRELEASE-1103) decryption of server password in settings.xml failed (works with 2.5.3)
[ https://issues.apache.org/jira/browse/MRELEASE-1103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605656#comment-17605656 ] Robert Seidel edited comment on MRELEASE-1103 at 9/16/22 7:11 AM: -- Problematic commit is this one [https://github.com/apache/maven-release/commit/dafdd7f49d4f96f4d3c9e9b525d6150c40b4784b] it has removed the calculation of the correct settings file here maven-release-manager/src/main/java/org/apache/maven/shared/release/exec/AbstractMavenExecutor.java so it uses the wrong default from plexus... (documentation points to other file name and location - https://maven.apache.org/guides/mini/guide-encryption.html which worked before) was (Author: JIRAUSER295788): Problematic commit is this one [https://github.com/apache/maven-release/commit/dafdd7f49d4f96f4d3c9e9b525d6150c40b4784b] it has removed the calculation of the correct settings file here maven-release-manager/src/main/java/org/apache/maven/shared/release/exec/AbstractMavenExecutor.java so it uses the wrong default from plexus... > decryption of server password in settings.xml failed (works with 2.5.3) > --- > > Key: MRELEASE-1103 > URL: https://issues.apache.org/jira/browse/MRELEASE-1103 > Project: Maven Release Plugin > Issue Type: Bug >Affects Versions: 3.0.0-M6 >Reporter: Robert Seidel >Priority: Major > > A server section was defined in the settings.xml at > with id, username and password to connect to a > Bitbucket server. > In the pom.xml the id was referenced in the properties via project.scm.id. > With 2.5.3 the build is running fine, but with 3.0.06-M6 the following > happens: > *11:35:40* [INFO] [WARNING] The requested profile "distribute" could not be > activated because it does not exist. > *11:35:40* [INFO] 11/17 prepare:scm-commit-release > *11:35:40* [INFO] Checking in modified POMs... > *11:35:40* [WARNING] Failed to decrypt password/passphrase for server > bitbucket-prod, using auth token as is: decrypt failed > and in the aftermath: > *11:35:41* [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-release-plugin:3.0.0-M6:prepare (default-cli) > on project ExamplePom: Unable to commit files > *11:35:41* [ERROR] Provider message: > *11:35:41* [ERROR] The git-push command failed. > *11:35:41* [ERROR] Command output: > *11:35:41* [ERROR] fatal: Authentication failed for > '[https://prod.bitbucket/scm/cp/examplepom.git/|https://git.aeb.com/bitbucket/scm/cp/aebparentpom.git/]' > > JDK used was Adoptium 17 (but with 11 the same problem occured). > Maven used was 3.8.6. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7540) Internal error when building project
chris tall created MNG-7540: --- Summary: Internal error when building project Key: MNG-7540 URL: https://issues.apache.org/jira/browse/MNG-7540 Project: Maven Issue Type: Bug Reporter: chris tall Attachments: debug.log I cant understand what is happening when i build check out attached log file -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAVADOC-726) Maven Java Doc Plug-in v3.4.0 downloads Log4j-1.2.12 dependency transitively
[ https://issues.apache.org/jira/browse/MJAVADOC-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605719#comment-17605719 ] Michael Osipov commented on MJAVADOC-726: - I can already hear the drums, rolling out the red carpet... > Maven Java Doc Plug-in v3.4.0 downloads Log4j-1.2.12 dependency transitively > > > Key: MJAVADOC-726 > URL: https://issues.apache.org/jira/browse/MJAVADOC-726 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: jar, javadoc >Affects Versions: 3.4.0 > Environment: Windows 10 >Reporter: Yogesh Desai >Priority: Major > Labels: Vulnerability, vulnerability > Fix For: wontfix-candidate, waiting-for-feedback > > Attachments: log4j-1.2.12.png > > > I have observed that Maven Javadoc Plug-in v3.4.0 downloads Log4j-1.2.12 > dependency transitively in local maven repository i.e. .m2 folder upon > running maven update in eclipse IDE or from command line. Since Log4j-1.X is > strictly prohibited for use in many organisations, we had no other option > that not using the plugin. Please plan to fix this issue and get rid of the > log4j-1.X dependency. > *Steps to Reproduce-* > 1. Add maven javadoc plugin v3.4.0 in your project POM file > > org.apache.maven.plugins > maven-javadoc-plugin > 3.4.0 > > UTF-8 > -Xdoclint:none > > > > attach-javadocs > > jar > > > > > 2. Observe your local maven repository ie. .m2 folder and see if there are > any log4j-1.2.12 artifacts are present in log4j folder of it. If artifacts > are present already, delete them for now. > 3. Run maven update command for your project (additionally run maven install > command as needed) > 4. Observe your local maven repository ie. .m2 folder and see if there are > any log4j-1.2.12 artifacts are generated with latest timestamp inside log4j > folder. > Attached is the screenshot showing, maven javadoc plugin v3.4.0 used in > POM.xml and log4j-1.2.12 dependency getting downloaded in local maven > repository i.e. .m2 folder. > Let me know if any other information is required. Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-dependency-plugin] michael-o commented on pull request #246: [MDEP-826] Upgrade maven-reporting-imp from 3.1.0 to 3.2.0
michael-o commented on PR #246: URL: https://github.com/apache/maven-dependency-plugin/pull/246#issuecomment-1249119447 Looking into now... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-plugin] michael-o commented on pull request #246: [MDEP-826] Upgrade maven-reporting-imp from 3.1.0 to 3.2.0
michael-o commented on PR #246: URL: https://github.com/apache/maven-dependency-plugin/pull/246#issuecomment-1249147116 @slawekjaranowski Added a followup commit. Please have a look. Reasoning is in the commit message. -- 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-dependency-plugin] slawekjaranowski commented on pull request #246: [MDEP-826] Upgrade maven-reporting-imp from 3.1.0 to 3.2.0
slawekjaranowski commented on PR #246: URL: https://github.com/apache/maven-dependency-plugin/pull/246#issuecomment-1249170304 When we don't override `outputDirectory` - report will be placed in `target/site` Now when we are calling report from cli output is stored in `target` - as you see in IT test Maybe such change should be done in separate issue, in order to show changing behavior in release notes -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MNG-7540) Internal error when building project
[ https://issues.apache.org/jira/browse/MNG-7540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-7540. --- Resolution: Information Provided # The syntax of the file URL is wrong # The Tycho plugin/components is not maintained by us, but by the Eclipse project I see no issue with Maven. > Internal error when building project > > > Key: MNG-7540 > URL: https://issues.apache.org/jira/browse/MNG-7540 > Project: Maven > Issue Type: Bug >Reporter: chris tall >Priority: Major > Attachments: debug.log > > > I cant understand what is happening when i build > check out attached log file -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-dependency-plugin] michael-o commented on pull request #246: [MDEP-826] Upgrade maven-reporting-imp from 3.1.0 to 3.2.0
michael-o commented on PR #246: URL: https://github.com/apache/maven-dependency-plugin/pull/246#issuecomment-1249189543 > When we don't override `outputDirectory` - report will be placed in `target/site` Now when we are calling report from cli output is stored in `target` - as you see in IT test > > Maybe such change should be done in separate issue, in order to show changing behavior in release notes I understand your reasoning, but if you look at other reporting plugins the standalone behavior is identical. I agree, let's make it a followup issue. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-pmd-plugin] dependabot[bot] opened a new pull request, #95: Bump maven-common-artifact-filters from 3.3.1 to 3.3.2
dependabot[bot] opened a new pull request, #95: URL: https://github.com/apache/maven-pmd-plugin/pull/95 Bumps [maven-common-artifact-filters](https://github.com/apache/maven-common-artifact-filters) from 3.3.1 to 3.3.2. Commits https://github.com/apache/maven-common-artifact-filters/commit/31e20e5c0a2226285dc6b90fc5b3eaaf5f642d8a";>31e20e5 [maven-release-plugin] prepare release maven-common-artifact-filters-3.3.2 https://github.com/apache/maven-common-artifact-filters/commit/7660d9bc1429ffbe4c86cdaf7af5776d118883cf";>7660d9b [MSHARED-1131] Upgrade Parent to 37 and cleanup https://github.com/apache/maven-common-artifact-filters/commit/bde012cf6f793adf6d135e0356694dc1fef2c7f9";>bde012c (doc) small code cleanup from ide suggestions https://github.com/apache/maven-common-artifact-filters/commit/500569dad88b8f91e77116a2743a4685c920bed5";>500569d [MSHARED-1130] Sanitised value nullability in match(Pattern, boolean, String) https://github.com/apache/maven-common-artifact-filters/commit/299cf441a2e6eede21b0f1657c86f292ab4885b0";>299cf44 Use GH shared v3 https://github.com/apache/maven-common-artifact-filters/commit/37ea472bf2950d12a9176c91a9a79543f748846b";>37ea472 [maven-release-plugin] prepare for next development iteration See full diff in https://github.com/apache/maven-common-artifact-filters/compare/maven-common-artifact-filters-3.3.1...maven-common-artifact-filters-3.3.2";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7539) Validate/Download SNAPSHOT dependencies once
[
https://issues.apache.org/jira/browse/MNG-7539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605780#comment-17605780
]
Adrian Tarau commented on MNG-7539:
---
We tried that, but it does not work. Right now, the update for SNAPSHOT is
{*}always{*}. The reason why it will not work is the following:
* let's say we change the policy *every 15 minutes*
* project A builds, uploads new SNAPSHOT artifacts
* project B builds (and it depends on A, and it did run {*}11 minutes ago{*}),
and the timeout is not reached, it sees the previous version of the artifact,
and the build fails
Finding the correct update policy is tricky, and depending on the build speed,
it introduces flaky behaviors.
I thought of writing an extension to download SNAPSHOTS once, but I feel it
should be built in. We have the following policies:
* always - always check when Maven is started for newer versions of snapshots
* never - never check for newer remote versions. Once off manual updates can
be performed.
* daily (default) - check on the first run of the day (local time)
* interval:XXX - check every XXX minutes
A new option can be added "once - check once per build"
> Validate/Download SNAPSHOT dependencies once
>
>
> Key: MNG-7539
> URL: https://issues.apache.org/jira/browse/MNG-7539
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Adrian Tarau
>Priority: Critical
>
> Building an unreleased multi-module project (30-40 modules) that depends on
> various other unreleased modules puts significant pressure on the Maven
> Repository (a local Nexus instance), and artifact resolution could slow down
> the build 2x-3x.
> I do acknowledge that it is the job of the repository to cache and serve
> those responses fast, and for some reason, sometimes it slows down without an
> apparent reason.
> However, the whole build process will be faster if Maven validates a SNAPSHOT
> once for multi-module (when the dependency is reached the first time) and
> then use that version. Even if Maven Repository is relative fast, there is
> still network traffic done. Outside the fact that it should not be done, it
> might also introduce flaky behaviors:
> * one module downloads a version of artifact A, works with it, and
> everything is fine
> * 10 minutes later, another module needs artifact A and gets a newer
> version, which has some issues, and various (test) failures will be raised
> For consistency, on a multi-module build, all modules should _see_ the same
> version of a SNAPSHOT artifact. It will be faster, and it will be consistent
> (which is very important).
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7539) Validate/Download SNAPSHOT dependencies once
[ https://issues.apache.org/jira/browse/MNG-7539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605783#comment-17605783 ] Adrian Tarau commented on MNG-7539: --- Using *daily* or *interval:XX* works fine if your project depends (temporarily) on some open source project ... your build will get a new copy once in a while...but in-house projects which depend on each other and are triggered one after each other by the build pipeline, need to see the latest version of a dependency to avoid failures. The dependency needs to be validated, but only once per build cycle. > Validate/Download SNAPSHOT dependencies once > > > Key: MNG-7539 > URL: https://issues.apache.org/jira/browse/MNG-7539 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Reporter: Adrian Tarau >Priority: Critical > > Building an unreleased multi-module project (30-40 modules) that depends on > various other unreleased modules puts significant pressure on the Maven > Repository (a local Nexus instance), and artifact resolution could slow down > the build 2x-3x. > I do acknowledge that it is the job of the repository to cache and serve > those responses fast, and for some reason, sometimes it slows down without an > apparent reason. > However, the whole build process will be faster if Maven validates a SNAPSHOT > once for multi-module (when the dependency is reached the first time) and > then use that version. Even if Maven Repository is relative fast, there is > still network traffic done. Outside the fact that it should not be done, it > might also introduce flaky behaviors: > * one module downloads a version of artifact A, works with it, and > everything is fine > * 10 minutes later, another module needs artifact A and gets a newer > version, which has some issues, and various (test) failures will be raised > For consistency, on a multi-module build, all modules should _see_ the same > version of a SNAPSHOT artifact. It will be faster, and it will be consistent > (which is very important). > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] michael-o commented on pull request #639: [MNG-7310] Using the plexusContainer to prevent loading lifecycle defined by extensions from other submodules.
michael-o commented on PR #639: URL: https://github.com/apache/maven/pull/639#issuecomment-1249276763 @MartinKanters Should I test again after your followups? -- 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-7310) Maven loads extension from another submodule
[
https://issues.apache.org/jira/browse/MNG-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605787#comment-17605787
]
ASF GitHub Bot commented on MNG-7310:
-
michael-o commented on PR #639:
URL: https://github.com/apache/maven/pull/639#issuecomment-1249276763
@MartinKanters Should I test again after your followups?
> Maven loads extension from another submodule
>
>
> Key: MNG-7310
> URL: https://issues.apache.org/jira/browse/MNG-7310
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-1
>Reporter: Martin Kanters
>Priority: Major
> Attachments: demo-plugins.zip
>
>
> With the latest Maven master, I'm not able to build a certain multi module
> project.
> It fails with the following error:
> C:\work\apache\demo>mvn validate
> [INFO] Scanning for projects...
> ...
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project com.example:demo2:0.0.1-SNAPSHOT
> (C:\work\apache\demo\demo2\pom.xml) has 1 error
> [ERROR] 'build.plugins.plugin.version' for
> org.springframework.cloud:spring-cloud-contract-maven-plugin must be a valid
> version but is '${project.version}'. @
> org.apache.maven:maven-core:4.0.0-alpha-1-SNAPSHOT:default-lifecycle-bindings
> The project looks as follows:
> parent
> – demo (module containing plugin "spring-cloud-contract-maven-plugin")
> – demo2 (module)
> "demo2" has no dependency on "demo" and the parent of "demo2" is "parent"..
> Somehow, the plugin from "demo" leaks into "demo2", which I've verified is
> the case during a debug session.
> I'm still unsure of a couple of things:
> - Does it only happen with the "spring-cloud-contract-maven-plugin" plugin?
> - Where does ${project.version} come from? (I've not defined it)
> I've done a bisect and tracked it down to the following commit:
> [[MNG-5577] Convert maven-core to JSR
> 330|https://github.com/apache/maven/commit/9567da2bc889a94f5c3b692b4afb310ddbacd6e5]
> Subject project is attached. Reproduce with the current master of Maven: mvn
> validate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] MartinKanters commented on a diff in pull request #783: [MNG-7098] Keep the project counter intact when resuming a multi-module project.
MartinKanters commented on code in PR #783: URL: https://github.com/apache/maven/pull/783#discussion_r972950966 ## maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java: ## @@ -143,7 +143,11 @@ public void sessionStarted( ExecutionEvent event ) project.getName(), chars( ' ', ( len > 0 ) ? len : 1 ), project.getPackaging() ); } -totalProjects = projects.size(); +final List allProjects = event.getSession().getAllProjects(); Review Comment: Makes sense, but I am not sure what the policy is on that. @michael-o Should I remove it as suggested, what do you think? -- 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-7098) Project counter should be cumulative when using resume
[
https://issues.apache.org/jira/browse/MNG-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605788#comment-17605788
]
ASF GitHub Bot commented on MNG-7098:
-
MartinKanters commented on code in PR #783:
URL: https://github.com/apache/maven/pull/783#discussion_r972950966
##
maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java:
##
@@ -143,7 +143,11 @@ public void sessionStarted( ExecutionEvent event )
project.getName(), chars( ' ', ( len > 0 ) ? len : 1
), project.getPackaging() );
}
-totalProjects = projects.size();
+final List allProjects =
event.getSession().getAllProjects();
Review Comment:
Makes sense, but I am not sure what the policy is on that. @michael-o Should
I remove it as suggested, what do you think?
> Project counter should be cumulative when using resume
> --
>
> Key: MNG-7098
> URL: https://issues.apache.org/jira/browse/MNG-7098
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and Workspace
>Reporter: Robert Scholte
>Priority: Minor
> Fix For: 4.0.x-candidate
>
>
> When doing a resume on a build, the counter now starts again at 1.
> E.g. Suppose a project has 10 modules and the 7th module fails. With a resume
> now you'll see {{[1/4]}}.
> To me it makes more sense to say {{[7/10]}}. You're still as close to the end
> as usual, but this indicates the size of the complete project.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-artifact-transfer] dependabot[bot] opened a new pull request, #76: Bump maven-common-artifact-filters from 3.1.0 to 3.3.2
dependabot[bot] opened a new pull request, #76: URL: https://github.com/apache/maven-artifact-transfer/pull/76 Bumps [maven-common-artifact-filters](https://github.com/apache/maven-common-artifact-filters) from 3.1.0 to 3.3.2. Commits https://github.com/apache/maven-common-artifact-filters/commit/31e20e5c0a2226285dc6b90fc5b3eaaf5f642d8a";>31e20e5 [maven-release-plugin] prepare release maven-common-artifact-filters-3.3.2 https://github.com/apache/maven-common-artifact-filters/commit/7660d9bc1429ffbe4c86cdaf7af5776d118883cf";>7660d9b [MSHARED-1131] Upgrade Parent to 37 and cleanup https://github.com/apache/maven-common-artifact-filters/commit/bde012cf6f793adf6d135e0356694dc1fef2c7f9";>bde012c (doc) small code cleanup from ide suggestions https://github.com/apache/maven-common-artifact-filters/commit/500569dad88b8f91e77116a2743a4685c920bed5";>500569d [MSHARED-1130] Sanitised value nullability in match(Pattern, boolean, String) https://github.com/apache/maven-common-artifact-filters/commit/299cf441a2e6eede21b0f1657c86f292ab4885b0";>299cf44 Use GH shared v3 https://github.com/apache/maven-common-artifact-filters/commit/37ea472bf2950d12a9176c91a9a79543f748846b";>37ea472 [maven-release-plugin] prepare for next development iteration https://github.com/apache/maven-common-artifact-filters/commit/b244fd9e0e7e84ee0e2e3ba3402f5ba654b5becd";>b244fd9 [maven-release-plugin] prepare release maven-common-artifact-filters-3.3.1 https://github.com/apache/maven-common-artifact-filters/commit/611baf61bc8ff8a26bf4af48dcf8ecb53e5c74dc";>611baf6 [MSHARED-1104] Four element pattern may be GATV or GATC (https://github-redirect.dependabot.com/apache/maven-common-artifact-filters/issues/29";>#29) https://github.com/apache/maven-common-artifact-filters/commit/0985a227dcc4de82759797b40b939c4ebb5f6ff5";>0985a22 Fix jenkins url https://github.com/apache/maven-common-artifact-filters/commit/94088c760d6e9b80cf166a5028b2a87b5af43cfa";>94088c7 [maven-release-plugin] prepare for next development iteration Additional commits viewable in https://github.com/apache/maven-common-artifact-filters/compare/maven-common-artifact-filters-3.1.0...maven-common-artifact-filters-3.3.2";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-artifact-transfer] dependabot[bot] commented on pull request #70: Bump maven-common-artifact-filters from 3.1.0 to 3.3.1
dependabot[bot] commented on PR #70: URL: https://github.com/apache/maven-artifact-transfer/pull/70#issuecomment-1249296639 Superseded by #76. -- 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-artifact-transfer] dependabot[bot] closed pull request #70: Bump maven-common-artifact-filters from 3.1.0 to 3.3.1
dependabot[bot] closed pull request #70: Bump maven-common-artifact-filters from 3.1.0 to 3.3.1 URL: https://github.com/apache/maven-artifact-transfer/pull/70 -- 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] cstamas opened a new pull request, #194: [MRESOLVER-273] More compat filesystem friendly mapper
cstamas opened a new pull request, #194: URL: https://github.com/apache/maven-resolver/pull/194 Create more compact FS NameMapper. Also, clean up existing ones and reduce clutter and mess. High level changes: * Introduce StringDigestUtil for String hashing (cleanup the mess of digest/checksum mixup, deprecate and make unused SimpleDigest) * Introduce HashingNameMapper (implements the "more compact" name mapper) * Cleanup and simplify existing NameMapper implementations * Introduce providers for "user facing" configuration names, as those are usually combination of existing NameMappers (like one wrapping other, etc). Hence, to keep things simple, no NameMapper is component anymore but dedicated providers are constructing them. No user facing change happens by this, as mapper names remains same. --- https://issues.apache.org/jira/browse/MRESOLVER-273 -- 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-273) Create more compact File locking layout/mapper
[ https://issues.apache.org/jira/browse/MRESOLVER-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605795#comment-17605795 ] ASF GitHub Bot commented on MRESOLVER-273: -- cstamas opened a new pull request, #194: URL: https://github.com/apache/maven-resolver/pull/194 Create more compact FS NameMapper. Also, clean up existing ones and reduce clutter and mess. High level changes: * Introduce StringDigestUtil for String hashing (cleanup the mess of digest/checksum mixup, deprecate and make unused SimpleDigest) * Introduce HashingNameMapper (implements the "more compact" name mapper) * Cleanup and simplify existing NameMapper implementations * Introduce providers for "user facing" configuration names, as those are usually combination of existing NameMappers (like one wrapping other, etc). Hence, to keep things simple, no NameMapper is component anymore but dedicated providers are constructing them. No user facing change happens by this, as mapper names remains same. --- https://issues.apache.org/jira/browse/MRESOLVER-273 > Create more compact File locking layout/mapper > -- > > Key: MRESOLVER-273 > URL: https://issues.apache.org/jira/browse/MRESOLVER-273 > Project: Maven Resolver > Issue Type: Improvement >Reporter: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Current FileGAVNameMapper "mimics" loosely local reposiory layout, uses long > paths, hence (relatively) big strings etc. > More compact layout would be just to hash strings like "a:G:A:V" and > "m:G[:A[:V]]" for artifacts and metadata instead, and create 2 level deep > hashed storage. > Problem with "loose" layout is that they do end up as files in OS, while > these would be much shorter. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-273) Create more compact File locking layout/mapper
[ https://issues.apache.org/jira/browse/MRESOLVER-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák reassigned MRESOLVER-273: - Assignee: Tamás Cservenák > Create more compact File locking layout/mapper > -- > > Key: MRESOLVER-273 > URL: https://issues.apache.org/jira/browse/MRESOLVER-273 > Project: Maven Resolver > Issue Type: Improvement >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Current FileGAVNameMapper "mimics" loosely local reposiory layout, uses long > paths, hence (relatively) big strings etc. > More compact layout would be just to hash strings like "a:G:A:V" and > "m:G[:A[:V]]" for artifacts and metadata instead, and create 2 level deep > hashed storage. > Problem with "loose" layout is that they do end up as files in OS, while > these would be much shorter. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-integration-testing] MartinKanters merged pull request #131: [MNG-7310] Add a test for MNG-7310
MartinKanters merged PR #131: URL: https://github.com/apache/maven-integration-testing/pull/131 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on pull request #194: [MRESOLVER-273] More compat filesystem friendly mapper
michael-o commented on PR #194: URL: https://github.com/apache/maven-resolver/pull/194#issuecomment-1249312238 Massive, give me some time to digest this... -- 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] MartinKanters merged pull request #783: [MNG-7098] Keep the project counter intact when resuming a multi-module project.
MartinKanters merged PR #783: URL: https://github.com/apache/maven/pull/783 -- 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-273) Create more compact File locking layout/mapper
[ https://issues.apache.org/jira/browse/MRESOLVER-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605798#comment-17605798 ] ASF GitHub Bot commented on MRESOLVER-273: -- michael-o commented on PR #194: URL: https://github.com/apache/maven-resolver/pull/194#issuecomment-1249312238 Massive, give me some time to digest this... > Create more compact File locking layout/mapper > -- > > Key: MRESOLVER-273 > URL: https://issues.apache.org/jira/browse/MRESOLVER-273 > Project: Maven Resolver > Issue Type: Improvement >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Current FileGAVNameMapper "mimics" loosely local reposiory layout, uses long > paths, hence (relatively) big strings etc. > More compact layout would be just to hash strings like "a:G:A:V" and > "m:G[:A[:V]]" for artifacts and metadata instead, and create 2 level deep > hashed storage. > Problem with "loose" layout is that they do end up as files in OS, while > these would be much shorter. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7098) Project counter should be cumulative when using resume
[
https://issues.apache.org/jira/browse/MNG-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605799#comment-17605799
]
ASF GitHub Bot commented on MNG-7098:
-
MartinKanters merged PR #783:
URL: https://github.com/apache/maven/pull/783
> Project counter should be cumulative when using resume
> --
>
> Key: MNG-7098
> URL: https://issues.apache.org/jira/browse/MNG-7098
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and Workspace
>Reporter: Robert Scholte
>Priority: Minor
> Fix For: 4.0.x-candidate
>
>
> When doing a resume on a build, the counter now starts again at 1.
> E.g. Suppose a project has 10 modules and the 7th module fails. With a resume
> now you'll see {{[1/4]}}.
> To me it makes more sense to say {{[7/10]}}. You're still as close to the end
> as usual, but this indicates the size of the complete project.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] MartinKanters commented on pull request #639: [MNG-7310] Using the plexusContainer to prevent loading lifecycle defined by extensions from other submodules.
MartinKanters commented on PR #639: URL: https://github.com/apache/maven/pull/639#issuecomment-1249317237 > @MartinKanters Should I test again after your followups? I took care of that :) -- 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-7310) Maven loads extension from another submodule
[
https://issues.apache.org/jira/browse/MNG-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605800#comment-17605800
]
ASF GitHub Bot commented on MNG-7310:
-
MartinKanters commented on PR #639:
URL: https://github.com/apache/maven/pull/639#issuecomment-1249317237
> @MartinKanters Should I test again after your followups?
I took care of that :)
> Maven loads extension from another submodule
>
>
> Key: MNG-7310
> URL: https://issues.apache.org/jira/browse/MNG-7310
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-1
>Reporter: Martin Kanters
>Priority: Major
> Attachments: demo-plugins.zip
>
>
> With the latest Maven master, I'm not able to build a certain multi module
> project.
> It fails with the following error:
> C:\work\apache\demo>mvn validate
> [INFO] Scanning for projects...
> ...
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project com.example:demo2:0.0.1-SNAPSHOT
> (C:\work\apache\demo\demo2\pom.xml) has 1 error
> [ERROR] 'build.plugins.plugin.version' for
> org.springframework.cloud:spring-cloud-contract-maven-plugin must be a valid
> version but is '${project.version}'. @
> org.apache.maven:maven-core:4.0.0-alpha-1-SNAPSHOT:default-lifecycle-bindings
> The project looks as follows:
> parent
> – demo (module containing plugin "spring-cloud-contract-maven-plugin")
> – demo2 (module)
> "demo2" has no dependency on "demo" and the parent of "demo2" is "parent"..
> Somehow, the plugin from "demo" leaks into "demo2", which I've verified is
> the case during a debug session.
> I'm still unsure of a couple of things:
> - Does it only happen with the "spring-cloud-contract-maven-plugin" plugin?
> - Where does ${project.version} come from? (I've not defined it)
> I've done a bisect and tracked it down to the following commit:
> [[MNG-5577] Convert maven-core to JSR
> 330|https://github.com/apache/maven/commit/9567da2bc889a94f5c3b692b4afb310ddbacd6e5]
> Subject project is attached. Reproduce with the current master of Maven: mvn
> validate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] MartinKanters merged pull request #639: [MNG-7310] Using the plexusContainer to prevent loading lifecycle defined by extensions from other submodules.
MartinKanters merged PR #639: URL: https://github.com/apache/maven/pull/639 -- 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-7310) Maven loads extension from another submodule
[
https://issues.apache.org/jira/browse/MNG-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605801#comment-17605801
]
ASF GitHub Bot commented on MNG-7310:
-
MartinKanters merged PR #639:
URL: https://github.com/apache/maven/pull/639
> Maven loads extension from another submodule
>
>
> Key: MNG-7310
> URL: https://issues.apache.org/jira/browse/MNG-7310
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-1
>Reporter: Martin Kanters
>Priority: Major
> Attachments: demo-plugins.zip
>
>
> With the latest Maven master, I'm not able to build a certain multi module
> project.
> It fails with the following error:
> C:\work\apache\demo>mvn validate
> [INFO] Scanning for projects...
> ...
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project com.example:demo2:0.0.1-SNAPSHOT
> (C:\work\apache\demo\demo2\pom.xml) has 1 error
> [ERROR] 'build.plugins.plugin.version' for
> org.springframework.cloud:spring-cloud-contract-maven-plugin must be a valid
> version but is '${project.version}'. @
> org.apache.maven:maven-core:4.0.0-alpha-1-SNAPSHOT:default-lifecycle-bindings
> The project looks as follows:
> parent
> – demo (module containing plugin "spring-cloud-contract-maven-plugin")
> – demo2 (module)
> "demo2" has no dependency on "demo" and the parent of "demo2" is "parent"..
> Somehow, the plugin from "demo" leaks into "demo2", which I've verified is
> the case during a debug session.
> I'm still unsure of a couple of things:
> - Does it only happen with the "spring-cloud-contract-maven-plugin" plugin?
> - Where does ${project.version} come from? (I've not defined it)
> I've done a bisect and tracked it down to the following commit:
> [[MNG-5577] Convert maven-core to JSR
> 330|https://github.com/apache/maven/commit/9567da2bc889a94f5c3b692b4afb310ddbacd6e5]
> Subject project is attached. Reproduce with the current master of Maven: mvn
> validate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] michael-o commented on a diff in pull request #783: [MNG-7098] Keep the project counter intact when resuming a multi-module project.
michael-o commented on code in PR #783: URL: https://github.com/apache/maven/pull/783#discussion_r972986997 ## maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java: ## @@ -143,7 +143,11 @@ public void sessionStarted( ExecutionEvent event ) project.getName(), chars( ' ', ( len > 0 ) ? len : 1 ), project.getPackaging() ); } -totalProjects = projects.size(); +final List allProjects = event.getSession().getAllProjects(); Review Comment: I would at least raise a JIRA issue. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7098) Project counter should be cumulative when using resume
[
https://issues.apache.org/jira/browse/MNG-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605802#comment-17605802
]
ASF GitHub Bot commented on MNG-7098:
-
michael-o commented on code in PR #783:
URL: https://github.com/apache/maven/pull/783#discussion_r972986997
##
maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java:
##
@@ -143,7 +143,11 @@ public void sessionStarted( ExecutionEvent event )
project.getName(), chars( ' ', ( len > 0 ) ? len : 1
), project.getPackaging() );
}
-totalProjects = projects.size();
+final List allProjects =
event.getSession().getAllProjects();
Review Comment:
I would at least raise a JIRA issue.
> Project counter should be cumulative when using resume
> --
>
> Key: MNG-7098
> URL: https://issues.apache.org/jira/browse/MNG-7098
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and Workspace
>Reporter: Robert Scholte
>Priority: Minor
> Fix For: 4.0.x-candidate
>
>
> When doing a resume on a build, the counter now starts again at 1.
> E.g. Suppose a project has 10 modules and the 7th module fails. With a resume
> now you'll see {{[1/4]}}.
> To me it makes more sense to say {{[7/10]}}. You're still as close to the end
> as usual, but this indicates the size of the complete project.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on pull request #193: [MRESOLVER-272] Update parent POM
cstamas commented on PR #193: URL: https://github.com/apache/maven-resolver/pull/193#issuecomment-1249344055 @michael-o take a look at this one as well ,please seems some ignores changed, similar to those you discuss on ML? -- 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-272) Update parent POM to 37, remove plugin version overrides, update bnd
[ https://issues.apache.org/jira/browse/MRESOLVER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605812#comment-17605812 ] ASF GitHub Bot commented on MRESOLVER-272: -- cstamas commented on PR #193: URL: https://github.com/apache/maven-resolver/pull/193#issuecomment-1249344055 @michael-o take a look at this one as well ,please seems some ignores changed, similar to those you discuss on ML? > Update parent POM to 37, remove plugin version overrides, update bnd > > > Key: MRESOLVER-272 > URL: https://issues.apache.org/jira/browse/MRESOLVER-272 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Remove version overrides and update bnd plugin to 6.3.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-272) Update parent POM to 37, remove plugin version overrides, update bnd
[ https://issues.apache.org/jira/browse/MRESOLVER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák reassigned MRESOLVER-272: - Assignee: Tamás Cservenák > Update parent POM to 37, remove plugin version overrides, update bnd > > > Key: MRESOLVER-272 > URL: https://issues.apache.org/jira/browse/MRESOLVER-272 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Remove version overrides and update bnd plugin to 6.3.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] michael-o commented on pull request #193: [MRESOLVER-272] Update parent POM
michael-o commented on PR #193: URL: https://github.com/apache/maven-resolver/pull/193#issuecomment-1249348244 Yes, @kwin knows how to deal with. -- 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-272) Update parent POM to 37, remove plugin version overrides, update bnd
[ https://issues.apache.org/jira/browse/MRESOLVER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605813#comment-17605813 ] ASF GitHub Bot commented on MRESOLVER-272: -- michael-o commented on PR #193: URL: https://github.com/apache/maven-resolver/pull/193#issuecomment-1249348244 Yes, @kwin knows how to deal with. > Update parent POM to 37, remove plugin version overrides, update bnd > > > Key: MRESOLVER-272 > URL: https://issues.apache.org/jira/browse/MRESOLVER-272 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Remove version overrides and update bnd plugin to 6.3.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-266) Simplify adapter creation and align configuration for it
[ https://issues.apache.org/jira/browse/MRESOLVER-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák reassigned MRESOLVER-266: - Assignee: Tamás Cservenák > Simplify adapter creation and align configuration for it > > > Key: MRESOLVER-266 > URL: https://issues.apache.org/jira/browse/MRESOLVER-266 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Rework how named lock factory adapter is created, it is the ONLY bit reaching > directly to Java System Properties instead to rely on session config > properties. This makes it impossible to control from Maven for example (as it > is "too late"). > Proposed changes: > * adapter should be created based on session config properties, not Java > system properties > * adapter should be stored within session > * adapter creation should be vastly simplified (currently we have 4 involved > class: selectors and default sync context) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7098) Project counter should be cumulative when using resume
[
https://issues.apache.org/jira/browse/MNG-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605817#comment-17605817
]
Hudson commented on MNG-7098:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » master #88
See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/88/
> Project counter should be cumulative when using resume
> --
>
> Key: MNG-7098
> URL: https://issues.apache.org/jira/browse/MNG-7098
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and Workspace
>Reporter: Robert Scholte
>Priority: Minor
> Fix For: 4.0.x-candidate
>
>
> When doing a resume on a build, the counter now starts again at 1.
> E.g. Suppose a project has 10 modules and the 7th module fails. With a resume
> now you'll see {{[1/4]}}.
> To me it makes more sense to say {{[7/10]}}. You're still as close to the end
> as usual, but this indicates the size of the complete project.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7310) Maven loads extension from another submodule
[
https://issues.apache.org/jira/browse/MNG-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605818#comment-17605818
]
Hudson commented on MNG-7310:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » master #88
See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/88/
> Maven loads extension from another submodule
>
>
> Key: MNG-7310
> URL: https://issues.apache.org/jira/browse/MNG-7310
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-1
>Reporter: Martin Kanters
>Priority: Major
> Attachments: demo-plugins.zip
>
>
> With the latest Maven master, I'm not able to build a certain multi module
> project.
> It fails with the following error:
> C:\work\apache\demo>mvn validate
> [INFO] Scanning for projects...
> ...
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project com.example:demo2:0.0.1-SNAPSHOT
> (C:\work\apache\demo\demo2\pom.xml) has 1 error
> [ERROR] 'build.plugins.plugin.version' for
> org.springframework.cloud:spring-cloud-contract-maven-plugin must be a valid
> version but is '${project.version}'. @
> org.apache.maven:maven-core:4.0.0-alpha-1-SNAPSHOT:default-lifecycle-bindings
> The project looks as follows:
> parent
> – demo (module containing plugin "spring-cloud-contract-maven-plugin")
> – demo2 (module)
> "demo2" has no dependency on "demo" and the parent of "demo2" is "parent"..
> Somehow, the plugin from "demo" leaks into "demo2", which I've verified is
> the case during a debug session.
> I'm still unsure of a couple of things:
> - Does it only happen with the "spring-cloud-contract-maven-plugin" plugin?
> - Where does ${project.version} come from? (I've not defined it)
> I've done a bisect and tracked it down to the following commit:
> [[MNG-5577] Convert maven-core to JSR
> 330|https://github.com/apache/maven/commit/9567da2bc889a94f5c3b692b4afb310ddbacd6e5]
> Subject project is attached. Reproduce with the current master of Maven: mvn
> validate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7310) Maven loads extension from another submodule
[
https://issues.apache.org/jira/browse/MNG-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605819#comment-17605819
]
Hudson commented on MNG-7310:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » master #89
See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/89/
> Maven loads extension from another submodule
>
>
> Key: MNG-7310
> URL: https://issues.apache.org/jira/browse/MNG-7310
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-1
>Reporter: Martin Kanters
>Priority: Major
> Attachments: demo-plugins.zip
>
>
> With the latest Maven master, I'm not able to build a certain multi module
> project.
> It fails with the following error:
> C:\work\apache\demo>mvn validate
> [INFO] Scanning for projects...
> ...
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project com.example:demo2:0.0.1-SNAPSHOT
> (C:\work\apache\demo\demo2\pom.xml) has 1 error
> [ERROR] 'build.plugins.plugin.version' for
> org.springframework.cloud:spring-cloud-contract-maven-plugin must be a valid
> version but is '${project.version}'. @
> org.apache.maven:maven-core:4.0.0-alpha-1-SNAPSHOT:default-lifecycle-bindings
> The project looks as follows:
> parent
> – demo (module containing plugin "spring-cloud-contract-maven-plugin")
> – demo2 (module)
> "demo2" has no dependency on "demo" and the parent of "demo2" is "parent"..
> Somehow, the plugin from "demo" leaks into "demo2", which I've verified is
> the case during a debug session.
> I'm still unsure of a couple of things:
> - Does it only happen with the "spring-cloud-contract-maven-plugin" plugin?
> - Where does ${project.version} come from? (I've not defined it)
> I've done a bisect and tracked it down to the following commit:
> [[MNG-5577] Convert maven-core to JSR
> 330|https://github.com/apache/maven/commit/9567da2bc889a94f5c3b692b4afb310ddbacd6e5]
> Subject project is attached. Reproduce with the current master of Maven: mvn
> validate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAR-138) jar:test-jar is skipped when maven.test.skip=true
[ https://issues.apache.org/jira/browse/MJAR-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605828#comment-17605828 ] J commented on MJAR-138: Any news on this? > jar:test-jar is skipped when maven.test.skip=true > - > > Key: MJAR-138 > URL: https://issues.apache.org/jira/browse/MJAR-138 > Project: Maven JAR Plugin > Issue Type: Improvement >Affects Versions: 2.3.1 > Environment: jar:test-jar >Reporter: Andrew Hughes >Priority: Major > Fix For: more-investigation > > Attachments: MJAR-138-maven-jar-plugin.patch > > > Not sure if this is a bug or improvement... > Example: > * ./pom.xml > * ./moduleA/pom.xml > * ./moduleB/pom.xml > Situation: > * moduleA produces moduleA-1.2.3-test.jar with the jar:test-jar goal > * moduleB consumes moduleA-1.2.3-test.jar as a > ...test > Problem: > * When -Dmaven.test.skip=true the moduleA-1.2.3-test.jar is never built. > * Then when moduleB tries to build, it's moduleA-1.2.3-test.jar dependency is > unresolved. FAIL! Even with -Dmaven.test.skip=true this will fail. > You might argue that this is a bug with dependency resolution with > -Dmaven.test.skip=true - should a missing dependency @ test scope really fail > the build??? It probably should - which is why the bug is submitted here :) > I've no idea what could be done to fix this either? > --- > p.s. for anyone with this bug the only workaround I can suggest is running > another module... > ./moduleA-test/pom.xml > and have > ...moduleA-test...test -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas closed pull request #194: [MRESOLVER-273] More compat filesystem friendly mapper
cstamas closed pull request #194: [MRESOLVER-273] More compat filesystem friendly mapper URL: https://github.com/apache/maven-resolver/pull/194 -- 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-273) Create more compact File locking layout/mapper
[ https://issues.apache.org/jira/browse/MRESOLVER-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605830#comment-17605830 ] ASF GitHub Bot commented on MRESOLVER-273: -- cstamas closed pull request #194: [MRESOLVER-273] More compat filesystem friendly mapper URL: https://github.com/apache/maven-resolver/pull/194 > Create more compact File locking layout/mapper > -- > > Key: MRESOLVER-273 > URL: https://issues.apache.org/jira/browse/MRESOLVER-273 > Project: Maven Resolver > Issue Type: Improvement >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Current FileGAVNameMapper "mimics" loosely local reposiory layout, uses long > paths, hence (relatively) big strings etc. > More compact layout would be just to hash strings like "a:G:A:V" and > "m:G[:A[:V]]" for artifacts and metadata instead, and create 2 level deep > hashed storage. > Problem with "loose" layout is that they do end up as files in OS, while > these would be much shorter. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-273) Create more compact File locking layout/mapper
[ https://issues.apache.org/jira/browse/MRESOLVER-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605831#comment-17605831 ] ASF GitHub Bot commented on MRESOLVER-273: -- cstamas opened a new pull request, #194: URL: https://github.com/apache/maven-resolver/pull/194 Create more compact FS NameMapper. Also, clean up existing ones and reduce clutter and mess. High level changes: * Introduce StringDigestUtil for String hashing (cleanup the mess of digest/checksum mixup, deprecate and make unused SimpleDigest) * Introduce HashingNameMapper (implements the "more compact" name mapper) * Cleanup and simplify existing NameMapper implementations * Introduce providers for "user facing" configuration names, as those are usually combination of existing NameMappers (like one wrapping other, etc). Hence, to keep things simple, no NameMapper is component anymore but dedicated providers are constructing them. No user facing change happens by this, as mapper names remains same. --- https://issues.apache.org/jira/browse/MRESOLVER-273 > Create more compact File locking layout/mapper > -- > > Key: MRESOLVER-273 > URL: https://issues.apache.org/jira/browse/MRESOLVER-273 > Project: Maven Resolver > Issue Type: Improvement >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Current FileGAVNameMapper "mimics" loosely local reposiory layout, uses long > paths, hence (relatively) big strings etc. > More compact layout would be just to hash strings like "a:G:A:V" and > "m:G[:A[:V]]" for artifacts and metadata instead, and create 2 level deep > hashed storage. > Problem with "loose" layout is that they do end up as files in OS, while > these would be much shorter. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] michael-o commented on a diff in pull request #194: [MRESOLVER-273] More compat filesystem friendly mapper
michael-o commented on code in PR #194:
URL: https://github.com/apache/maven-resolver/pull/194#discussion_r973033770
##
maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/synccontext/named/NameMapperTestSupport.java:
##
@@ -41,9 +42,9 @@
protected RepositorySystemSession session;
@Before
-public void before()
+public void before() throws IOException
{
-baseDir = "/home/maven/.m2/repository";
+baseDir = new File("/home/maven/.m2/repository").getCanonicalPath();
Review Comment:
This test is deemed to fail, no?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-273) Create more compact File locking layout/mapper
[
https://issues.apache.org/jira/browse/MRESOLVER-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605832#comment-17605832
]
ASF GitHub Bot commented on MRESOLVER-273:
--
michael-o commented on code in PR #194:
URL: https://github.com/apache/maven-resolver/pull/194#discussion_r973033770
##
maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/synccontext/named/NameMapperTestSupport.java:
##
@@ -41,9 +42,9 @@
protected RepositorySystemSession session;
@Before
-public void before()
+public void before() throws IOException
{
-baseDir = "/home/maven/.m2/repository";
+baseDir = new File("/home/maven/.m2/repository").getCanonicalPath();
Review Comment:
This test is deemed to fail, no?
> Create more compact File locking layout/mapper
> --
>
> Key: MRESOLVER-273
> URL: https://issues.apache.org/jira/browse/MRESOLVER-273
> Project: Maven Resolver
> Issue Type: Improvement
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: resolver-next
>
>
> Current FileGAVNameMapper "mimics" loosely local reposiory layout, uses long
> paths, hence (relatively) big strings etc.
> More compact layout would be just to hash strings like "a:G:A:V" and
> "m:G[:A[:V]]" for artifacts and metadata instead, and create 2 level deep
> hashed storage.
> Problem with "loose" layout is that they do end up as files in OS, while
> these would be much shorter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on a diff in pull request #194: [MRESOLVER-273] More compat filesystem friendly mapper
cstamas commented on code in PR #194:
URL: https://github.com/apache/maven-resolver/pull/194#discussion_r973035259
##
maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/synccontext/named/NameMapperTestSupport.java:
##
@@ -41,9 +42,9 @@
protected RepositorySystemSession session;
@Before
-public void before()
+public void before() throws IOException
{
-baseDir = "/home/maven/.m2/repository";
+baseDir = new File("/home/maven/.m2/repository").getCanonicalPath();
Review Comment:
why?
--
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] MartinKanters opened a new pull request, #804: [MNG-7098] Keep the project counter intact when resuming a multi-module project.
MartinKanters opened a new pull request, #804: URL: https://github.com/apache/maven/pull/804 This code change was accidentally already merged into master, and then reverted. This is the [original PR](https://github.com/apache/maven/pull/783). --- This PR ensures that when a multi module project is resumed halfway, the project progress counter is not reset. [Related issue](https://issues.apache.org/jira/browse/MNG-7098). Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-273) Create more compact File locking layout/mapper
[
https://issues.apache.org/jira/browse/MRESOLVER-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605834#comment-17605834
]
ASF GitHub Bot commented on MRESOLVER-273:
--
cstamas commented on code in PR #194:
URL: https://github.com/apache/maven-resolver/pull/194#discussion_r973035259
##
maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/synccontext/named/NameMapperTestSupport.java:
##
@@ -41,9 +42,9 @@
protected RepositorySystemSession session;
@Before
-public void before()
+public void before() throws IOException
{
-baseDir = "/home/maven/.m2/repository";
+baseDir = new File("/home/maven/.m2/repository").getCanonicalPath();
Review Comment:
why?
> Create more compact File locking layout/mapper
> --
>
> Key: MRESOLVER-273
> URL: https://issues.apache.org/jira/browse/MRESOLVER-273
> Project: Maven Resolver
> Issue Type: Improvement
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: resolver-next
>
>
> Current FileGAVNameMapper "mimics" loosely local reposiory layout, uses long
> paths, hence (relatively) big strings etc.
> More compact layout would be just to hash strings like "a:G:A:V" and
> "m:G[:A[:V]]" for artifacts and metadata instead, and create 2 level deep
> hashed storage.
> Problem with "loose" layout is that they do end up as files in OS, while
> these would be much shorter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7098) Project counter should be cumulative when using resume
[
https://issues.apache.org/jira/browse/MNG-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605835#comment-17605835
]
ASF GitHub Bot commented on MNG-7098:
-
MartinKanters opened a new pull request, #804:
URL: https://github.com/apache/maven/pull/804
This code change was accidentally already merged into master, and then
reverted. This is the [original PR](https://github.com/apache/maven/pull/783).
---
This PR ensures that when a multi module project is resumed halfway, the
project progress counter is not reset.
[Related issue](https://issues.apache.org/jira/browse/MNG-7098).
Following this checklist to help us incorporate your
contribution quickly and easily:
- [x] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/MNG) filed
for the change (usually before you start working on it). Trivial
changes like typos do not
require a JIRA issue. Your pull request should address just this
issue, without
pulling in other changes.
- [x] Each commit in the pull request should have a meaningful subject line
and body.
- [x] Format the pull request title like `[MNG-XXX] SUMMARY`, where you
replace `MNG-XXX`
and `SUMMARY` with the appropriate JIRA issue. Best practice is to
use the JIRA issue
title in the pull request title and in the first line of the commit
message.
- [x] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [x] Run `mvn clean verify` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [x] You have run the [Core IT][core-its] successfully.
If your pull request is about ~20 lines of code you don't need to sign an
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [x] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [x] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
[core-its]: https://maven.apache.org/core-its/core-it-suite/
> Project counter should be cumulative when using resume
> --
>
> Key: MNG-7098
> URL: https://issues.apache.org/jira/browse/MNG-7098
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and Workspace
>Reporter: Robert Scholte
>Priority: Minor
> Fix For: 4.0.x-candidate
>
>
> When doing a resume on a build, the counter now starts again at 1.
> E.g. Suppose a project has 10 modules and the 7th module fails. With a resume
> now you'll see {{[1/4]}}.
> To me it makes more sense to say {{[7/10]}}. You're still as close to the end
> as usual, but this indicates the size of the complete project.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] MartinKanters commented on a diff in pull request #783: [MNG-7098] Keep the project counter intact when resuming a multi-module project.
MartinKanters commented on code in PR #783: URL: https://github.com/apache/maven/pull/783#discussion_r973038017 ## maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java: ## @@ -143,7 +143,11 @@ public void sessionStarted( ExecutionEvent event ) project.getName(), chars( ' ', ( len > 0 ) ? len : 1 ), project.getPackaging() ); } -totalProjects = projects.size(); +final List allProjects = event.getSession().getAllProjects(); Review Comment: A JIRA for removing that method and adding the JIRA number into the TODO? -- 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-7098) Project counter should be cumulative when using resume
[
https://issues.apache.org/jira/browse/MNG-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605838#comment-17605838
]
ASF GitHub Bot commented on MNG-7098:
-
MartinKanters commented on code in PR #783:
URL: https://github.com/apache/maven/pull/783#discussion_r973038017
##
maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java:
##
@@ -143,7 +143,11 @@ public void sessionStarted( ExecutionEvent event )
project.getName(), chars( ' ', ( len > 0 ) ? len : 1
), project.getPackaging() );
}
-totalProjects = projects.size();
+final List allProjects =
event.getSession().getAllProjects();
Review Comment:
A JIRA for removing that method and adding the JIRA number into the TODO?
> Project counter should be cumulative when using resume
> --
>
> Key: MNG-7098
> URL: https://issues.apache.org/jira/browse/MNG-7098
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and Workspace
>Reporter: Robert Scholte
>Priority: Minor
> Fix For: 4.0.x-candidate
>
>
> When doing a resume on a build, the counter now starts again at 1.
> E.g. Suppose a project has 10 modules and the 7th module fails. With a resume
> now you'll see {{[1/4]}}.
> To me it makes more sense to say {{[7/10]}}. You're still as close to the end
> as usual, but this indicates the size of the complete project.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7098) Project counter should be cumulative when using resume
[
https://issues.apache.org/jira/browse/MNG-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605841#comment-17605841
]
Hudson commented on MNG-7098:
-
Build failed in Jenkins: Maven » Maven TLP » maven » master #90
See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/90/
> Project counter should be cumulative when using resume
> --
>
> Key: MNG-7098
> URL: https://issues.apache.org/jira/browse/MNG-7098
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and Workspace
>Reporter: Robert Scholte
>Priority: Minor
> Fix For: 4.0.x-candidate
>
>
> When doing a resume on a build, the counter now starts again at 1.
> E.g. Suppose a project has 10 modules and the 7th module fails. With a resume
> now you'll see {{[1/4]}}.
> To me it makes more sense to say {{[7/10]}}. You're still as close to the end
> as usual, but this indicates the size of the complete project.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MNG-7310) Maven loads extension from another submodule
[
https://issues.apache.org/jira/browse/MNG-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Kanters resolved MNG-7310.
-
Resolution: Fixed
Issue is resolved with:
-
https://github.com/apache/maven/commit/7e0e9f9fbece8f416807c14fc6b582e501f3a414
-
https://github.com/apache/maven-integration-testing/commit/8993266166805a0667679011689f4e5a05eb9ddc
> Maven loads extension from another submodule
>
>
> Key: MNG-7310
> URL: https://issues.apache.org/jira/browse/MNG-7310
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-1
>Reporter: Martin Kanters
>Priority: Major
> Attachments: demo-plugins.zip
>
>
> With the latest Maven master, I'm not able to build a certain multi module
> project.
> It fails with the following error:
> C:\work\apache\demo>mvn validate
> [INFO] Scanning for projects...
> ...
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project com.example:demo2:0.0.1-SNAPSHOT
> (C:\work\apache\demo\demo2\pom.xml) has 1 error
> [ERROR] 'build.plugins.plugin.version' for
> org.springframework.cloud:spring-cloud-contract-maven-plugin must be a valid
> version but is '${project.version}'. @
> org.apache.maven:maven-core:4.0.0-alpha-1-SNAPSHOT:default-lifecycle-bindings
> The project looks as follows:
> parent
> – demo (module containing plugin "spring-cloud-contract-maven-plugin")
> – demo2 (module)
> "demo2" has no dependency on "demo" and the parent of "demo2" is "parent"..
> Somehow, the plugin from "demo" leaks into "demo2", which I've verified is
> the case during a debug session.
> I'm still unsure of a couple of things:
> - Does it only happen with the "spring-cloud-contract-maven-plugin" plugin?
> - Where does ${project.version} come from? (I've not defined it)
> I've done a bisect and tracked it down to the following commit:
> [[MNG-5577] Convert maven-core to JSR
> 330|https://github.com/apache/maven/commit/9567da2bc889a94f5c3b692b4afb310ddbacd6e5]
> Subject project is attached. Reproduce with the current master of Maven: mvn
> validate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7310) Maven loads extension from another submodule
[
https://issues.apache.org/jira/browse/MNG-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Kanters updated MNG-7310:
Fix Version/s: 4.0.0
> Maven loads extension from another submodule
>
>
> Key: MNG-7310
> URL: https://issues.apache.org/jira/browse/MNG-7310
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-1
>Reporter: Martin Kanters
>Priority: Major
> Fix For: 4.0.0
>
> Attachments: demo-plugins.zip
>
>
> With the latest Maven master, I'm not able to build a certain multi module
> project.
> It fails with the following error:
> C:\work\apache\demo>mvn validate
> [INFO] Scanning for projects...
> ...
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project com.example:demo2:0.0.1-SNAPSHOT
> (C:\work\apache\demo\demo2\pom.xml) has 1 error
> [ERROR] 'build.plugins.plugin.version' for
> org.springframework.cloud:spring-cloud-contract-maven-plugin must be a valid
> version but is '${project.version}'. @
> org.apache.maven:maven-core:4.0.0-alpha-1-SNAPSHOT:default-lifecycle-bindings
> The project looks as follows:
> parent
> – demo (module containing plugin "spring-cloud-contract-maven-plugin")
> – demo2 (module)
> "demo2" has no dependency on "demo" and the parent of "demo2" is "parent"..
> Somehow, the plugin from "demo" leaks into "demo2", which I've verified is
> the case during a debug session.
> I'm still unsure of a couple of things:
> - Does it only happen with the "spring-cloud-contract-maven-plugin" plugin?
> - Where does ${project.version} come from? (I've not defined it)
> I've done a bisect and tracked it down to the following commit:
> [[MNG-5577] Convert maven-core to JSR
> 330|https://github.com/apache/maven/commit/9567da2bc889a94f5c3b692b4afb310ddbacd6e5]
> Subject project is attached. Reproduce with the current master of Maven: mvn
> validate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-resolver] kwin commented on pull request #193: [MRESOLVER-272] Update parent POM
kwin commented on PR #193: URL: https://github.com/apache/maven-resolver/pull/193#issuecomment-1249420770 @cstamas Can you enable https://creadur.apache.org/rat/apache-rat-plugin/check-mojo.html#consoleOutput in the root pom.xml's plugin configuration so that it is more easy to see where the failure is? I assume it is related to https://issues.apache.org/jira/browse/RAT-308. We can either add the Apache License header to it or add it to the ignores. -- 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-272) Update parent POM to 37, remove plugin version overrides, update bnd
[ https://issues.apache.org/jira/browse/MRESOLVER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605845#comment-17605845 ] ASF GitHub Bot commented on MRESOLVER-272: -- kwin commented on PR #193: URL: https://github.com/apache/maven-resolver/pull/193#issuecomment-1249420770 @cstamas Can you enable https://creadur.apache.org/rat/apache-rat-plugin/check-mojo.html#consoleOutput in the root pom.xml's plugin configuration so that it is more easy to see where the failure is? I assume it is related to https://issues.apache.org/jira/browse/RAT-308. We can either add the Apache License header to it or add it to the ignores. > Update parent POM to 37, remove plugin version overrides, update bnd > > > Key: MRESOLVER-272 > URL: https://issues.apache.org/jira/browse/MRESOLVER-272 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Remove version overrides and update bnd plugin to 6.3.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] slawekjaranowski commented on pull request #193: [MRESOLVER-272] Update parent POM
slawekjaranowski commented on PR #193: URL: https://github.com/apache/maven-resolver/pull/193#issuecomment-1249430113 I added `.gitattributes` to excluded list for RAT in https://github.com/apache/maven/pull/792 -- 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-272) Update parent POM to 37, remove plugin version overrides, update bnd
[ https://issues.apache.org/jira/browse/MRESOLVER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605849#comment-17605849 ] ASF GitHub Bot commented on MRESOLVER-272: -- cstamas commented on PR #193: URL: https://github.com/apache/maven-resolver/pull/193#issuecomment-1249429595 @kwin @michael-o "traded" old Travis rat ignore to gitattibutes, locally is OK, let me see CI. > Update parent POM to 37, remove plugin version overrides, update bnd > > > Key: MRESOLVER-272 > URL: https://issues.apache.org/jira/browse/MRESOLVER-272 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Remove version overrides and update bnd plugin to 6.3.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on pull request #193: [MRESOLVER-272] Update parent POM
cstamas commented on PR #193: URL: https://github.com/apache/maven-resolver/pull/193#issuecomment-1249429595 @kwin @michael-o "traded" old Travis rat ignore to gitattibutes, locally is OK, let me see CI. -- 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-272) Update parent POM to 37, remove plugin version overrides, update bnd
[ https://issues.apache.org/jira/browse/MRESOLVER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605851#comment-17605851 ] ASF GitHub Bot commented on MRESOLVER-272: -- slawekjaranowski commented on PR #193: URL: https://github.com/apache/maven-resolver/pull/193#issuecomment-1249430113 I added `.gitattributes` to excluded list for RAT in https://github.com/apache/maven/pull/792 > Update parent POM to 37, remove plugin version overrides, update bnd > > > Key: MRESOLVER-272 > URL: https://issues.apache.org/jira/browse/MRESOLVER-272 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Remove version overrides and update bnd plugin to 6.3.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] kwin commented on pull request #193: [MRESOLVER-272] Update parent POM
kwin commented on PR #193: URL: https://github.com/apache/maven-resolver/pull/193#issuecomment-1249432715 Not sure about IP of a gitignore file but to me it seems safer to add an Apache License header to it according to https://www.apache.org/legal/src-headers.html#faq-exceptions. -- 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-272) Update parent POM to 37, remove plugin version overrides, update bnd
[ https://issues.apache.org/jira/browse/MRESOLVER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605853#comment-17605853 ] ASF GitHub Bot commented on MRESOLVER-272: -- kwin commented on PR #193: URL: https://github.com/apache/maven-resolver/pull/193#issuecomment-1249432715 Not sure about IP of a gitignore file but to me it seems safer to add an Apache License header to it according to https://www.apache.org/legal/src-headers.html#faq-exceptions. > Update parent POM to 37, remove plugin version overrides, update bnd > > > Key: MRESOLVER-272 > URL: https://issues.apache.org/jira/browse/MRESOLVER-272 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Remove version overrides and update bnd plugin to 6.3.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas commented on pull request #193: [MRESOLVER-272] Update parent POM
cstamas commented on PR #193: URL: https://github.com/apache/maven-resolver/pull/193#issuecomment-1249435233 IMHO, git config files carries no IP... they are more "environment" or so... -- 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-272) Update parent POM to 37, remove plugin version overrides, update bnd
[ https://issues.apache.org/jira/browse/MRESOLVER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605856#comment-17605856 ] ASF GitHub Bot commented on MRESOLVER-272: -- cstamas commented on PR #193: URL: https://github.com/apache/maven-resolver/pull/193#issuecomment-1249435233 IMHO, git config files carries no IP... they are more "environment" or so... > Update parent POM to 37, remove plugin version overrides, update bnd > > > Key: MRESOLVER-272 > URL: https://issues.apache.org/jira/browse/MRESOLVER-272 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Remove version overrides and update bnd plugin to 6.3.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] slawekjaranowski commented on pull request #193: [MRESOLVER-272] Update parent POM to 37, remove plugin version overrides, update bnd
slawekjaranowski commented on PR #193: URL: https://github.com/apache/maven-resolver/pull/193#issuecomment-1249445524 I don't see **creativity** in .git* files - so IMHO header is not 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] [Commented] (MRESOLVER-272) Update parent POM to 37, remove plugin version overrides, update bnd
[ https://issues.apache.org/jira/browse/MRESOLVER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605857#comment-17605857 ] ASF GitHub Bot commented on MRESOLVER-272: -- slawekjaranowski commented on PR #193: URL: https://github.com/apache/maven-resolver/pull/193#issuecomment-1249445524 I don't see **creativity** in .git* files - so IMHO header is not needed > Update parent POM to 37, remove plugin version overrides, update bnd > > > Key: MRESOLVER-272 > URL: https://issues.apache.org/jira/browse/MRESOLVER-272 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Remove version overrides and update bnd plugin to 6.3.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPOM-342) Configure some excludes for apache-rat-plugin
Konrad Windszus created MPOM-342:
Summary: Configure some excludes for apache-rat-plugin
Key: MPOM-342
URL: https://issues.apache.org/jira/browse/MPOM-342
Project: Maven POMs
Issue Type: Improvement
Components: asf
Reporter: Konrad Windszus
As the version 0.14 now also checks for license headers in {{.gitignore}} and
{{.gitattributes}} files (compare with RAT-308) and these files seem to be
considered not relevant (compare with
https://www.apache.org/legal/src-headers.html#faq-exceptions and
https://github.com/apache/maven-resolver/pull/193#issuecomment-1249435233)
those should be globally ignored for all ASF projects.
This has already been done for some downstream projects like
https://github.com/apache/maven/pull/792/files#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R578.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MPOM-342) Configure some default excludes for apache-rat-plugin
[
https://issues.apache.org/jira/browse/MPOM-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MPOM-342:
-
Summary: Configure some default excludes for apache-rat-plugin (was:
Configure some excludes for apache-rat-plugin)
> Configure some default excludes for apache-rat-plugin
> -
>
> Key: MPOM-342
> URL: https://issues.apache.org/jira/browse/MPOM-342
> Project: Maven POMs
> Issue Type: Improvement
> Components: asf
>Reporter: Konrad Windszus
>Priority: Major
>
> As the version 0.14 now also checks for license headers in {{.gitignore}} and
> {{.gitattributes}} files (compare with RAT-308) and these files seem to be
> considered not relevant (compare with
> https://www.apache.org/legal/src-headers.html#faq-exceptions and
> https://github.com/apache/maven-resolver/pull/193#issuecomment-1249435233)
> those should be globally ignored for all ASF projects.
> This has already been done for some downstream projects like
> https://github.com/apache/maven/pull/792/files#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R578.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] michael-o commented on a diff in pull request #783: [MNG-7098] Keep the project counter intact when resuming a multi-module project.
michael-o commented on code in PR #783: URL: https://github.com/apache/maven/pull/783#discussion_r973131293 ## maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java: ## @@ -143,7 +143,11 @@ public void sessionStarted( ExecutionEvent event ) project.getName(), chars( ' ', ( len > 0 ) ? len : 1 ), project.getPackaging() ); } -totalProjects = projects.size(); +final List allProjects = event.getSession().getAllProjects(); Review Comment: Yes -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] michael-o commented on pull request #804: [MNG-7098] Keep the project counter intact when resuming a multi-module project.
michael-o commented on PR #804: URL: https://github.com/apache/maven/pull/804#issuecomment-1249486693 Will schedule for the next couple of days -- 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-7098) Project counter should be cumulative when using resume
[
https://issues.apache.org/jira/browse/MNG-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605886#comment-17605886
]
ASF GitHub Bot commented on MNG-7098:
-
michael-o commented on code in PR #783:
URL: https://github.com/apache/maven/pull/783#discussion_r973131293
##
maven-embedder/src/main/java/org/apache/maven/cli/event/ExecutionEventLogger.java:
##
@@ -143,7 +143,11 @@ public void sessionStarted( ExecutionEvent event )
project.getName(), chars( ' ', ( len > 0 ) ? len : 1
), project.getPackaging() );
}
-totalProjects = projects.size();
+final List allProjects =
event.getSession().getAllProjects();
Review Comment:
Yes
> Project counter should be cumulative when using resume
> --
>
> Key: MNG-7098
> URL: https://issues.apache.org/jira/browse/MNG-7098
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and Workspace
>Reporter: Robert Scholte
>Priority: Minor
> Fix For: 4.0.x-candidate
>
>
> When doing a resume on a build, the counter now starts again at 1.
> E.g. Suppose a project has 10 modules and the 7th module fails. With a resume
> now you'll see {{[1/4]}}.
> To me it makes more sense to say {{[7/10]}}. You're still as close to the end
> as usual, but this indicates the size of the complete project.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7098) Project counter should be cumulative when using resume
[
https://issues.apache.org/jira/browse/MNG-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605888#comment-17605888
]
ASF GitHub Bot commented on MNG-7098:
-
michael-o commented on PR #804:
URL: https://github.com/apache/maven/pull/804#issuecomment-1249486693
Will schedule for the next couple of days
> Project counter should be cumulative when using resume
> --
>
> Key: MNG-7098
> URL: https://issues.apache.org/jira/browse/MNG-7098
> Project: Maven
> Issue Type: Improvement
> Components: Reactor and Workspace
>Reporter: Robert Scholte
>Priority: Minor
> Fix For: 4.0.x-candidate
>
>
> When doing a resume on a build, the counter now starts again at 1.
> E.g. Suppose a project has 10 modules and the 7th module fails. With a resume
> now you'll see {{[1/4]}}.
> To me it makes more sense to say {{[7/10]}}. You're still as close to the end
> as usual, but this indicates the size of the complete project.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-enforcer] dependabot[bot] opened a new pull request, #185: Bump maven-common-artifact-filters from 3.2.0 to 3.3.2
dependabot[bot] opened a new pull request, #185: URL: https://github.com/apache/maven-enforcer/pull/185 Bumps [maven-common-artifact-filters](https://github.com/apache/maven-common-artifact-filters) from 3.2.0 to 3.3.2. Commits https://github.com/apache/maven-common-artifact-filters/commit/31e20e5c0a2226285dc6b90fc5b3eaaf5f642d8a";>31e20e5 [maven-release-plugin] prepare release maven-common-artifact-filters-3.3.2 https://github.com/apache/maven-common-artifact-filters/commit/7660d9bc1429ffbe4c86cdaf7af5776d118883cf";>7660d9b [MSHARED-1131] Upgrade Parent to 37 and cleanup https://github.com/apache/maven-common-artifact-filters/commit/bde012cf6f793adf6d135e0356694dc1fef2c7f9";>bde012c (doc) small code cleanup from ide suggestions https://github.com/apache/maven-common-artifact-filters/commit/500569dad88b8f91e77116a2743a4685c920bed5";>500569d [MSHARED-1130] Sanitised value nullability in match(Pattern, boolean, String) https://github.com/apache/maven-common-artifact-filters/commit/299cf441a2e6eede21b0f1657c86f292ab4885b0";>299cf44 Use GH shared v3 https://github.com/apache/maven-common-artifact-filters/commit/37ea472bf2950d12a9176c91a9a79543f748846b";>37ea472 [maven-release-plugin] prepare for next development iteration https://github.com/apache/maven-common-artifact-filters/commit/b244fd9e0e7e84ee0e2e3ba3402f5ba654b5becd";>b244fd9 [maven-release-plugin] prepare release maven-common-artifact-filters-3.3.1 https://github.com/apache/maven-common-artifact-filters/commit/611baf61bc8ff8a26bf4af48dcf8ecb53e5c74dc";>611baf6 [MSHARED-1104] Four element pattern may be GATV or GATC (https://github-redirect.dependabot.com/apache/maven-common-artifact-filters/issues/29";>#29) https://github.com/apache/maven-common-artifact-filters/commit/0985a227dcc4de82759797b40b939c4ebb5f6ff5";>0985a22 Fix jenkins url https://github.com/apache/maven-common-artifact-filters/commit/94088c760d6e9b80cf166a5028b2a87b5af43cfa";>94088c7 [maven-release-plugin] prepare for next development iteration Additional commits viewable in https://github.com/apache/maven-common-artifact-filters/compare/maven-common-artifact-filters-3.2.0...maven-common-artifact-filters-3.3.2";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] dependabot[bot] closed pull request #173: Bump maven-common-artifact-filters from 3.2.0 to 3.3.1
dependabot[bot] closed pull request #173: Bump maven-common-artifact-filters from 3.2.0 to 3.3.1 URL: https://github.com/apache/maven-enforcer/pull/173 -- 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-enforcer] dependabot[bot] commented on pull request #173: Bump maven-common-artifact-filters from 3.2.0 to 3.3.1
dependabot[bot] commented on PR #173: URL: https://github.com/apache/maven-enforcer/pull/173#issuecomment-1249489747 Superseded by #185. -- 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-gh-actions-shared] slawekjaranowski merged pull request #58: Bump release-drafter/release-drafter from 5.20.1 to 5.21.0
slawekjaranowski merged PR #58: URL: https://github.com/apache/maven-gh-actions-shared/pull/58 -- 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-gh-actions-shared] slawekjaranowski merged pull request #59: Bump release-drafter/release-drafter from 5.20.1 to 5.21.0
slawekjaranowski merged PR #59: URL: https://github.com/apache/maven-gh-actions-shared/pull/59 -- 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] cstamas merged pull request #193: [MRESOLVER-272] Update parent POM to 37, remove plugin version overrides, update bnd
cstamas merged PR #193: URL: https://github.com/apache/maven-resolver/pull/193 -- 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-272) Update parent POM to 37, remove plugin version overrides, update bnd
[ https://issues.apache.org/jira/browse/MRESOLVER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605891#comment-17605891 ] ASF GitHub Bot commented on MRESOLVER-272: -- cstamas merged PR #193: URL: https://github.com/apache/maven-resolver/pull/193 > Update parent POM to 37, remove plugin version overrides, update bnd > > > Key: MRESOLVER-272 > URL: https://issues.apache.org/jira/browse/MRESOLVER-272 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Remove version overrides and update bnd plugin to 6.3.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MRESOLVER-272) Update parent POM to 37, remove plugin version overrides, update bnd
[ https://issues.apache.org/jira/browse/MRESOLVER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák resolved MRESOLVER-272. --- Resolution: Fixed > Update parent POM to 37, remove plugin version overrides, update bnd > > > Key: MRESOLVER-272 > URL: https://issues.apache.org/jira/browse/MRESOLVER-272 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Remove version overrides and update bnd plugin to 6.3.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-272) Update parent POM to 37, remove plugin version overrides, update bnd
[ https://issues.apache.org/jira/browse/MRESOLVER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák closed MRESOLVER-272. - > Update parent POM to 37, remove plugin version overrides, update bnd > > > Key: MRESOLVER-272 > URL: https://issues.apache.org/jira/browse/MRESOLVER-272 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Remove version overrides and update bnd plugin to 6.3.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-272) Update parent POM to 37, remove plugin version overrides, update bnd
[ https://issues.apache.org/jira/browse/MRESOLVER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605895#comment-17605895 ] Hudson commented on MRESOLVER-272: -- Build succeeded in Jenkins: Maven » Maven TLP » maven-resolver » master #50 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-resolver/job/master/50/ > Update parent POM to 37, remove plugin version overrides, update bnd > > > Key: MRESOLVER-272 > URL: https://issues.apache.org/jira/browse/MRESOLVER-272 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Remove version overrides and update bnd plugin to 6.3.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas closed pull request #188: [MRESOLVER-266] Simplify named lock adapter creation and align config source
cstamas closed pull request #188: [MRESOLVER-266] Simplify named lock adapter creation and align config source URL: https://github.com/apache/maven-resolver/pull/188 -- 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-266) Simplify adapter creation and align configuration for it
[ https://issues.apache.org/jira/browse/MRESOLVER-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605913#comment-17605913 ] ASF GitHub Bot commented on MRESOLVER-266: -- cstamas closed pull request #188: [MRESOLVER-266] Simplify named lock adapter creation and align config source URL: https://github.com/apache/maven-resolver/pull/188 > Simplify adapter creation and align configuration for it > > > Key: MRESOLVER-266 > URL: https://issues.apache.org/jira/browse/MRESOLVER-266 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Rework how named lock factory adapter is created, it is the ONLY bit reaching > directly to Java System Properties instead to rely on session config > properties. This makes it impossible to control from Maven for example (as it > is "too late"). > Proposed changes: > * adapter should be created based on session config properties, not Java > system properties > * adapter should be stored within session > * adapter creation should be vastly simplified (currently we have 4 involved > class: selectors and default sync context) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas opened a new pull request, #195: [MRESOLVER-266] Simplify named lock adapter creation and align config source
cstamas opened a new pull request, #195: URL: https://github.com/apache/maven-resolver/pull/195 Simplified adapter creation and now as everything else in resolver, session config properties are used as configuration source, not Java system properties. --- https://issues.apache.org/jira/browse/MRESOLVER-266 --- Supersede https://github.com/apache/maven-resolver/pull/188 -- 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-266) Simplify adapter creation and align configuration for it
[ https://issues.apache.org/jira/browse/MRESOLVER-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605914#comment-17605914 ] ASF GitHub Bot commented on MRESOLVER-266: -- cstamas opened a new pull request, #195: URL: https://github.com/apache/maven-resolver/pull/195 Simplified adapter creation and now as everything else in resolver, session config properties are used as configuration source, not Java system properties. --- https://issues.apache.org/jira/browse/MRESOLVER-266 --- Supersede https://github.com/apache/maven-resolver/pull/188 > Simplify adapter creation and align configuration for it > > > Key: MRESOLVER-266 > URL: https://issues.apache.org/jira/browse/MRESOLVER-266 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Rework how named lock factory adapter is created, it is the ONLY bit reaching > directly to Java System Properties instead to rely on session config > properties. This makes it impossible to control from Maven for example (as it > is "too late"). > Proposed changes: > * adapter should be created based on session config properties, not Java > system properties > * adapter should be stored within session > * adapter creation should be vastly simplified (currently we have 4 involved > class: selectors and default sync context) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas closed pull request #195: [MRESOLVER-266] Simplify named lock adapter creation and align config source
cstamas closed pull request #195: [MRESOLVER-266] Simplify named lock adapter creation and align config source URL: https://github.com/apache/maven-resolver/pull/195 -- 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-266) Simplify adapter creation and align configuration for it
[ https://issues.apache.org/jira/browse/MRESOLVER-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605915#comment-17605915 ] ASF GitHub Bot commented on MRESOLVER-266: -- cstamas closed pull request #195: [MRESOLVER-266] Simplify named lock adapter creation and align config source URL: https://github.com/apache/maven-resolver/pull/195 > Simplify adapter creation and align configuration for it > > > Key: MRESOLVER-266 > URL: https://issues.apache.org/jira/browse/MRESOLVER-266 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Rework how named lock factory adapter is created, it is the ONLY bit reaching > directly to Java System Properties instead to rely on session config > properties. This makes it impossible to control from Maven for example (as it > is "too late"). > Proposed changes: > * adapter should be created based on session config properties, not Java > system properties > * adapter should be stored within session > * adapter creation should be vastly simplified (currently we have 4 involved > class: selectors and default sync context) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] cstamas opened a new pull request, #196: [MRESOLVER-266] Simplify named lock adapter creation and align config source
cstamas opened a new pull request, #196: URL: https://github.com/apache/maven-resolver/pull/196 Simplified adapter creation and now as everything else in resolver, session config properties are used as configuration source, not Java system properties. --- https://issues.apache.org/jira/browse/MRESOLVER-266 -- 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-266) Simplify adapter creation and align configuration for it
[ https://issues.apache.org/jira/browse/MRESOLVER-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605916#comment-17605916 ] ASF GitHub Bot commented on MRESOLVER-266: -- cstamas opened a new pull request, #196: URL: https://github.com/apache/maven-resolver/pull/196 Simplified adapter creation and now as everything else in resolver, session config properties are used as configuration source, not Java system properties. --- https://issues.apache.org/jira/browse/MRESOLVER-266 > Simplify adapter creation and align configuration for it > > > Key: MRESOLVER-266 > URL: https://issues.apache.org/jira/browse/MRESOLVER-266 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: resolver-next > > > Rework how named lock factory adapter is created, it is the ONLY bit reaching > directly to Java System Properties instead to rely on session config > properties. This makes it impossible to control from Maven for example (as it > is "too late"). > Proposed changes: > * adapter should be created based on session config properties, not Java > system properties > * adapter should be stored within session > * adapter creation should be vastly simplified (currently we have 4 involved > class: selectors and default sync context) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] cstamas commented on pull request #763: [INFRA-23217] : s390x Jenkinsfile
cstamas commented on PR #763: URL: https://github.com/apache/maven/pull/763#issuecomment-1249569323 @slawekjaranowski @olamy you are more versed in Jenkins, please take a look -- 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-270) Maven resolver makes bad repository choices when resolving version ranges
[
https://issues.apache.org/jira/browse/MRESOLVER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605939#comment-17605939
]
Tamás Cservenák commented on MRESOLVER-270:
---
Just FTR this issue was actually fixed in Maven, there is no related change in
Maven Resolver, see MNG-7529 for details. Hence, I will modify this issue
resolution to something else as "Fixed" as that implies code change in resolver.
> Maven resolver makes bad repository choices when resolving version ranges
> -
>
> Key: MRESOLVER-270
> URL: https://issues.apache.org/jira/browse/MRESOLVER-270
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> This also affects the maven-resolver-provider which is part of Maven core. I
> still file the bug here because it is easier to explain.
> I have a repository setup like this:
> {quote}
>
> repo
>
>
> snapshots
> [https://.../maven-public/]
>
> false
> never
> warn
>
>
> true
> interval:180
> fail
>
> default
>
>
> central
> [https://...|https://.../]/maven-public/
>
> true
> never
> warn
>
>
> false
> interval:180
> fail
>
> default
>
>
> {quote}
>
> Maven is trying to resolve the metadata from this component:
> [https://repo1.maven.org/maven2/com/googlecode/owasp-java-html-sanitizer/owasp-java-html-sanitizer/20220608.1/owasp-java-html-sanitizer-20220608.1.pom]
> which contains (after resolution):
>
> {quote}
> com.google.code.findbugs
> jsr305
> [2.0.1,)
> provided
>
> {quote}
> {quote}
> com.google.code.findbugs
> annotations
> [2.0.1,)
> provided
>
>
> {quote}
>
> what happens now is that maven uses the DefaultVersionRangeResolver, which
> contains this line:
> {quote}{{Metadata metadata = new DefaultMetadata(
> request.getArtifact().getGroupId(), request.getArtifact().getArtifactId(),
> MAVEN_METADATA_XML, Metadata.Nature.RELEASE_OR_SNAPSHOT );}}
> {quote}
> So it tries to resolve the dependency range against all the repositories.
> By searching for "Nature.RELEASE_OR_SNAPSHOT", both configured repositories
> (snapshot and central) are eligible and selected. And by the order, the
> snapshot repository is chosen first.
> Because both remote repositories map to the same local repository, the
> following version check in lines 210 - 231 iterates over the local versions
> and finds the matching version in the "snapshots" repository.
> All of this code is called from the ProjectDependenciesResolver (which is
> injected into a mojo as a component), when calling resolve() on a
> DependencyResolutionRequest for this specific component
> (com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1).
> It results in the following (slightly obscure) error message:
> {quote}Could not resolve dependencies for project
> com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1:
> The following artifacts could not be resolved:
> com.google.code.findbugs:jsr305:jar:3.0.2,
> com.google.code.findbugs:annotations:jar:3.0.1u2: Could not find artifact
> com.google.code.findbugs:jsr305:jar:3.0.2
> {quote}
> However, that artifact is clearly present both in the local and remote
> repository.
>
> What happens is that the ProjectDependenciesResolver tries to resolve the
> (release) artifact om.google.code.findbugs:jsr305:jar:3.0.2 against the
> resolved repository (which is a snapshot only repository) and that repository
> rightfully refuses to resolve it. Hence the error message.
> I can fix this (which confirms this behavior) by removing the snapshot
> repository from the maven_settings.xml and enable snapshots for the "central"
> repository.
>
> Expected resolution: The DefaultVersionRangeResolver will not select the
> "first repository that contains the version" but looks at snapshot/release
> enabled and choose based on that information.
> I might find time to whip up a bug fix.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (MRESOLVER-270) Maven resolver makes bad repository choices when resolving version ranges
[
https://issues.apache.org/jira/browse/MRESOLVER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák reopened MRESOLVER-270:
---
Assignee: Tamás Cservenák
> Maven resolver makes bad repository choices when resolving version ranges
> -
>
> Key: MRESOLVER-270
> URL: https://issues.apache.org/jira/browse/MRESOLVER-270
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Henning Schmiedehausen
>Assignee: Tamás Cservenák
>Priority: Major
>
> This also affects the maven-resolver-provider which is part of Maven core. I
> still file the bug here because it is easier to explain.
> I have a repository setup like this:
> {quote}
>
> repo
>
>
> snapshots
> [https://.../maven-public/]
>
> false
> never
> warn
>
>
> true
> interval:180
> fail
>
> default
>
>
> central
> [https://...|https://.../]/maven-public/
>
> true
> never
> warn
>
>
> false
> interval:180
> fail
>
> default
>
>
> {quote}
>
> Maven is trying to resolve the metadata from this component:
> [https://repo1.maven.org/maven2/com/googlecode/owasp-java-html-sanitizer/owasp-java-html-sanitizer/20220608.1/owasp-java-html-sanitizer-20220608.1.pom]
> which contains (after resolution):
>
> {quote}
> com.google.code.findbugs
> jsr305
> [2.0.1,)
> provided
>
> {quote}
> {quote}
> com.google.code.findbugs
> annotations
> [2.0.1,)
> provided
>
>
> {quote}
>
> what happens now is that maven uses the DefaultVersionRangeResolver, which
> contains this line:
> {quote}{{Metadata metadata = new DefaultMetadata(
> request.getArtifact().getGroupId(), request.getArtifact().getArtifactId(),
> MAVEN_METADATA_XML, Metadata.Nature.RELEASE_OR_SNAPSHOT );}}
> {quote}
> So it tries to resolve the dependency range against all the repositories.
> By searching for "Nature.RELEASE_OR_SNAPSHOT", both configured repositories
> (snapshot and central) are eligible and selected. And by the order, the
> snapshot repository is chosen first.
> Because both remote repositories map to the same local repository, the
> following version check in lines 210 - 231 iterates over the local versions
> and finds the matching version in the "snapshots" repository.
> All of this code is called from the ProjectDependenciesResolver (which is
> injected into a mojo as a component), when calling resolve() on a
> DependencyResolutionRequest for this specific component
> (com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1).
> It results in the following (slightly obscure) error message:
> {quote}Could not resolve dependencies for project
> com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1:
> The following artifacts could not be resolved:
> com.google.code.findbugs:jsr305:jar:3.0.2,
> com.google.code.findbugs:annotations:jar:3.0.1u2: Could not find artifact
> com.google.code.findbugs:jsr305:jar:3.0.2
> {quote}
> However, that artifact is clearly present both in the local and remote
> repository.
>
> What happens is that the ProjectDependenciesResolver tries to resolve the
> (release) artifact om.google.code.findbugs:jsr305:jar:3.0.2 against the
> resolved repository (which is a snapshot only repository) and that repository
> rightfully refuses to resolve it. Hence the error message.
> I can fix this (which confirms this behavior) by removing the snapshot
> repository from the maven_settings.xml and enable snapshots for the "central"
> repository.
>
> Expected resolution: The DefaultVersionRangeResolver will not select the
> "first repository that contains the version" but looks at snapshot/release
> enabled and choose based on that information.
> I might find time to whip up a bug fix.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MRESOLVER-270) Maven resolver makes bad repository choices when resolving version ranges
[
https://issues.apache.org/jira/browse/MRESOLVER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák closed MRESOLVER-270.
-
> Maven resolver makes bad repository choices when resolving version ranges
> -
>
> Key: MRESOLVER-270
> URL: https://issues.apache.org/jira/browse/MRESOLVER-270
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Henning Schmiedehausen
>Assignee: Tamás Cservenák
>Priority: Major
>
> This also affects the maven-resolver-provider which is part of Maven core. I
> still file the bug here because it is easier to explain.
> I have a repository setup like this:
> {quote}
>
> repo
>
>
> snapshots
> [https://.../maven-public/]
>
> false
> never
> warn
>
>
> true
> interval:180
> fail
>
> default
>
>
> central
> [https://...|https://.../]/maven-public/
>
> true
> never
> warn
>
>
> false
> interval:180
> fail
>
> default
>
>
> {quote}
>
> Maven is trying to resolve the metadata from this component:
> [https://repo1.maven.org/maven2/com/googlecode/owasp-java-html-sanitizer/owasp-java-html-sanitizer/20220608.1/owasp-java-html-sanitizer-20220608.1.pom]
> which contains (after resolution):
>
> {quote}
> com.google.code.findbugs
> jsr305
> [2.0.1,)
> provided
>
> {quote}
> {quote}
> com.google.code.findbugs
> annotations
> [2.0.1,)
> provided
>
>
> {quote}
>
> what happens now is that maven uses the DefaultVersionRangeResolver, which
> contains this line:
> {quote}{{Metadata metadata = new DefaultMetadata(
> request.getArtifact().getGroupId(), request.getArtifact().getArtifactId(),
> MAVEN_METADATA_XML, Metadata.Nature.RELEASE_OR_SNAPSHOT );}}
> {quote}
> So it tries to resolve the dependency range against all the repositories.
> By searching for "Nature.RELEASE_OR_SNAPSHOT", both configured repositories
> (snapshot and central) are eligible and selected. And by the order, the
> snapshot repository is chosen first.
> Because both remote repositories map to the same local repository, the
> following version check in lines 210 - 231 iterates over the local versions
> and finds the matching version in the "snapshots" repository.
> All of this code is called from the ProjectDependenciesResolver (which is
> injected into a mojo as a component), when calling resolve() on a
> DependencyResolutionRequest for this specific component
> (com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1).
> It results in the following (slightly obscure) error message:
> {quote}Could not resolve dependencies for project
> com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1:
> The following artifacts could not be resolved:
> com.google.code.findbugs:jsr305:jar:3.0.2,
> com.google.code.findbugs:annotations:jar:3.0.1u2: Could not find artifact
> com.google.code.findbugs:jsr305:jar:3.0.2
> {quote}
> However, that artifact is clearly present both in the local and remote
> repository.
>
> What happens is that the ProjectDependenciesResolver tries to resolve the
> (release) artifact om.google.code.findbugs:jsr305:jar:3.0.2 against the
> resolved repository (which is a snapshot only repository) and that repository
> rightfully refuses to resolve it. Hence the error message.
> I can fix this (which confirms this behavior) by removing the snapshot
> repository from the maven_settings.xml and enable snapshots for the "central"
> repository.
>
> Expected resolution: The DefaultVersionRangeResolver will not select the
> "first repository that contains the version" but looks at snapshot/release
> enabled and choose based on that information.
> I might find time to whip up a bug fix.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MRESOLVER-270) Maven resolver makes bad repository choices when resolving version ranges
[
https://issues.apache.org/jira/browse/MRESOLVER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák resolved MRESOLVER-270.
---
Resolution: Won't Fix
Wont fix from resolver perspective, there is no code change in resolver.
> Maven resolver makes bad repository choices when resolving version ranges
> -
>
> Key: MRESOLVER-270
> URL: https://issues.apache.org/jira/browse/MRESOLVER-270
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Henning Schmiedehausen
>Assignee: Tamás Cservenák
>Priority: Major
>
> This also affects the maven-resolver-provider which is part of Maven core. I
> still file the bug here because it is easier to explain.
> I have a repository setup like this:
> {quote}
>
> repo
>
>
> snapshots
> [https://.../maven-public/]
>
> false
> never
> warn
>
>
> true
> interval:180
> fail
>
> default
>
>
> central
> [https://...|https://.../]/maven-public/
>
> true
> never
> warn
>
>
> false
> interval:180
> fail
>
> default
>
>
> {quote}
>
> Maven is trying to resolve the metadata from this component:
> [https://repo1.maven.org/maven2/com/googlecode/owasp-java-html-sanitizer/owasp-java-html-sanitizer/20220608.1/owasp-java-html-sanitizer-20220608.1.pom]
> which contains (after resolution):
>
> {quote}
> com.google.code.findbugs
> jsr305
> [2.0.1,)
> provided
>
> {quote}
> {quote}
> com.google.code.findbugs
> annotations
> [2.0.1,)
> provided
>
>
> {quote}
>
> what happens now is that maven uses the DefaultVersionRangeResolver, which
> contains this line:
> {quote}{{Metadata metadata = new DefaultMetadata(
> request.getArtifact().getGroupId(), request.getArtifact().getArtifactId(),
> MAVEN_METADATA_XML, Metadata.Nature.RELEASE_OR_SNAPSHOT );}}
> {quote}
> So it tries to resolve the dependency range against all the repositories.
> By searching for "Nature.RELEASE_OR_SNAPSHOT", both configured repositories
> (snapshot and central) are eligible and selected. And by the order, the
> snapshot repository is chosen first.
> Because both remote repositories map to the same local repository, the
> following version check in lines 210 - 231 iterates over the local versions
> and finds the matching version in the "snapshots" repository.
> All of this code is called from the ProjectDependenciesResolver (which is
> injected into a mojo as a component), when calling resolve() on a
> DependencyResolutionRequest for this specific component
> (com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1).
> It results in the following (slightly obscure) error message:
> {quote}Could not resolve dependencies for project
> com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1:
> The following artifacts could not be resolved:
> com.google.code.findbugs:jsr305:jar:3.0.2,
> com.google.code.findbugs:annotations:jar:3.0.1u2: Could not find artifact
> com.google.code.findbugs:jsr305:jar:3.0.2
> {quote}
> However, that artifact is clearly present both in the local and remote
> repository.
>
> What happens is that the ProjectDependenciesResolver tries to resolve the
> (release) artifact om.google.code.findbugs:jsr305:jar:3.0.2 against the
> resolved repository (which is a snapshot only repository) and that repository
> rightfully refuses to resolve it. Hence the error message.
> I can fix this (which confirms this behavior) by removing the snapshot
> repository from the maven_settings.xml and enable snapshots for the "central"
> repository.
>
> Expected resolution: The DefaultVersionRangeResolver will not select the
> "first repository that contains the version" but looks at snapshot/release
> enabled and choose based on that information.
> I might find time to whip up a bug fix.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-7529) Maven resolver makes bad repository choices when resolving version ranges
[ https://issues.apache.org/jira/browse/MNG-7529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák reassigned MNG-7529: Assignee: Tamás Cservenák > Maven resolver makes bad repository choices when resolving version ranges > - > > Key: MNG-7529 > URL: https://issues.apache.org/jira/browse/MNG-7529 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.8.6 >Reporter: Henning Schmiedehausen >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.8.x-candidate, 3.9.0, 4.0.0-alpha-1, 4.0.0 > > > This is the same problem as MRESOLVER-270. The problem is actually in the > maven core, not in the resolver. See the description there. > > This bug is a placeholder for the fix PR. -- This message was sent by Atlassian Jira (v8.20.10#820010)
