[jira] [Resolved] (MASSEMBLY-959) Update to Java8, drop unused dependencies
[ https://issues.apache.org/jira/browse/MASSEMBLY-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák resolved MASSEMBLY-959. --- Resolution: Fixed > Update to Java8, drop unused dependencies > - > > Key: MASSEMBLY-959 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-959 > Project: Maven Assembly Plugin > Issue Type: Task >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.3.1 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MSHARED-1081) Drop m-shared-utils from deps
[ https://issues.apache.org/jira/browse/MSHARED-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552582#comment-17552582 ] Hudson commented on MSHARED-1081: - Build succeeded in Jenkins: Maven » Maven TLP » maven-archiver » master #9 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-archiver/job/master/9/ > Drop m-shared-utils from deps > - > > Key: MSHARED-1081 > URL: https://issues.apache.org/jira/browse/MSHARED-1081 > Project: Maven Shared Components > Issue Type: Task > Components: maven-archiver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: maven-archiver-3.6.0 > > > maven-shared-utils are used for 3 methods, while plexus-utils, commons-io and > who knows what is present. Just ditch the maven-shared-utils. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (MASSEMBLY-959) Update to Java8, drop unused dependencies
[ https://issues.apache.org/jira/browse/MASSEMBLY-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák closed MASSEMBLY-959. - > Update to Java8, drop unused dependencies > - > > Key: MASSEMBLY-959 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-959 > Project: Maven Assembly Plugin > Issue Type: Task >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.3.1 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-assembly-plugin] cstamas merged pull request #67: [MASSEMBLY-959] Update to Java8 and drop m-shared-utils
cstamas merged PR #67: URL: https://github.com/apache/maven-assembly-plugin/pull/67 -- 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] (MSHARED-1081) Drop m-shared-utils from deps
[ https://issues.apache.org/jira/browse/MSHARED-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552581#comment-17552581 ] ASF GitHub Bot commented on MSHARED-1081: - cstamas merged PR #23: URL: https://github.com/apache/maven-archiver/pull/23 > Drop m-shared-utils from deps > - > > Key: MSHARED-1081 > URL: https://issues.apache.org/jira/browse/MSHARED-1081 > Project: Maven Shared Components > Issue Type: Task > Components: maven-archiver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: maven-archiver-3.6.0 > > > maven-shared-utils are used for 3 methods, while plexus-utils, commons-io and > who knows what is present. Just ditch the maven-shared-utils. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (MSHARED-1081) Drop m-shared-utils from deps
[ https://issues.apache.org/jira/browse/MSHARED-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák resolved MSHARED-1081. -- Resolution: Fixed > Drop m-shared-utils from deps > - > > Key: MSHARED-1081 > URL: https://issues.apache.org/jira/browse/MSHARED-1081 > Project: Maven Shared Components > Issue Type: Task > Components: maven-archiver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: maven-archiver-3.6.0 > > > maven-shared-utils are used for 3 methods, while plexus-utils, commons-io and > who knows what is present. Just ditch the maven-shared-utils. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (MSHARED-1081) Drop m-shared-utils from deps
[ https://issues.apache.org/jira/browse/MSHARED-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák reassigned MSHARED-1081: Assignee: Tamás Cservenák > Drop m-shared-utils from deps > - > > Key: MSHARED-1081 > URL: https://issues.apache.org/jira/browse/MSHARED-1081 > Project: Maven Shared Components > Issue Type: Task > Components: maven-archiver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: maven-archiver-3.6.0 > > > maven-shared-utils are used for 3 methods, while plexus-utils, commons-io and > who knows what is present. Just ditch the maven-shared-utils. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (MSHARED-1081) Drop m-shared-utils from deps
[ https://issues.apache.org/jira/browse/MSHARED-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák closed MSHARED-1081. > Drop m-shared-utils from deps > - > > Key: MSHARED-1081 > URL: https://issues.apache.org/jira/browse/MSHARED-1081 > Project: Maven Shared Components > Issue Type: Task > Components: maven-archiver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: maven-archiver-3.6.0 > > > maven-shared-utils are used for 3 methods, while plexus-utils, commons-io and > who knows what is present. Just ditch the maven-shared-utils. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-archiver] cstamas merged pull request #23: [MSHARED-1081] Drop m-shared-utils
cstamas merged PR #23: URL: https://github.com/apache/maven-archiver/pull/23 -- 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] (MSHADE-421) Shade plugin with latest Spring Boot 2.7.0 breaks actuator endpoints
[ https://issues.apache.org/jira/browse/MSHADE-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552580#comment-17552580 ] Florian Eberle commented on MSHADE-421: --- Thanks Phil! :) (And sorry for the noise in this project) > Shade plugin with latest Spring Boot 2.7.0 breaks actuator endpoints > > > Key: MSHADE-421 > URL: https://issues.apache.org/jira/browse/MSHADE-421 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 3.3.0 > Environment: Java 17, Maven 3.8.4 >Reporter: Florian Eberle >Priority: Major > > I am using Java 17 and the latest maven shade plugin in version 3.3.0. While > upgrading to the latest Spring Boot Version 2.7.0 maven shade seems to build > the jar incorrectly. > When running this jar, the actuator endpoints is not reachable anymore. I > have no clue what is causing this issue and appreciate any help. > > Please have a look at a small demo I created which visualizes the problem. > > [https://github.com/FloEberle/demo-spring-boot-maven-shade-actuator-endpoints-broken] > > To be transparent: since I am unsure where the issue is originating from I > also opened an > [issue|https://github.com/spring-projects/spring-boot/issues/31316] in the > spring boot project. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (SUREFIRE-2098) ParallelComputerUtilTest flaky test
Olivier Lamy created SUREFIRE-2098:
--
Summary: ParallelComputerUtilTest flaky test
Key: SUREFIRE-2098
URL: https://issues.apache.org/jira/browse/SUREFIRE-2098
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.7+ (parallel) support
Reporter: Olivier Lamy
the test ParallelComputerUtilTest made assumptions which can depend on node.
{code:java}
Error:
org.apache.maven.surefire.junitcore.pc.ParallelComputerUtilTest.withoutShutdown
Time elapsed: 11.846 s <<< ERROR!
2477java.lang.AssertionError: expected:<1.0> but was:<10502.0>
2478at org.junit.Assert.fail(Assert.java:91)
2479at org.junit.Assert.failNotEquals(Assert.java:645)
2480at org.junit.Assert.assertEquals(Assert.java:441)
2481at org.junit.Assert.assertEquals(Assert.java:510)
2482at
org.apache.maven.surefire.junitcore.pc.ParallelComputerUtilTest.withoutShutdown(ParallelComputerUtilTest.java:956)
{code}
or delta should be increase
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MRESOLVER-262) Provide contextual data in trace data for collector invoked requests
[ https://issues.apache.org/jira/browse/MRESOLVER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552540#comment-17552540 ] ASF GitHub Bot commented on MRESOLVER-262: -- grgrzybek commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151932081 @michael-o sorry for holding the release - I added my approval earlier ;) > Provide contextual data in trace data for collector invoked requests > > > Key: MRESOLVER-262 > URL: https://issues.apache.org/jira/browse/MRESOLVER-262 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 1.8.1 > > > During collection several RepositoryEvents are fired, but they does not carry > any context related data regarding artifact collection. > Simplest solution would be to extend RequestTrace to provide: > * request context > * the artifact path (from root to leaf) > * leaf artifact being collected -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-resolver] grgrzybek commented on pull request #182: [MRESOLVER-262] Provide contextual data in trace during collect
grgrzybek commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151932081 @michael-o sorry for holding the release - I added my approval earlier ;) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] dependabot[bot] merged pull request #541: Bump assertj-core from 3.22.0 to 3.23.1
dependabot[bot] merged PR #541: URL: https://github.com/apache/maven-surefire/pull/541 -- 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-filtering] olamy commented on a diff in pull request #38: [MSHARED-1080] Parent POM 36, Java8, drop legacy.
olamy commented on code in PR #38: URL: https://github.com/apache/maven-filtering/pull/38#discussion_r894089757 ## src/main/java/org/apache/maven/shared/filtering/DefaultMavenFileFilter.java: ## @@ -105,8 +110,6 @@ public void copyFile( File from, File to, boolean filtering, List
[GitHub] [maven-surefire] Tibor17 commented on pull request #545: [SUREFIRE-2095] Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true when run with failsafe
Tibor17 commented on PR #545: URL: https://github.com/apache/maven-surefire/pull/545#issuecomment-1151747378 @br0nstein Thx for the fix in the verifier mojo. I admit the commit [6e60b03](https://github.com/apache/maven-surefire/commit/6e60b0389814d8361e453092d3b18f52c3e4bcb1) was not done so well. The situation with XML reports is even more complicated if you have `forkCount` greater than `1`. Additionally, I think we touched the discussion with the non-zero exit where the exit on-jvm-startup is different situation from on-test-run-jvm. Let's continue and discuss it on tomorrow. -- 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] (MNGSITE-485) Expired signature in provided KEYS file on the download page
[
https://issues.apache.org/jira/browse/MNGSITE-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552451#comment-17552451
]
Baiyang Li commented on MNGSITE-485:
Hey Osipov,
Sorry for the delay, I still meet an issue when I run above steps. The error is
shown as below.
{code:java}
gpg: Good signature from "Michael Osipov (Java developer) <1983-01...@gmx.net>"
[unknown]
gpg: aka "Michael Osipov " [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the
owner.{code}
May I know do you meet this error on your side as well?
Thanks.
> Expired signature in provided KEYS file on the download page
>
>
> Key: MNGSITE-485
> URL: https://issues.apache.org/jira/browse/MNGSITE-485
> Project: Maven Project Web Site
> Issue Type: Bug
>Reporter: Baiyang Li
>Assignee: Michael Osipov
>Priority: Major
>
> Hey,
> I met the same expired signature issue described in this close
> [issue|https://issues.apache.org/jira/browse/MNGSITE-458?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel&focusedCommentId=17410236#comment-17410236].
> When i follow the procedure to verify the signature using the KEYS file, both
> provided on the maven's download page::
> * KEYS file import: gpg --import KEYS
> * signature verification; gpg --verify .\apache-maven-3.8.2-bin.tar.gz.asc
> .\apache-maven-3.8.2-bin.tar.gz
> I've got the following message at the second step:
> gpg: Good signature from "Michael Osipov (Java developer)
> <1983-01...@gmx.net>" [expired]
> gpg: aka "Michael Osipov " [expired]
> gpg: Note: This key has expired!
> According to the same procedure: "A signature is valid, if gpg verifies the
> .asc as a good signature, and doesn't complain about expired or revoked
> keys", so, technically, the signature is not valid.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-surefire] Tibor17 closed pull request #531: [SUREFIRE-2082] - Close file handles asap to prevent breaching the system's maximum number of open files
Tibor17 closed pull request #531: [SUREFIRE-2082] - Close file handles asap to prevent breaching the system's maximum number of open files URL: https://github.com/apache/maven-surefire/pull/531 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #531: [SUREFIRE-2082] - Close file handles asap to prevent breaching the system's maximum number of open files
Tibor17 commented on PR #531: URL: https://github.com/apache/maven-surefire/pull/531#issuecomment-1151644647 @sman-81 Thx for contributing anyway! T -- 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] (SUREFIRE-2082) Huge test sets may open too many files
[
https://issues.apache.org/jira/browse/SUREFIRE-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-2082.
--
Resolution: Fixed
https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=d51e7c958a4f93876fafd23d12db0e1c686ec10a
> Huge test sets may open too many files
> --
>
> Key: SUREFIRE-2082
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2082
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M6
>Reporter: Markus Spann
>Assignee: Tibor Digana
>Priority: Major
> Labels: patch, performance, pull-request-available
> Fix For: 3.0.0-M8
>
>
> Test sets with a very large number of tests (such as a JUnit
> {{ParameterizedTest}} with a large number of test inputs) cause surefire to
> open a file for _stdout_ and another file for _stderr_ as soon as a test
> method prints to either of these output streams.
> Surefire captures _stdout_ and _stderr_ in temporary files.
> These file handles are kept until the very end of the test set
> ({{{}TestSetRunListener.testSetCompleted{}}}) which may cause the limit of
> open files to be reached on a system, resulting in test errors
> ({{{}java.nio.file.FileSystemException{}}}, too many open files).
> This behavior may have been introduced with the performance improvements of
> SUREFIRE-1845.
> To reproduce, set the maximum allowed open files to a value lower than test
> iterations in a test class:
> {{ulimit -n }}
> where {{limit}} is the maximum number of open files for a user (Linux).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-surefire] Tibor17 merged pull request #534: [SUREFIRE-2082] Close file handles asap to prevent breaching the system's maximum number of open files
Tibor17 merged PR #534: URL: https://github.com/apache/maven-surefire/pull/534 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (SUREFIRE-2082) Huge test sets may open too many files
[
https://issues.apache.org/jira/browse/SUREFIRE-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-2082:
---
Fix Version/s: 3.0.0-M8
> Huge test sets may open too many files
> --
>
> Key: SUREFIRE-2082
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2082
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M6
>Reporter: Markus Spann
>Assignee: Tibor Digana
>Priority: Major
> Labels: patch, performance, pull-request-available
> Fix For: 3.0.0-M8
>
>
> Test sets with a very large number of tests (such as a JUnit
> {{ParameterizedTest}} with a large number of test inputs) cause surefire to
> open a file for _stdout_ and another file for _stderr_ as soon as a test
> method prints to either of these output streams.
> Surefire captures _stdout_ and _stderr_ in temporary files.
> These file handles are kept until the very end of the test set
> ({{{}TestSetRunListener.testSetCompleted{}}}) which may cause the limit of
> open files to be reached on a system, resulting in test errors
> ({{{}java.nio.file.FileSystemException{}}}, too many open files).
> This behavior may have been introduced with the performance improvements of
> SUREFIRE-1845.
> To reproduce, set the maximum allowed open files to a value lower than test
> iterations in a test class:
> {{ulimit -n }}
> where {{limit}} is the maximum number of open files for a user (Linux).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (SUREFIRE-2082) Huge test sets may open too many files
[
https://issues.apache.org/jira/browse/SUREFIRE-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned SUREFIRE-2082:
--
Assignee: Tibor Digana
> Huge test sets may open too many files
> --
>
> Key: SUREFIRE-2082
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2082
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0-M6
>Reporter: Markus Spann
>Assignee: Tibor Digana
>Priority: Major
> Labels: patch, performance, pull-request-available
>
> Test sets with a very large number of tests (such as a JUnit
> {{ParameterizedTest}} with a large number of test inputs) cause surefire to
> open a file for _stdout_ and another file for _stderr_ as soon as a test
> method prints to either of these output streams.
> Surefire captures _stdout_ and _stderr_ in temporary files.
> These file handles are kept until the very end of the test set
> ({{{}TestSetRunListener.testSetCompleted{}}}) which may cause the limit of
> open files to be reached on a system, resulting in test errors
> ({{{}java.nio.file.FileSystemException{}}}, too many open files).
> This behavior may have been introduced with the performance improvements of
> SUREFIRE-1845.
> To reproduce, set the maximum allowed open files to a value lower than test
> iterations in a test class:
> {{ulimit -n }}
> where {{limit}} is the maximum number of open files for a user (Linux).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-indexer] cstamas commented on pull request #216: Bail out from Jenkins
cstamas commented on PR #216: URL: https://github.com/apache/maven-indexer/pull/216#issuecomment-1151546891 @slawekjaranowski thanks for chiming in with meaningful information, hence, am closing this for 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-indexer] cstamas closed pull request #216: Bail out from Jenkins
cstamas closed pull request #216: Bail out from Jenkins URL: https://github.com/apache/maven-indexer/pull/216 -- 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-262) Provide contextual data in trace data for collector invoked requests
[ https://issues.apache.org/jira/browse/MRESOLVER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552399#comment-17552399 ] Hudson commented on MRESOLVER-262: -- Build succeeded in Jenkins: Maven » Maven TLP » maven-resolver » master #35 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-resolver/job/master/35/ > Provide contextual data in trace data for collector invoked requests > > > Key: MRESOLVER-262 > URL: https://issues.apache.org/jira/browse/MRESOLVER-262 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 1.8.1 > > > During collection several RepositoryEvents are fired, but they does not carry > any context related data regarding artifact collection. > Simplest solution would be to extend RequestTrace to provide: > * request context > * the artifact path (from root to leaf) > * leaf artifact being collected -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (MRESOLVER-262) Provide contextual data in trace data for collector invoked requests
[ https://issues.apache.org/jira/browse/MRESOLVER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák closed MRESOLVER-262. - Assignee: Tamás Cservenák > Provide contextual data in trace data for collector invoked requests > > > Key: MRESOLVER-262 > URL: https://issues.apache.org/jira/browse/MRESOLVER-262 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 1.8.1 > > > During collection several RepositoryEvents are fired, but they does not carry > any context related data regarding artifact collection. > Simplest solution would be to extend RequestTrace to provide: > * request context > * the artifact path (from root to leaf) > * leaf artifact being collected -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (MRESOLVER-262) Provide contextual data in trace data for collector invoked requests
[ https://issues.apache.org/jira/browse/MRESOLVER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák resolved MRESOLVER-262. --- Resolution: Fixed > Provide contextual data in trace data for collector invoked requests > > > Key: MRESOLVER-262 > URL: https://issues.apache.org/jira/browse/MRESOLVER-262 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Priority: Major > Fix For: 1.8.1 > > > During collection several RepositoryEvents are fired, but they does not carry > any context related data regarding artifact collection. > Simplest solution would be to extend RequestTrace to provide: > * request context > * the artifact path (from root to leaf) > * leaf artifact being collected -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MRESOLVER-262) Provide contextual data in trace data for collector invoked requests
[ https://issues.apache.org/jira/browse/MRESOLVER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552397#comment-17552397 ] ASF GitHub Bot commented on MRESOLVER-262: -- cstamas merged PR #182: URL: https://github.com/apache/maven-resolver/pull/182 > Provide contextual data in trace data for collector invoked requests > > > Key: MRESOLVER-262 > URL: https://issues.apache.org/jira/browse/MRESOLVER-262 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Priority: Major > Fix For: 1.8.1 > > > During collection several RepositoryEvents are fired, but they does not carry > any context related data regarding artifact collection. > Simplest solution would be to extend RequestTrace to provide: > * request context > * the artifact path (from root to leaf) > * leaf artifact being collected -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-resolver] cstamas merged pull request #182: [MRESOLVER-262] Provide contextual data in trace during collect
cstamas merged PR #182: URL: https://github.com/apache/maven-resolver/pull/182 -- 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-262) Provide contextual data in trace data for collector invoked requests
[ https://issues.apache.org/jira/browse/MRESOLVER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552391#comment-17552391 ] ASF GitHub Bot commented on MRESOLVER-262: -- michael-o commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151506806 @grgrzybek can we merge this? > Provide contextual data in trace data for collector invoked requests > > > Key: MRESOLVER-262 > URL: https://issues.apache.org/jira/browse/MRESOLVER-262 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Priority: Major > Fix For: 1.8.1 > > > During collection several RepositoryEvents are fired, but they does not carry > any context related data regarding artifact collection. > Simplest solution would be to extend RequestTrace to provide: > * request context > * the artifact path (from root to leaf) > * leaf artifact being collected -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-resolver] michael-o commented on pull request #182: [MRESOLVER-262] Provide contextual data in trace during collect
michael-o commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151506806 @grgrzybek can we merge 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
[jira] [Updated] (MRESOURCES-287) Symlink resource copy fails if symlink target does not exist.
[
https://issues.apache.org/jira/browse/MRESOURCES-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Dunagan updated MRESOURCES-287:
Description:
This problem occurs when symlink file resources are copied in such an order
whereby the symlink file is attempted to be copied prior to the related target
file being copied. The root cause appears to be a change in MRP 3.2.0 where it
attempts to set permissions on the symlink (and thus the target file) and this
fails. I believe this is related to a change introduced as part of a bug fix in
in the MRP 3.2.0 release: MRESOURCES-236.
An example stack track trace excerpt as the issue is encountered as the symlink
file is being copied to its destination and the symlink's target file is not
yet in place:
{code:java}
Caused by: java.nio.file.NoSuchFileException: [full path to file name] at
sun.nio.fs.UnixException.translateToIOException (UnixException.java:92) at
sun.nio.fs.UnixException.rethrowAsIOException (UnixException.java:111) at
sun.nio.fs.UnixException.rethrowAsIOException (UnixException.java:116) at
sun.nio.fs.UnixFileAttributeViews$Posix.setMode
(UnixFileAttributeViews.java:254) at
sun.nio.fs.UnixFileAttributeViews$Posix.setPermissions
(UnixFileAttributeViews.java:276) at
java.nio.file.Files.setPosixFilePermissions (Files.java:2080) at
org.apache.maven.shared.utils.io.FileUtils.copyFilePermissions
(FileUtils.java:1997) at
org.apache.maven.shared.utils.io.FileUtils.copyFile (FileUtils.java:1978)
at org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile
(DefaultMavenFileFilter.java:106) at
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources
(DefaultMavenResourcesFiltering.java:262) at
org.apache.maven.plugins.resources.ResourcesMojo.execute
(ResourcesMojo.java:356) {code}
was:
This problem occurs when symlink file resources are copied in such an order
whereby the symlink file is attempted to be copied prior to the related target
file being copied. The root cause appears to be a change in MRP 3.2.0 where it
attempts to set permissions on the symlink (and thus the target file) and this
fails. I believe this is related to a change introduced as part of a bug fix in
in the MRP 3.2.0 release: MRESOURCES-236.
An example stack track trace excerpt as the issue is encountered as the symlink
file is being copied to its destination and the symlink's target file is not
yet in place:
{noformat}
Caused by: java.nio.file.NoSuchFileException: [full path to file name] at
sun.nio.fs.UnixException.translateToIOException (UnixException.java:92) at
sun.nio.fs.UnixException.rethrowAsIOException (UnixException.java:111) at
sun.nio.fs.UnixException.rethrowAsIOException (UnixException.java:116) at
sun.nio.fs.UnixFileAttributeViews$Posix.setMode
(UnixFileAttributeViews.java:254) at
sun.nio.fs.UnixFileAttributeViews$Posix.setPermissions
(UnixFileAttributeViews.java:276) at
java.nio.file.Files.setPosixFilePermissions (Files.java:2080) at
org.apache.maven.shared.utils.io.FileUtils.copyFilePermissions
(FileUtils.java:1997) at
org.apache.maven.shared.utils.io.FileUtils.copyFile (FileUtils.java:1978)
at org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile
(DefaultMavenFileFilter.java:106) at
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources
(DefaultMavenResourcesFiltering.java:262) at
org.apache.maven.plugins.resources.ResourcesMojo.execute
(ResourcesMojo.java:356){noformat}
> Symlink resource copy fails if symlink target does not exist.
> -
>
> Key: MRESOURCES-287
> URL: https://issues.apache.org/jira/browse/MRESOURCES-287
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: copy
>Affects Versions: 3.2.0
>Reporter: Todd Dunagan
>Priority: Major
>
> This problem occurs when symlink file resources are copied in such an order
> whereby the symlink file is attempted to be copied prior to the related
> target file being copied. The root cause appears to be a change in MRP 3.2.0
> where it attempts to set permissions on the symlink (and thus the target
> file) and this fails. I believe this is related to a change introduced as
> part of a bug fix in in the MRP 3.2.0 release: MRESOURCES-236.
> An example stack track trace excerpt as the issue is encountered as the
> symlink file is being copied to its destination and the symlink's target file
> is not yet in place:
> {code:java}
> Caused by: java.nio.file.NoSuchFileException: [full path to file name] at
> sun.nio.fs.UnixException.translateToIOException (UnixException.java:92)
> at sun.nio.fs.UnixException.rethrowAsIOException (UnixException.java:111)
> at sun.
[jira] [Created] (MRESOURCES-287) Symlink resource copy fails if symlink target does not exist.
Todd Dunagan created MRESOURCES-287:
---
Summary: Symlink resource copy fails if symlink target does not
exist.
Key: MRESOURCES-287
URL: https://issues.apache.org/jira/browse/MRESOURCES-287
Project: Maven Resources Plugin
Issue Type: Bug
Components: copy
Affects Versions: 3.2.0
Reporter: Todd Dunagan
This problem occurs when symlink file resources are copied in such an order
whereby the symlink file is attempted to be copied prior to the related target
file being copied. The root cause appears to be a change in MRP 3.2.0 where it
attempts to set permissions on the symlink (and thus the target file) and this
fails. I believe this is related to a change introduced as part of a bug fix in
in the MRP 3.2.0 release: MRESOURCES-236.
An example stack track trace excerpt as the issue is encountered as the symlink
file is being copied to its destination and the symlink's target file is not
yet in place:
{noformat}
Caused by: java.nio.file.NoSuchFileException: [full path to file name] at
sun.nio.fs.UnixException.translateToIOException (UnixException.java:92) at
sun.nio.fs.UnixException.rethrowAsIOException (UnixException.java:111) at
sun.nio.fs.UnixException.rethrowAsIOException (UnixException.java:116) at
sun.nio.fs.UnixFileAttributeViews$Posix.setMode
(UnixFileAttributeViews.java:254) at
sun.nio.fs.UnixFileAttributeViews$Posix.setPermissions
(UnixFileAttributeViews.java:276) at
java.nio.file.Files.setPosixFilePermissions (Files.java:2080) at
org.apache.maven.shared.utils.io.FileUtils.copyFilePermissions
(FileUtils.java:1997) at
org.apache.maven.shared.utils.io.FileUtils.copyFile (FileUtils.java:1978)
at org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile
(DefaultMavenFileFilter.java:106) at
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources
(DefaultMavenResourcesFiltering.java:262) at
org.apache.maven.plugins.resources.ResourcesMojo.execute
(ResourcesMojo.java:356){noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Closed] (MSHADE-421) Shade plugin with latest Spring Boot 2.7.0 breaks actuator endpoints
[ https://issues.apache.org/jira/browse/MSHADE-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MSHADE-421. -- Resolution: Not A Bug > Shade plugin with latest Spring Boot 2.7.0 breaks actuator endpoints > > > Key: MSHADE-421 > URL: https://issues.apache.org/jira/browse/MSHADE-421 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 3.3.0 > Environment: Java 17, Maven 3.8.4 >Reporter: Florian Eberle >Priority: Major > > I am using Java 17 and the latest maven shade plugin in version 3.3.0. While > upgrading to the latest Spring Boot Version 2.7.0 maven shade seems to build > the jar incorrectly. > When running this jar, the actuator endpoints is not reachable anymore. I > have no clue what is causing this issue and appreciate any help. > > Please have a look at a small demo I created which visualizes the problem. > > [https://github.com/FloEberle/demo-spring-boot-maven-shade-actuator-endpoints-broken] > > To be transparent: since I am unsure where the issue is originating from I > also opened an > [issue|https://github.com/spring-projects/spring-boot/issues/31316] in the > spring boot project. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MSHADE-421) Shade plugin with latest Spring Boot 2.7.0 breaks actuator endpoints
[ https://issues.apache.org/jira/browse/MSHADE-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552316#comment-17552316 ] Phillip Webb commented on MSHADE-421: - This is an issue with the configuration, there's no bug in the shade plugin. We have a Spring Boot issue to improve things on our side (https://github.com/spring-projects/spring-boot/issues/31316). I think this issue can be closed. > Shade plugin with latest Spring Boot 2.7.0 breaks actuator endpoints > > > Key: MSHADE-421 > URL: https://issues.apache.org/jira/browse/MSHADE-421 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 3.3.0 > Environment: Java 17, Maven 3.8.4 >Reporter: Florian Eberle >Priority: Major > > I am using Java 17 and the latest maven shade plugin in version 3.3.0. While > upgrading to the latest Spring Boot Version 2.7.0 maven shade seems to build > the jar incorrectly. > When running this jar, the actuator endpoints is not reachable anymore. I > have no clue what is causing this issue and appreciate any help. > > Please have a look at a small demo I created which visualizes the problem. > > [https://github.com/FloEberle/demo-spring-boot-maven-shade-actuator-endpoints-broken] > > To be transparent: since I am unsure where the issue is originating from I > also opened an > [issue|https://github.com/spring-projects/spring-boot/issues/31316] in the > spring boot project. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MDEPLOY-293) Maven deploy fails with 401 Unauthorized when using £ in password
[
https://issues.apache.org/jira/browse/MDEPLOY-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552313#comment-17552313
]
Michael Osipov commented on MDEPLOY-293:
I will try this at my end as well. Truly strange...
> Maven deploy fails with 401 Unauthorized when using £ in password
> -
>
> Key: MDEPLOY-293
> URL: https://issues.apache.org/jira/browse/MDEPLOY-293
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Nélson Cunha
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: image-2022-06-08-20-06-39-388.png,
> image-2022-06-08-20-09-57-536.png, image-2022-06-09-16-52-04-876.png,
> image-2022-06-09-16-52-19-905.png, image-2022-06-09-17-01-18-568.png
>
>
> Hello.
> I'm using Apache Maven 3.6.3 and maven-deploy-plugin 2.8.2 on Oracle's Java
> version 1.8.0_321 and I'm currently receiving the 401 Unauthorized error
> when deploying an artifact to Sonatype Nexus:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on
> project XXX: Failed to deploy artifacts: Could not transfer artifact
> XXX:XXX:pom:4.0.0-20220608.184337-1 from/to nexus-snapshots
> (http://.../repository/maven-snapshots/): Transfer failed for
> http://...-4.0.0-20220608.184337-1.pom 401 Unauthorized -> [Help 1]{noformat}
>
> This error showed up after I changed my password with a leading {{£}}
> character.
>
> Using Wireshark to capture the HTTP packages exchanged between the maven
> client and the nexus repository, I see 3 interactions:
> # unauthenticated GET request for a maven-metadata.xml file, followed by a
> 401 response
> # authenticated GET request for the same maven-metadata.xml file, followed
> by a 404 response
> # authenticated PUT request for the pom file, followed by a 401 response
>
> Now, analyzing the headers for the second and third request I noticed the
> base64 on the Authentication header is not the same.
> * 2nd request: GET metadata
> !image-2022-06-08-20-06-39-388.png!
>
> * 3rd request PUT pom
> !image-2022-06-08-20-09-57-536.png!
>
> The decoded base64 with the username:password, shows that, as expected, the
> request that received a 404 holds the right password, but on the other hand,
> the PUT request that got a 401 has a password with a {{?}} for the {{{}£{}}}.
>
> All the servers on my {{settings.xml}} hold the same user/password and I have
> tried with the passwords encoded and in plain text.
>
>
> Further tests with base64 encoding and decoding showed that the "wrong"
> password is the actual password but encoded from an ANSI code page where the
> password accepted by Nexus is encoded from utf8.
>
> I noticed the 401 responses don't specify the encoding on the
> {{WWW-Authenticate}} header, which should clear up which encoding to use, but
> still for some reason the two requests are apparently using different
> encodings.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MDEPLOY-293) Maven deploy fails with 401 Unauthorized when using £ in password
[
https://issues.apache.org/jira/browse/MDEPLOY-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552312#comment-17552312
]
Michael Osipov commented on MDEPLOY-293:
Truly interesting: Please run Maven with
{{-Dorg.slf4j.simpleLogger.log.org.apache.maven.wagon.providers.http.httpclient=debug}}
and share the output. This issue has been addressed quite some time ago:
https://github.com/apache/maven-wagon/blob/8e5a4b698b77b5272405a1678ef87e24aba2f4a2/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L527-L532
> Maven deploy fails with 401 Unauthorized when using £ in password
> -
>
> Key: MDEPLOY-293
> URL: https://issues.apache.org/jira/browse/MDEPLOY-293
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Nélson Cunha
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: image-2022-06-08-20-06-39-388.png,
> image-2022-06-08-20-09-57-536.png, image-2022-06-09-16-52-04-876.png,
> image-2022-06-09-16-52-19-905.png, image-2022-06-09-17-01-18-568.png
>
>
> Hello.
> I'm using Apache Maven 3.6.3 and maven-deploy-plugin 2.8.2 on Oracle's Java
> version 1.8.0_321 and I'm currently receiving the 401 Unauthorized error
> when deploying an artifact to Sonatype Nexus:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on
> project XXX: Failed to deploy artifacts: Could not transfer artifact
> XXX:XXX:pom:4.0.0-20220608.184337-1 from/to nexus-snapshots
> (http://.../repository/maven-snapshots/): Transfer failed for
> http://...-4.0.0-20220608.184337-1.pom 401 Unauthorized -> [Help 1]{noformat}
>
> This error showed up after I changed my password with a leading {{£}}
> character.
>
> Using Wireshark to capture the HTTP packages exchanged between the maven
> client and the nexus repository, I see 3 interactions:
> # unauthenticated GET request for a maven-metadata.xml file, followed by a
> 401 response
> # authenticated GET request for the same maven-metadata.xml file, followed
> by a 404 response
> # authenticated PUT request for the pom file, followed by a 401 response
>
> Now, analyzing the headers for the second and third request I noticed the
> base64 on the Authentication header is not the same.
> * 2nd request: GET metadata
> !image-2022-06-08-20-06-39-388.png!
>
> * 3rd request PUT pom
> !image-2022-06-08-20-09-57-536.png!
>
> The decoded base64 with the username:password, shows that, as expected, the
> request that received a 404 holds the right password, but on the other hand,
> the PUT request that got a 401 has a password with a {{?}} for the {{{}£{}}}.
>
> All the servers on my {{settings.xml}} hold the same user/password and I have
> tried with the passwords encoded and in plain text.
>
>
> Further tests with base64 encoding and decoding showed that the "wrong"
> password is the actual password but encoded from an ANSI code page where the
> password accepted by Nexus is encoded from utf8.
>
> I noticed the 401 responses don't specify the encoding on the
> {{WWW-Authenticate}} header, which should clear up which encoding to use, but
> still for some reason the two requests are apparently using different
> encodings.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MDEPLOY-293) Maven deploy fails with 401 Unauthorized when using £ in password
[
https://issues.apache.org/jira/browse/MDEPLOY-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552310#comment-17552310
]
Slawomir Jaranowski commented on MDEPLOY-293:
-
Please also try with {{maven-deploy-plugin}} in the latest version {{3.0.0-M2}}
> Maven deploy fails with 401 Unauthorized when using £ in password
> -
>
> Key: MDEPLOY-293
> URL: https://issues.apache.org/jira/browse/MDEPLOY-293
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Nélson Cunha
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: image-2022-06-08-20-06-39-388.png,
> image-2022-06-08-20-09-57-536.png, image-2022-06-09-16-52-04-876.png,
> image-2022-06-09-16-52-19-905.png, image-2022-06-09-17-01-18-568.png
>
>
> Hello.
> I'm using Apache Maven 3.6.3 and maven-deploy-plugin 2.8.2 on Oracle's Java
> version 1.8.0_321 and I'm currently receiving the 401 Unauthorized error
> when deploying an artifact to Sonatype Nexus:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on
> project XXX: Failed to deploy artifacts: Could not transfer artifact
> XXX:XXX:pom:4.0.0-20220608.184337-1 from/to nexus-snapshots
> (http://.../repository/maven-snapshots/): Transfer failed for
> http://...-4.0.0-20220608.184337-1.pom 401 Unauthorized -> [Help 1]{noformat}
>
> This error showed up after I changed my password with a leading {{£}}
> character.
>
> Using Wireshark to capture the HTTP packages exchanged between the maven
> client and the nexus repository, I see 3 interactions:
> # unauthenticated GET request for a maven-metadata.xml file, followed by a
> 401 response
> # authenticated GET request for the same maven-metadata.xml file, followed
> by a 404 response
> # authenticated PUT request for the pom file, followed by a 401 response
>
> Now, analyzing the headers for the second and third request I noticed the
> base64 on the Authentication header is not the same.
> * 2nd request: GET metadata
> !image-2022-06-08-20-06-39-388.png!
>
> * 3rd request PUT pom
> !image-2022-06-08-20-09-57-536.png!
>
> The decoded base64 with the username:password, shows that, as expected, the
> request that received a 404 holds the right password, but on the other hand,
> the PUT request that got a 401 has a password with a {{?}} for the {{{}£{}}}.
>
> All the servers on my {{settings.xml}} hold the same user/password and I have
> tried with the passwords encoded and in plain text.
>
>
> Further tests with base64 encoding and decoding showed that the "wrong"
> password is the actual password but encoded from an ANSI code page where the
> password accepted by Nexus is encoded from utf8.
>
> I noticed the 401 responses don't specify the encoding on the
> {{WWW-Authenticate}} header, which should clear up which encoding to use, but
> still for some reason the two requests are apparently using different
> encodings.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MSHADE-421) Shade plugin with latest Spring Boot 2.7.0 breaks actuator endpoints
[
https://issues.apache.org/jira/browse/MSHADE-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552294#comment-17552294
]
Slawomir Jaranowski commented on MSHADE-421:
Why not simply use {{spring-boot-maven-plugin:repackage}}
https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/htmlsingle/#packaging
What additional feature from {{m-shade-p}} you need for your case?
> Shade plugin with latest Spring Boot 2.7.0 breaks actuator endpoints
>
>
> Key: MSHADE-421
> URL: https://issues.apache.org/jira/browse/MSHADE-421
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.3.0
> Environment: Java 17, Maven 3.8.4
>Reporter: Florian Eberle
>Priority: Major
>
> I am using Java 17 and the latest maven shade plugin in version 3.3.0. While
> upgrading to the latest Spring Boot Version 2.7.0 maven shade seems to build
> the jar incorrectly.
> When running this jar, the actuator endpoints is not reachable anymore. I
> have no clue what is causing this issue and appreciate any help.
>
> Please have a look at a small demo I created which visualizes the problem.
>
> [https://github.com/FloEberle/demo-spring-boot-maven-shade-actuator-endpoints-broken]
>
> To be transparent: since I am unsure where the issue is originating from I
> also opened an
> [issue|https://github.com/spring-projects/spring-boot/issues/31316] in the
> spring boot project.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MSHADE-421) Shade plugin with latest Spring Boot 2.7.0 breaks actuator endpoints
[ https://issues.apache.org/jira/browse/MSHADE-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Eberle updated MSHADE-421: -- Description: I am using Java 17 and the latest maven shade plugin in version 3.3.0. While upgrading to the latest Spring Boot Version 2.7.0 maven shade seems to build the jar incorrectly. When running this jar, the actuator endpoints is not reachable anymore. I have no clue what is causing this issue and appreciate any help. Please have a look at a small demo I created which visualizes the problem. [https://github.com/FloEberle/demo-spring-boot-maven-shade-actuator-endpoints-broken] To be transparent: since I am unsure where the issue is originating from I also opened an [issue|https://github.com/spring-projects/spring-boot/issues/31316] in the spring boot project. was: I am using Java 17 and the latest maven shade plugin in version 3.3.0. While upgrading to the latest Spring Boot Version 2.7.0 maven shade seems to build the jar incorrectly. When running this jar, the actuator endpoints is not reachable anymore. I have no clue what is causing this issue and appreciate any help. Please have a look at a small demo I created which visualizes the problem. [https://github.com/FloEberle/demo-spring-boot-maven-shade-actuator-endpoints-broken] > Shade plugin with latest Spring Boot 2.7.0 breaks actuator endpoints > > > Key: MSHADE-421 > URL: https://issues.apache.org/jira/browse/MSHADE-421 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 3.3.0 > Environment: Java 17, Maven 3.8.4 >Reporter: Florian Eberle >Priority: Major > > I am using Java 17 and the latest maven shade plugin in version 3.3.0. While > upgrading to the latest Spring Boot Version 2.7.0 maven shade seems to build > the jar incorrectly. > When running this jar, the actuator endpoints is not reachable anymore. I > have no clue what is causing this issue and appreciate any help. > > Please have a look at a small demo I created which visualizes the problem. > > [https://github.com/FloEberle/demo-spring-boot-maven-shade-actuator-endpoints-broken] > > To be transparent: since I am unsure where the issue is originating from I > also opened an > [issue|https://github.com/spring-projects/spring-boot/issues/31316] in the > spring boot project. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (MDEPLOY-293) Maven deploy fails with 401 Unauthorized when using £ in password
[
https://issues.apache.org/jira/browse/MDEPLOY-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552285#comment-17552285
]
Nélson Cunha edited comment on MDEPLOY-293 at 6/9/22 4:02 PM:
--
Hello.
I changed my password to: {{£Password1}} and here are the screenshots, as
requested:
* 2nd request, authenticated GET with the correct password ({{{}Basic
bmN1bmhhOsKjUGFzc3dvcmQx{}}}):
!image-2022-06-09-16-52-04-876.png!
* 3rd request, authenticated PUT with the wrong password ({{{}Basic
bmN1bmhhOj9QYXNzd29yZDE={}}});
!image-2022-06-09-17-01-18-568.png!
was (Author: JIRAUSER290677):
Hello.
I changed my password to: {{£Password1}} and here are the screenshots, as
requested:
* 2nd request, authenticated GET with the correct password ({{{}Basic
bmN1bmhhOsKjUGFzc3dvcmQx{}}}):
!image-2022-06-09-16-52-04-876.png!
* 3rd request, authenticated PUT with the wrong password ({{{}Basic
bmN1bmhhOj9QYXNzd29yZDE={}}});
!image-2022-06-09-16-52-19-905.png!
> Maven deploy fails with 401 Unauthorized when using £ in password
> -
>
> Key: MDEPLOY-293
> URL: https://issues.apache.org/jira/browse/MDEPLOY-293
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Nélson Cunha
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: image-2022-06-08-20-06-39-388.png,
> image-2022-06-08-20-09-57-536.png, image-2022-06-09-16-52-04-876.png,
> image-2022-06-09-16-52-19-905.png, image-2022-06-09-17-01-18-568.png
>
>
> Hello.
> I'm using Apache Maven 3.6.3 and maven-deploy-plugin 2.8.2 on Oracle's Java
> version 1.8.0_321 and I'm currently receiving the 401 Unauthorized error
> when deploying an artifact to Sonatype Nexus:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on
> project XXX: Failed to deploy artifacts: Could not transfer artifact
> XXX:XXX:pom:4.0.0-20220608.184337-1 from/to nexus-snapshots
> (http://.../repository/maven-snapshots/): Transfer failed for
> http://...-4.0.0-20220608.184337-1.pom 401 Unauthorized -> [Help 1]{noformat}
>
> This error showed up after I changed my password with a leading {{£}}
> character.
>
> Using Wireshark to capture the HTTP packages exchanged between the maven
> client and the nexus repository, I see 3 interactions:
> # unauthenticated GET request for a maven-metadata.xml file, followed by a
> 401 response
> # authenticated GET request for the same maven-metadata.xml file, followed
> by a 404 response
> # authenticated PUT request for the pom file, followed by a 401 response
>
> Now, analyzing the headers for the second and third request I noticed the
> base64 on the Authentication header is not the same.
> * 2nd request: GET metadata
> !image-2022-06-08-20-06-39-388.png!
>
> * 3rd request PUT pom
> !image-2022-06-08-20-09-57-536.png!
>
> The decoded base64 with the username:password, shows that, as expected, the
> request that received a 404 holds the right password, but on the other hand,
> the PUT request that got a 401 has a password with a {{?}} for the {{{}£{}}}.
>
> All the servers on my {{settings.xml}} hold the same user/password and I have
> tried with the passwords encoded and in plain text.
>
>
> Further tests with base64 encoding and decoding showed that the "wrong"
> password is the actual password but encoded from an ANSI code page where the
> password accepted by Nexus is encoded from utf8.
>
> I noticed the 401 responses don't specify the encoding on the
> {{WWW-Authenticate}} header, which should clear up which encoding to use, but
> still for some reason the two requests are apparently using different
> encodings.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (MDEPLOY-293) Maven deploy fails with 401 Unauthorized when using £ in password
[
https://issues.apache.org/jira/browse/MDEPLOY-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552285#comment-17552285
]
Nélson Cunha edited comment on MDEPLOY-293 at 6/9/22 3:58 PM:
--
Hello.
I changed my password to: {{£Password1}} and here are the screenshots, as
requested:
* 2nd request, authenticated GET with the correct password ({{{}Basic
bmN1bmhhOsKjUGFzc3dvcmQx{}}}):
!image-2022-06-09-16-52-04-876.png!
* 3rd request, authenticated PUT with the wrong password ({{{}Basic
bmN1bmhhOj9QYXNzd29yZDE={}}});
!image-2022-06-09-16-52-19-905.png!
was (Author: JIRAUSER290677):
Hello.
I changed my password to: {{£Password1}} and hare are the screenshots as
requested:
* 2nd request, authenticated GET with the correct password:
!image-2022-06-09-16-52-04-876.png!
* 3rd request, authenticated PUT with the wrong password
!image-2022-06-09-16-52-19-905.png!
> Maven deploy fails with 401 Unauthorized when using £ in password
> -
>
> Key: MDEPLOY-293
> URL: https://issues.apache.org/jira/browse/MDEPLOY-293
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Nélson Cunha
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: image-2022-06-08-20-06-39-388.png,
> image-2022-06-08-20-09-57-536.png, image-2022-06-09-16-52-04-876.png,
> image-2022-06-09-16-52-19-905.png
>
>
> Hello.
> I'm using Apache Maven 3.6.3 and maven-deploy-plugin 2.8.2 on Oracle's Java
> version 1.8.0_321 and I'm currently receiving the 401 Unauthorized error
> when deploying an artifact to Sonatype Nexus:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on
> project XXX: Failed to deploy artifacts: Could not transfer artifact
> XXX:XXX:pom:4.0.0-20220608.184337-1 from/to nexus-snapshots
> (http://.../repository/maven-snapshots/): Transfer failed for
> http://...-4.0.0-20220608.184337-1.pom 401 Unauthorized -> [Help 1]{noformat}
>
> This error showed up after I changed my password with a leading {{£}}
> character.
>
> Using Wireshark to capture the HTTP packages exchanged between the maven
> client and the nexus repository, I see 3 interactions:
> # unauthenticated GET request for a maven-metadata.xml file, followed by a
> 401 response
> # authenticated GET request for the same maven-metadata.xml file, followed
> by a 404 response
> # authenticated PUT request for the pom file, followed by a 401 response
>
> Now, analyzing the headers for the second and third request I noticed the
> base64 on the Authentication header is not the same.
> * 2nd request: GET metadata
> !image-2022-06-08-20-06-39-388.png!
>
> * 3rd request PUT pom
> !image-2022-06-08-20-09-57-536.png!
>
> The decoded base64 with the username:password, shows that, as expected, the
> request that received a 404 holds the right password, but on the other hand,
> the PUT request that got a 401 has a password with a {{?}} for the {{{}£{}}}.
>
> All the servers on my {{settings.xml}} hold the same user/password and I have
> tried with the passwords encoded and in plain text.
>
>
> Further tests with base64 encoding and decoding showed that the "wrong"
> password is the actual password but encoded from an ANSI code page where the
> password accepted by Nexus is encoded from utf8.
>
> I noticed the 401 responses don't specify the encoding on the
> {{WWW-Authenticate}} header, which should clear up which encoding to use, but
> still for some reason the two requests are apparently using different
> encodings.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MDEPLOY-293) Maven deploy fails with 401 Unauthorized when using £ in password
[
https://issues.apache.org/jira/browse/MDEPLOY-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552285#comment-17552285
]
Nélson Cunha commented on MDEPLOY-293:
--
Hello.
I changed my password to: {{£Password1}} and hare are the screenshots as
requested:
* 2nd request, authenticated GET with the correct password:
!image-2022-06-09-16-52-04-876.png!
* 3rd request, authenticated PUT with the wrong password
!image-2022-06-09-16-52-19-905.png!
> Maven deploy fails with 401 Unauthorized when using £ in password
> -
>
> Key: MDEPLOY-293
> URL: https://issues.apache.org/jira/browse/MDEPLOY-293
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Nélson Cunha
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: image-2022-06-08-20-06-39-388.png,
> image-2022-06-08-20-09-57-536.png, image-2022-06-09-16-52-04-876.png,
> image-2022-06-09-16-52-19-905.png
>
>
> Hello.
> I'm using Apache Maven 3.6.3 and maven-deploy-plugin 2.8.2 on Oracle's Java
> version 1.8.0_321 and I'm currently receiving the 401 Unauthorized error
> when deploying an artifact to Sonatype Nexus:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on
> project XXX: Failed to deploy artifacts: Could not transfer artifact
> XXX:XXX:pom:4.0.0-20220608.184337-1 from/to nexus-snapshots
> (http://.../repository/maven-snapshots/): Transfer failed for
> http://...-4.0.0-20220608.184337-1.pom 401 Unauthorized -> [Help 1]{noformat}
>
> This error showed up after I changed my password with a leading {{£}}
> character.
>
> Using Wireshark to capture the HTTP packages exchanged between the maven
> client and the nexus repository, I see 3 interactions:
> # unauthenticated GET request for a maven-metadata.xml file, followed by a
> 401 response
> # authenticated GET request for the same maven-metadata.xml file, followed
> by a 404 response
> # authenticated PUT request for the pom file, followed by a 401 response
>
> Now, analyzing the headers for the second and third request I noticed the
> base64 on the Authentication header is not the same.
> * 2nd request: GET metadata
> !image-2022-06-08-20-06-39-388.png!
>
> * 3rd request PUT pom
> !image-2022-06-08-20-09-57-536.png!
>
> The decoded base64 with the username:password, shows that, as expected, the
> request that received a 404 holds the right password, but on the other hand,
> the PUT request that got a 401 has a password with a {{?}} for the {{{}£{}}}.
>
> All the servers on my {{settings.xml}} hold the same user/password and I have
> tried with the passwords encoded and in plain text.
>
>
> Further tests with base64 encoding and decoding showed that the "wrong"
> password is the actual password but encoded from an ANSI code page where the
> password accepted by Nexus is encoded from utf8.
>
> I noticed the 401 responses don't specify the encoding on the
> {{WWW-Authenticate}} header, which should clear up which encoding to use, but
> still for some reason the two requests are apparently using different
> encodings.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MSHADE-421) Shade plugin with latest Spring Boot 2.7.0 breaks actuator endpoints
[ https://issues.apache.org/jira/browse/MSHADE-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Florian Eberle updated MSHADE-421: -- Description: I am using Java 17 and the latest maven shade plugin in version 3.3.0. While upgrading to the latest Spring Boot Version 2.7.0 maven shade seems to build the jar incorrectly. When running this jar, the actuator endpoints is not reachable anymore. I have no clue what is causing this issue and appreciate any help. Please have a look at a small demo I created which visualizes the problem. [https://github.com/FloEberle/demo-spring-boot-maven-shade-actuator-endpoints-broken] was: I am using Java 17 and the latest maven shade plugin in version 3.3.0. While upgrading to the latest Spring Boot Version 2.7.0 maven shade seems to build the jar incorrectly. When running this jar, the actuator endpoints is not reachable anymore. I have no clue what is causing this issue and appreciate any help. Please have a look at a small demo I created which demonstrates the problem. [https://github.com/FloEberle/demo-spring-boot-maven-shade-actuator-endpoints-broken] > Shade plugin with latest Spring Boot 2.7.0 breaks actuator endpoints > > > Key: MSHADE-421 > URL: https://issues.apache.org/jira/browse/MSHADE-421 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 3.3.0 > Environment: Java 17, Maven 3.8.4 >Reporter: Florian Eberle >Priority: Major > > I am using Java 17 and the latest maven shade plugin in version 3.3.0. While > upgrading to the latest Spring Boot Version 2.7.0 maven shade seems to build > the jar incorrectly. > When running this jar, the actuator endpoints is not reachable anymore. I > have no clue what is causing this issue and appreciate any help. > > Please have a look at a small demo I created which visualizes the problem. > > [https://github.com/FloEberle/demo-spring-boot-maven-shade-actuator-endpoints-broken] > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (MDEPLOY-293) Maven deploy fails with 401 Unauthorized when using £ in password
[
https://issues.apache.org/jira/browse/MDEPLOY-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nélson Cunha updated MDEPLOY-293:
-
Attachment: image-2022-06-09-16-52-19-905.png
> Maven deploy fails with 401 Unauthorized when using £ in password
> -
>
> Key: MDEPLOY-293
> URL: https://issues.apache.org/jira/browse/MDEPLOY-293
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Nélson Cunha
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: image-2022-06-08-20-06-39-388.png,
> image-2022-06-08-20-09-57-536.png, image-2022-06-09-16-52-04-876.png,
> image-2022-06-09-16-52-19-905.png
>
>
> Hello.
> I'm using Apache Maven 3.6.3 and maven-deploy-plugin 2.8.2 on Oracle's Java
> version 1.8.0_321 and I'm currently receiving the 401 Unauthorized error
> when deploying an artifact to Sonatype Nexus:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on
> project XXX: Failed to deploy artifacts: Could not transfer artifact
> XXX:XXX:pom:4.0.0-20220608.184337-1 from/to nexus-snapshots
> (http://.../repository/maven-snapshots/): Transfer failed for
> http://...-4.0.0-20220608.184337-1.pom 401 Unauthorized -> [Help 1]{noformat}
>
> This error showed up after I changed my password with a leading {{£}}
> character.
>
> Using Wireshark to capture the HTTP packages exchanged between the maven
> client and the nexus repository, I see 3 interactions:
> # unauthenticated GET request for a maven-metadata.xml file, followed by a
> 401 response
> # authenticated GET request for the same maven-metadata.xml file, followed
> by a 404 response
> # authenticated PUT request for the pom file, followed by a 401 response
>
> Now, analyzing the headers for the second and third request I noticed the
> base64 on the Authentication header is not the same.
> * 2nd request: GET metadata
> !image-2022-06-08-20-06-39-388.png!
>
> * 3rd request PUT pom
> !image-2022-06-08-20-09-57-536.png!
>
> The decoded base64 with the username:password, shows that, as expected, the
> request that received a 404 holds the right password, but on the other hand,
> the PUT request that got a 401 has a password with a {{?}} for the {{{}£{}}}.
>
> All the servers on my {{settings.xml}} hold the same user/password and I have
> tried with the passwords encoded and in plain text.
>
>
> Further tests with base64 encoding and decoding showed that the "wrong"
> password is the actual password but encoded from an ANSI code page where the
> password accepted by Nexus is encoded from utf8.
>
> I noticed the 401 responses don't specify the encoding on the
> {{WWW-Authenticate}} header, which should clear up which encoding to use, but
> still for some reason the two requests are apparently using different
> encodings.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MDEPLOY-293) Maven deploy fails with 401 Unauthorized when using £ in password
[
https://issues.apache.org/jira/browse/MDEPLOY-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nélson Cunha updated MDEPLOY-293:
-
Attachment: image-2022-06-09-16-52-04-876.png
> Maven deploy fails with 401 Unauthorized when using £ in password
> -
>
> Key: MDEPLOY-293
> URL: https://issues.apache.org/jira/browse/MDEPLOY-293
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Nélson Cunha
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: image-2022-06-08-20-06-39-388.png,
> image-2022-06-08-20-09-57-536.png, image-2022-06-09-16-52-04-876.png,
> image-2022-06-09-16-52-19-905.png
>
>
> Hello.
> I'm using Apache Maven 3.6.3 and maven-deploy-plugin 2.8.2 on Oracle's Java
> version 1.8.0_321 and I'm currently receiving the 401 Unauthorized error
> when deploying an artifact to Sonatype Nexus:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on
> project XXX: Failed to deploy artifacts: Could not transfer artifact
> XXX:XXX:pom:4.0.0-20220608.184337-1 from/to nexus-snapshots
> (http://.../repository/maven-snapshots/): Transfer failed for
> http://...-4.0.0-20220608.184337-1.pom 401 Unauthorized -> [Help 1]{noformat}
>
> This error showed up after I changed my password with a leading {{£}}
> character.
>
> Using Wireshark to capture the HTTP packages exchanged between the maven
> client and the nexus repository, I see 3 interactions:
> # unauthenticated GET request for a maven-metadata.xml file, followed by a
> 401 response
> # authenticated GET request for the same maven-metadata.xml file, followed
> by a 404 response
> # authenticated PUT request for the pom file, followed by a 401 response
>
> Now, analyzing the headers for the second and third request I noticed the
> base64 on the Authentication header is not the same.
> * 2nd request: GET metadata
> !image-2022-06-08-20-06-39-388.png!
>
> * 3rd request PUT pom
> !image-2022-06-08-20-09-57-536.png!
>
> The decoded base64 with the username:password, shows that, as expected, the
> request that received a 404 holds the right password, but on the other hand,
> the PUT request that got a 401 has a password with a {{?}} for the {{{}£{}}}.
>
> All the servers on my {{settings.xml}} hold the same user/password and I have
> tried with the passwords encoded and in plain text.
>
>
> Further tests with base64 encoding and decoding showed that the "wrong"
> password is the actual password but encoded from an ANSI code page where the
> password accepted by Nexus is encoded from utf8.
>
> I noticed the 401 responses don't specify the encoding on the
> {{WWW-Authenticate}} header, which should clear up which encoding to use, but
> still for some reason the two requests are apparently using different
> encodings.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (MSHADE-421) Shade plugin with latest Spring Boot 2.7.0 breaks actuator endpoints
Florian Eberle created MSHADE-421: - Summary: Shade plugin with latest Spring Boot 2.7.0 breaks actuator endpoints Key: MSHADE-421 URL: https://issues.apache.org/jira/browse/MSHADE-421 Project: Maven Shade Plugin Issue Type: Bug Affects Versions: 3.3.0 Environment: Java 17, Maven 3.8.4 Reporter: Florian Eberle I am using Java 17 and the latest maven shade plugin in version 3.3.0. While upgrading to the latest Spring Boot Version 2.7.0 maven shade seems to build the jar incorrectly. When running this jar, the actuator endpoints is not reachable anymore. I have no clue what is causing this issue and appreciate any help. Please have a look at a small demo I created which demonstrates the problem. [https://github.com/FloEberle/demo-spring-boot-maven-shade-actuator-endpoints-broken] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-indexer] slawekjaranowski commented on pull request #216: Bail out from Jenkins
slawekjaranowski commented on PR #216: URL: https://github.com/apache/maven-indexer/pull/216#issuecomment-1151255939 There is no issue that you mention - now jenkins check only PR-sha not PR+master sha. So jobs for PR are not triggered after each commit to master. -1 also from me - we have another important task on jenkins - deploy snapshot artifacts -- 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-262) Provide contextual data in trace data for collector invoked requests
[ https://issues.apache.org/jira/browse/MRESOLVER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552260#comment-17552260 ] ASF GitHub Bot commented on MRESOLVER-262: -- michael-o commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151228693 I will do the release > Provide contextual data in trace data for collector invoked requests > > > Key: MRESOLVER-262 > URL: https://issues.apache.org/jira/browse/MRESOLVER-262 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Priority: Major > Fix For: 1.8.1 > > > During collection several RepositoryEvents are fired, but they does not carry > any context related data regarding artifact collection. > Simplest solution would be to extend RequestTrace to provide: > * request context > * the artifact path (from root to leaf) > * leaf artifact being collected -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-resolver] michael-o commented on pull request #182: [MRESOLVER-262] Provide contextual data in trace during collect
michael-o commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151228693 I will do the release -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MSHARED-1081) Drop m-shared-utils from deps
Tamás Cservenák created MSHARED-1081: Summary: Drop m-shared-utils from deps Key: MSHARED-1081 URL: https://issues.apache.org/jira/browse/MSHARED-1081 Project: Maven Shared Components Issue Type: Task Components: maven-archiver Reporter: Tamás Cservenák Fix For: maven-archiver-3.6.0 maven-shared-utils are used for 3 methods, while plexus-utils, commons-io and who knows what is present. Just ditch the maven-shared-utils. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MSHARED-1081) Drop m-shared-utils from deps
[ https://issues.apache.org/jira/browse/MSHARED-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552257#comment-17552257 ] ASF GitHub Bot commented on MSHARED-1081: - cstamas opened a new pull request, #23: URL: https://github.com/apache/maven-archiver/pull/23 Drop m-s-utils --- https://issues.apache.org/jira/browse/MSHARED-1081 > Drop m-shared-utils from deps > - > > Key: MSHARED-1081 > URL: https://issues.apache.org/jira/browse/MSHARED-1081 > Project: Maven Shared Components > Issue Type: Task > Components: maven-archiver >Reporter: Tamás Cservenák >Priority: Major > Fix For: maven-archiver-3.6.0 > > > maven-shared-utils are used for 3 methods, while plexus-utils, commons-io and > who knows what is present. Just ditch the maven-shared-utils. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-archiver] cstamas opened a new pull request, #23: [MSHARED-1081] Drop m-shared-utils
cstamas opened a new pull request, #23: URL: https://github.com/apache/maven-archiver/pull/23 Drop m-s-utils --- https://issues.apache.org/jira/browse/MSHARED-1081 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-indexer] cstamas commented on pull request #216: Bail out from Jenkins
cstamas commented on PR #216: URL: https://github.com/apache/maven-indexer/pull/216#issuecomment-1151181154 @olamy you still stick to your -1 here? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-262) Provide contextual data in trace data for collector invoked requests
[ https://issues.apache.org/jira/browse/MRESOLVER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552246#comment-17552246 ] ASF GitHub Bot commented on MRESOLVER-262: -- cstamas commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151179681 > From my PoV just fine, waiting for @grgrzybek In a moment you nod, am merging this and soon is followed by 1.8.1 release... > Provide contextual data in trace data for collector invoked requests > > > Key: MRESOLVER-262 > URL: https://issues.apache.org/jira/browse/MRESOLVER-262 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Priority: Major > Fix For: 1.8.1 > > > During collection several RepositoryEvents are fired, but they does not carry > any context related data regarding artifact collection. > Simplest solution would be to extend RequestTrace to provide: > * request context > * the artifact path (from root to leaf) > * leaf artifact being collected -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-resolver] cstamas commented on pull request #182: [MRESOLVER-262] Provide contextual data in trace during collect
cstamas commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151179681 > From my PoV just fine, waiting for @grgrzybek In a moment you nod, am merging this and soon is followed by 1.8.1 release... -- 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-262) Provide contextual data in trace data for collector invoked requests
[ https://issues.apache.org/jira/browse/MRESOLVER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552245#comment-17552245 ] ASF GitHub Bot commented on MRESOLVER-262: -- grgrzybek commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151176988 > Yes and yes: this very PR is last bit we waited for to release resolver 1.8.1, and hopefully will go into Maven 3.9.0. Great to hear - thank you very much for your outstanding help! > Provide contextual data in trace data for collector invoked requests > > > Key: MRESOLVER-262 > URL: https://issues.apache.org/jira/browse/MRESOLVER-262 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Priority: Major > Fix For: 1.8.1 > > > During collection several RepositoryEvents are fired, but they does not carry > any context related data regarding artifact collection. > Simplest solution would be to extend RequestTrace to provide: > * request context > * the artifact path (from root to leaf) > * leaf artifact being collected -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-resolver] grgrzybek commented on pull request #182: [MRESOLVER-262] Provide contextual data in trace during collect
grgrzybek commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151176988 > Yes and yes: this very PR is last bit we waited for to release resolver 1.8.1, and hopefully will go into Maven 3.9.0. Great to hear - thank you very much for your outstanding help! -- 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-262) Provide contextual data in trace data for collector invoked requests
[ https://issues.apache.org/jira/browse/MRESOLVER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552243#comment-17552243 ] ASF GitHub Bot commented on MRESOLVER-262: -- cstamas commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151172953 > Will it use maven resolver 1.8.0 or 1.8.1? Any chance this PR will make it into maven-resolver used in Maven 3.9.0? Yes and yes: this is last bit we waited for to release resolver 1.8.1, and hopefully will go into Maven 3.9.0. > Provide contextual data in trace data for collector invoked requests > > > Key: MRESOLVER-262 > URL: https://issues.apache.org/jira/browse/MRESOLVER-262 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Priority: Major > Fix For: 1.8.1 > > > During collection several RepositoryEvents are fired, but they does not carry > any context related data regarding artifact collection. > Simplest solution would be to extend RequestTrace to provide: > * request context > * the artifact path (from root to leaf) > * leaf artifact being collected -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-resolver] cstamas commented on pull request #182: [MRESOLVER-262] Provide contextual data in trace during collect
cstamas commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151172953 > Will it use maven resolver 1.8.0 or 1.8.1? Any chance this PR will make it into maven-resolver used in Maven 3.9.0? Yes and yes: this is last bit we waited for to release resolver 1.8.1, and hopefully will go into Maven 3.9.0. -- 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-262) Provide contextual data in trace data for collector invoked requests
[ https://issues.apache.org/jira/browse/MRESOLVER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552242#comment-17552242 ] ASF GitHub Bot commented on MRESOLVER-262: -- grgrzybek commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151171821 > Btw, Maven 3.9.0 (branch maven-3.9.x) is almost done, should be safe to use as well as you locally build instance for yourself (that's what I use as well when testing stuff). Will it use maven resolver 1.8.0 or 1.8.1? Any chance this PR will make it into maven-resolver used in Maven 3.9.0? > Provide contextual data in trace data for collector invoked requests > > > Key: MRESOLVER-262 > URL: https://issues.apache.org/jira/browse/MRESOLVER-262 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Priority: Major > Fix For: 1.8.1 > > > During collection several RepositoryEvents are fired, but they does not carry > any context related data regarding artifact collection. > Simplest solution would be to extend RequestTrace to provide: > * request context > * the artifact path (from root to leaf) > * leaf artifact being collected -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-resolver] grgrzybek commented on pull request #182: [MRESOLVER-262] Provide contextual data in trace during collect
grgrzybek commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151171821 > Btw, Maven 3.9.0 (branch maven-3.9.x) is almost done, should be safe to use as well as you locally build instance for yourself (that's what I use as well when testing stuff). Will it use maven resolver 1.8.0 or 1.8.1? Any chance this PR will make it into maven-resolver used in Maven 3.9.0? -- 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-262) Provide contextual data in trace data for collector invoked requests
[ https://issues.apache.org/jira/browse/MRESOLVER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552238#comment-17552238 ] ASF GitHub Bot commented on MRESOLVER-262: -- cstamas commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151167650 Btw, Maven 3.9.0 (branch maven-3.9.x) is almost done, should be safe to use as well as you locally build instance for yourself (that's what I use as well when testing stuff). > Provide contextual data in trace data for collector invoked requests > > > Key: MRESOLVER-262 > URL: https://issues.apache.org/jira/browse/MRESOLVER-262 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Priority: Major > Fix For: 1.8.1 > > > During collection several RepositoryEvents are fired, but they does not carry > any context related data regarding artifact collection. > Simplest solution would be to extend RequestTrace to provide: > * request context > * the artifact path (from root to leaf) > * leaf artifact being collected -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-resolver] cstamas commented on pull request #182: [MRESOLVER-262] Provide contextual data in trace during collect
cstamas commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151167650 Btw, Maven 3.9.0 (branch maven-3.9.x) is almost done, should be safe to use as well as you locally build instance for yourself (that's what I use as well when testing stuff). -- 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-262) Provide contextual data in trace data for collector invoked requests
[
https://issues.apache.org/jira/browse/MRESOLVER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552235#comment-17552235
]
ASF GitHub Bot commented on MRESOLVER-262:
--
grgrzybek commented on PR #182:
URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151165431
Similar situation with
`camel-spring-boot-generator-maven-plugin:3.14.2-SNAPSHOT:prepare-spring-boot-starter`:
```
"main@1" prio=5 tid=0x1 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at
org.ops4j.tools.maven.tracker.TrackingRepositoryListener.write(TrackingRepositoryListener.java:130)
at
org.ops4j.tools.maven.tracker.TrackingRepositoryListener.artifactResolved(TrackingRepositoryListener.java:53)
at
org.eclipse.aether.internal.impl.DefaultRepositoryEventDispatcher.dispatch(DefaultRepositoryEventDispatcher.java:136)
at
org.eclipse.aether.internal.impl.DefaultRepositoryEventDispatcher.dispatch(DefaultRepositoryEventDispatcher.java:93)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.artifactResolved(DefaultArtifactResolver.java:673)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:339)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:235)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:212)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:272)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:318)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:299)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:593)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:212)
at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:551)
at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:605)
at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.collect(DefaultLegacyArtifactCollector.java:148)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:504)
at
org.apache.maven.repository.legacy.LegacyRepositorySystem.resolve(LegacyRepositorySystem.java:367)
at
org.apache.maven.DefaultProjectDependenciesResolver.resolveImpl(DefaultProjectDependenciesResolver.java:165)
at
org.apache.maven.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:81)
at
org.apache.maven.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:65)
at
org.apache.camel.springboot.maven.SpringBootStarterMojo.filterIncludedArtifacts(SpringBootStarterMojo.java:306)
at
org.apache.camel.springboot.maven.SpringBootStarterMojo.fixExcludedDependencies(SpringBootStarterMojo.java:265)
at
org.apache.camel.springboot.maven.SpringBootStarterMojo.executeAll(SpringBootStarterMojo.java:114)
at
org.apache.camel.springboot.maven.AbstractSpringBootGenerator.execute(AbstractSpringBootGenerator.java:69)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
...
```
There's
`org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector`
involved and my listener, while called, doesn't have access to anything useful:
```
result = {org.eclipse.aether.RepositoryEvent@9738} "ARTIFACT_RESOLVED
com.fasterxml.jackson.datatype:jackson-datatype-jsr310:pom:2.12.1
(/home/ggrzybek/.m2/repository/com/fasterxml/jackson/datatype/jackson-datatype-jsr310/2.12.1/jackson-datatype-jsr310-2.12.1.pom)
@ central (https://repo.maven.apache.org/maven2, default, releases)"
artifact: org.eclipse.aether.artifact.Artifact =
{org.eclipse.aether.artifact.DefaultArtifact@9782}
"com.fasterxml.jackson.datatype:jackson-datatype-jsr310:pom:2.12.1"
exceptions: java.util.List = {java.util.Collections$EmptyList@9785} size
= 0
file: java.io.File = {java.io.File@9784}
"/home/ggrzybek/.m2/repository/com/fasterxml/jackson/datatype/jackson-datatype-jsr310/2.12.1/jackson-datatype-jsr310-2.12.1.pom"
metadata: org.eclipse.aether.metadata.Metadata = null
repository: org.eclipse.aether.repository.ArtifactRepository =
{org.eclipse.aether.repository.RemoteRepository@9783} "central
(https://repo.maven.apache.org/maven2, default, releases)"
session: org.eclipse.aether.RepositorySystemSession =
{org.eclip
[GitHub] [maven-resolver] grgrzybek commented on pull request #182: [MRESOLVER-262] Provide contextual data in trace during collect
grgrzybek commented on PR #182:
URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151165431
Similar situation with
`camel-spring-boot-generator-maven-plugin:3.14.2-SNAPSHOT:prepare-spring-boot-starter`:
```
"main@1" prio=5 tid=0x1 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at
org.ops4j.tools.maven.tracker.TrackingRepositoryListener.write(TrackingRepositoryListener.java:130)
at
org.ops4j.tools.maven.tracker.TrackingRepositoryListener.artifactResolved(TrackingRepositoryListener.java:53)
at
org.eclipse.aether.internal.impl.DefaultRepositoryEventDispatcher.dispatch(DefaultRepositoryEventDispatcher.java:136)
at
org.eclipse.aether.internal.impl.DefaultRepositoryEventDispatcher.dispatch(DefaultRepositoryEventDispatcher.java:93)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.artifactResolved(DefaultArtifactResolver.java:673)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:339)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:235)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:212)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:272)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:318)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:299)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:593)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:212)
at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:551)
at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:605)
at
org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.collect(DefaultLegacyArtifactCollector.java:148)
at
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:504)
at
org.apache.maven.repository.legacy.LegacyRepositorySystem.resolve(LegacyRepositorySystem.java:367)
at
org.apache.maven.DefaultProjectDependenciesResolver.resolveImpl(DefaultProjectDependenciesResolver.java:165)
at
org.apache.maven.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:81)
at
org.apache.maven.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:65)
at
org.apache.camel.springboot.maven.SpringBootStarterMojo.filterIncludedArtifacts(SpringBootStarterMojo.java:306)
at
org.apache.camel.springboot.maven.SpringBootStarterMojo.fixExcludedDependencies(SpringBootStarterMojo.java:265)
at
org.apache.camel.springboot.maven.SpringBootStarterMojo.executeAll(SpringBootStarterMojo.java:114)
at
org.apache.camel.springboot.maven.AbstractSpringBootGenerator.execute(AbstractSpringBootGenerator.java:69)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
...
```
There's
`org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector`
involved and my listener, while called, doesn't have access to anything useful:
```
result = {org.eclipse.aether.RepositoryEvent@9738} "ARTIFACT_RESOLVED
com.fasterxml.jackson.datatype:jackson-datatype-jsr310:pom:2.12.1
(/home/ggrzybek/.m2/repository/com/fasterxml/jackson/datatype/jackson-datatype-jsr310/2.12.1/jackson-datatype-jsr310-2.12.1.pom)
@ central (https://repo.maven.apache.org/maven2, default, releases)"
artifact: org.eclipse.aether.artifact.Artifact =
{org.eclipse.aether.artifact.DefaultArtifact@9782}
"com.fasterxml.jackson.datatype:jackson-datatype-jsr310:pom:2.12.1"
exceptions: java.util.List = {java.util.Collections$EmptyList@9785} size
= 0
file: java.io.File = {java.io.File@9784}
"/home/ggrzybek/.m2/repository/com/fasterxml/jackson/datatype/jackson-datatype-jsr310/2.12.1/jackson-datatype-jsr310-2.12.1.pom"
metadata: org.eclipse.aether.metadata.Metadata = null
repository: org.eclipse.aether.repository.ArtifactRepository =
{org.eclipse.aether.repository.RemoteRepository@9783} "central
(https://repo.maven.apache.org/maven2, default, releases)"
session: org.eclipse.aether.RepositorySystemSession =
{org.eclipse.aether.DefaultRepositorySystemSession@9781}
trace: org.eclipse.aether.RequestTrace =
{org.eclipse.aether.RequestTrace@9786}
"com.fasterxml.jackson.datatype:jackson-datatype-jsr310:pom:2.12.1 < [central
(https://repo.maven.apache.org/maven2, default, re
[jira] [Commented] (MRESOLVER-262) Provide contextual data in trace data for collector invoked requests
[ https://issues.apache.org/jira/browse/MRESOLVER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552234#comment-17552234 ] ASF GitHub Bot commented on MRESOLVER-262: -- cstamas commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151164419 > darn, I always lag behind... What kind of transport? ;) Sorry, spoke too early: I just spotted you play with 3.8.6 while this is in 3.9.0 and above only https://issues.apache.org/jira/browse/MNG-7454 (you can use it with 3.8.6 as well, but is a bit more complicated, just follow steps as here https://github.com/apache/maven/pull/635) > Provide contextual data in trace data for collector invoked requests > > > Key: MRESOLVER-262 > URL: https://issues.apache.org/jira/browse/MRESOLVER-262 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Priority: Major > Fix For: 1.8.1 > > > During collection several RepositoryEvents are fired, but they does not carry > any context related data regarding artifact collection. > Simplest solution would be to extend RequestTrace to provide: > * request context > * the artifact path (from root to leaf) > * leaf artifact being collected -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-resolver] cstamas commented on pull request #182: [MRESOLVER-262] Provide contextual data in trace during collect
cstamas commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151164419 > darn, I always lag behind... What kind of transport? ;) Sorry, spoke too early: I just spotted you play with 3.8.6 while this is in 3.9.0 and above only https://issues.apache.org/jira/browse/MNG-7454 (you can use it with 3.8.6 as well, but is a bit more complicated, just follow steps as here https://github.com/apache/maven/pull/635) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7478) Improve transport selection for resolver
[ https://issues.apache.org/jira/browse/MNG-7478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák updated MNG-7478: - Description: The MNG-7454 included resolver native transport and wagon transport for resolver and retains Wagon as default transport. Also, change added setting for the transport by user using user properties. Still, as the selection logic relies on user properties, it makes it impossible to simply set "for good" the selection, as it works only if set on command line. Moreover, the default maven behavior is affected by this change (in case 3rd party transport is installed), as in this case user MUST provide "auto" setting, while before 3.9.0 this was NOT the case: transport just had to be installed and proper transport was selected based on priorities. Hence, following changes are proposed: * Instead of user properties, core should use config properties (config + system + user merged) instead, as this allows setting transport in places like MAVEN_OPTS etc. * Introduce "real" default setting (used when no user input regarding transport) The latter change needs a bit of explanation: currently, if no user input, the code selects "wagon" as default value, and sets Wagon priority to MAX, potentially inhibiting any other installed 3rd party transport. Hence, due this change, users installing 3rd party transport now MUST provide transport setting "auto", that is IMHO wrong (alters behavior unexpectedly, requires user interaction where that was not the case before). Hence, we need to introduce "default" case (no user input given), that ONLY modifies Wagon priority in such way it ensures it "wins" over HttpTransport, but DOES NOT inhibit any potentially installed 3rd party provider. The "wagon" and "native" settings are unchanged (making sure that selected is used and INHIBITS anything else), while "auto" mode differs from "default" mode that it does not tamper with priorities at all (so stock maven with auto mode would select native transport due their coded priorities). was: The NNG-7454 included resolver native transport and wagon transport for resolver and retains Wagon as default transport. Also, change added setting for the transport by user using user properties. Still, as the selection logic relies on user properties, it makes it impossible to simply set "for good" the selection, as it works only if set on command line. Moreover, the default maven behavior is affected by this change (in case 3rd party transport is installed), as in this case user MUST provide "auto" setting, while before 3.9.0 this was NOT the case: transport just had to be installed and proper transport was selected based on priorities. Hence, following changes are proposed: * Instead of user properties, core should use config properties (config + system + user merged) instead, as this allows setting transport in places like MAVEN_OPTS etc. * Introduce "real" default setting (used when no user input regarding transport) The latter change needs a bit of explanation: currently, if no user input, the code selects "wagon" as default value, and sets Wagon priority to MAX, potentially inhibiting any other installed 3rd party transport. Hence, due this change, users installing 3rd party transport now MUST provide transport setting "auto", that is IMHO wrong (alters behavior unexpectedly, requires user interaction where that was not the case before). Hence, we need to introduce "default" case (no user input given), that ONLY modifies Wagon priority in such way it ensures it "wins" over HttpTransport, but DOES NOT inhibit any potentially installed 3rd party provider. The "wagon" and "native" settings are unchanged (making sure that selected is used and INHIBITS anything else), while "auto" mode differs from "default" mode that it does not tamper with priorities at all (so stock maven with auto mode would select native transport due their coded priorities). > Improve transport selection for resolver > > > Key: MNG-7478 > URL: https://issues.apache.org/jira/browse/MNG-7478 > Project: Maven > Issue Type: Improvement > Components: Core >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0 > > > The MNG-7454 included resolver native transport and wagon transport for > resolver and retains Wagon as default transport. Also, change added setting > for the transport by user using user properties. Still, as the selection > logic relies on user properties, it makes it impossible to simply set "for > good" the selection, as it works only if set on command line. Moreover, the > default maven behavior is affected by this change (in case 3rd party > transport is installed), as in this case user MUST
[jira] [Commented] (MRESOLVER-262) Provide contextual data in trace data for collector invoked requests
[ https://issues.apache.org/jira/browse/MRESOLVER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552230#comment-17552230 ] ASF GitHub Bot commented on MRESOLVER-262: -- grgrzybek commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151148657 An update about karaf-maven-plugin - while it's downloading additional artifacts (after analyzing the Karaf features), there's no real resolution performed, so it's not really possible to intercept karaf's downloads with some particular "path to the dependency". > Provide contextual data in trace data for collector invoked requests > > > Key: MRESOLVER-262 > URL: https://issues.apache.org/jira/browse/MRESOLVER-262 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Priority: Major > Fix For: 1.8.1 > > > During collection several RepositoryEvents are fired, but they does not carry > any context related data regarding artifact collection. > Simplest solution would be to extend RequestTrace to provide: > * request context > * the artifact path (from root to leaf) > * leaf artifact being collected -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-resolver] grgrzybek commented on pull request #182: [MRESOLVER-262] Provide contextual data in trace during collect
grgrzybek commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151148657 An update about karaf-maven-plugin - while it's downloading additional artifacts (after analyzing the Karaf features), there's no real resolution performed, so it's not really possible to intercept karaf's downloads with some particular "path to the dependency". -- 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-filtering] cstamas commented on a diff in pull request #38: [MSHARED-1080] Parent POM 36, Java8, drop legacy.
cstamas commented on code in PR #38: URL: https://github.com/apache/maven-filtering/pull/38#discussion_r893471604 ## src/main/java/org/apache/maven/shared/filtering/DefaultMavenFileFilter.java: ## @@ -105,8 +110,6 @@ public void copyFile( File from, File to, boolean filtering, List
[jira] [Commented] (ARCHETYPE-587) Multi-modules Archetypes' Root POM file contains empty lines in Java 11
[ https://issues.apache.org/jira/browse/ARCHETYPE-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552186#comment-17552186 ] Mike Cantrell commented on ARCHETYPE-587: - For what it's worth, it happens to me in 1.1 as well. > Multi-modules Archetypes' Root POM file contains empty lines in Java 11 > --- > > Key: ARCHETYPE-587 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-587 > Project: Maven Archetype > Issue Type: Bug > Components: Archetypes >Affects Versions: 3.1.1, 3.1.2 > Environment: Java 11.0.6 on Mac OS X Mojave (10.14.6), Maven 3.6.3 >Reporter: Andreas Schaefer >Priority: Major > > Building a project from an multi-modules archetype like Sling Project > Archetype ([https://github.com/apache/sling-project-archetype]) will yield a > parent POM that contains multiple empty lines between each line inside the > POM. > This is an issue in Java 11 but not in Java 8. > This seems to be related to issue 584 but its in this case this is only an > issue in Java 11 and the fix proposed in 584 does not seem to fix it. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MRESOLVER-262) Provide contextual data in trace data for collector invoked requests
[ https://issues.apache.org/jira/browse/MRESOLVER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552176#comment-17552176 ] ASF GitHub Bot commented on MRESOLVER-262: -- grgrzybek commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151058454 The trace shows DefaultLegacyArtifactCollector, so this may be the reason: ``` "main@1" prio=5 tid=0x1 nid=NA runnable java.lang.Thread.State: RUNNABLE at org.ops4j.tools.maven.tracker.TrackingRepositoryListener.write(TrackingRepositoryListener.java:123) at org.ops4j.tools.maven.tracker.TrackingRepositoryListener.artifactResolved(TrackingRepositoryListener.java:52) at org.eclipse.aether.internal.impl.DefaultRepositoryEventDispatcher.dispatch(DefaultRepositoryEventDispatcher.java:136) at org.eclipse.aether.internal.impl.DefaultRepositoryEventDispatcher.dispatch(DefaultRepositoryEventDispatcher.java:93) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.artifactResolved(DefaultArtifactResolver.java:673) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:339) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:235) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:212) at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:272) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:318) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:299) at org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:593) at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:212) at org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:551) at org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:605) at org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.collect(DefaultLegacyArtifactCollector.java:148) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:504) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveWithExceptions(DefaultArtifactResolver.java:358) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:352) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:324) at org.codehaus.mojo.gwt.AbstractGwtMojo.getJarAndDependencies(AbstractGwtMojo.java:377) at org.codehaus.mojo.gwt.AbstractGwtMojo.getGwtDevJar(AbstractGwtMojo.java:269) at com.vaadin.integration.maven.UpdateWidgetsetMojo.updateWidgetset(UpdateWidgetsetMojo.java:276) at com.vaadin.integration.maven.UpdateWidgetsetMojo.updateLocalWidgetset(UpdateWidgetsetMojo.java:123) at com.vaadin.integration.maven.UpdateWidgetsetMojo.doExecute(UpdateWidgetsetMojo.java:92) at org.codehaus.mojo.gwt.shell.AbstractGwtShellMojo.execute(AbstractGwtShellMojo.java:182) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137) at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:370) at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:351) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:215) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:171) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:163) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:294) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:960) at org.apache.maven.cli.MavenCli.
[GitHub] [maven-resolver] grgrzybek commented on pull request #182: [MRESOLVER-262] Provide contextual data in trace during collect
grgrzybek commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151058454 The trace shows DefaultLegacyArtifactCollector, so this may be the reason: ``` "main@1" prio=5 tid=0x1 nid=NA runnable java.lang.Thread.State: RUNNABLE at org.ops4j.tools.maven.tracker.TrackingRepositoryListener.write(TrackingRepositoryListener.java:123) at org.ops4j.tools.maven.tracker.TrackingRepositoryListener.artifactResolved(TrackingRepositoryListener.java:52) at org.eclipse.aether.internal.impl.DefaultRepositoryEventDispatcher.dispatch(DefaultRepositoryEventDispatcher.java:136) at org.eclipse.aether.internal.impl.DefaultRepositoryEventDispatcher.dispatch(DefaultRepositoryEventDispatcher.java:93) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.artifactResolved(DefaultArtifactResolver.java:673) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:339) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:235) at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:212) at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:272) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:318) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:299) at org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:593) at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:212) at org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:551) at org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.recurse(DefaultLegacyArtifactCollector.java:605) at org.apache.maven.repository.legacy.resolver.DefaultLegacyArtifactCollector.collect(DefaultLegacyArtifactCollector.java:148) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:504) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveWithExceptions(DefaultArtifactResolver.java:358) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:352) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:324) at org.codehaus.mojo.gwt.AbstractGwtMojo.getJarAndDependencies(AbstractGwtMojo.java:377) at org.codehaus.mojo.gwt.AbstractGwtMojo.getGwtDevJar(AbstractGwtMojo.java:269) at com.vaadin.integration.maven.UpdateWidgetsetMojo.updateWidgetset(UpdateWidgetsetMojo.java:276) at com.vaadin.integration.maven.UpdateWidgetsetMojo.updateLocalWidgetset(UpdateWidgetsetMojo.java:123) at com.vaadin.integration.maven.UpdateWidgetsetMojo.doExecute(UpdateWidgetsetMojo.java:92) at org.codehaus.mojo.gwt.shell.AbstractGwtShellMojo.execute(AbstractGwtShellMojo.java:182) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137) at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:370) at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:351) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:215) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:171) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:163) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:294) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:960) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:293) at org.apache.maven.cli.MavenCli.main(MavenCli.java:196) at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessor
[jira] [Commented] (MRESOLVER-262) Provide contextual data in trace data for collector invoked requests
[
https://issues.apache.org/jira/browse/MRESOLVER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552174#comment-17552174
]
ASF GitHub Bot commented on MRESOLVER-262:
--
grgrzybek commented on PR #182:
URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151057136
Another plugin doing its own resolution:
`com.vaadin.integration.maven.UpdateWidgetsetMojo` - my listener is called, but
there's only one RequestTrace available:
```
result = {org.eclipse.aether.RepositoryEvent@41639} "ARTIFACT_RESOLVED
ant:ant:pom:1.6.5 (/data/tmp/.m2-ext2-df/ant/ant/1.6.5/ant-1.6.5.pom) @ central
(https://repo.maven.apache.org/maven2, default, releases)"
artifact: org.eclipse.aether.artifact.Artifact =
{org.eclipse.aether.artifact.DefaultArtifact@41691} "ant:ant:pom:1.6.5"
exceptions: java.util.List = {java.util.Collections$EmptyList@41694} size
= 0
file: java.io.File = {java.io.File@41693}
"/data/tmp/.m2-ext2-df/ant/ant/1.6.5/ant-1.6.5.pom"
metadata: org.eclipse.aether.metadata.Metadata = null
repository: org.eclipse.aether.repository.ArtifactRepository =
{org.eclipse.aether.repository.RemoteRepository@41692} "central
(https://repo.maven.apache.org/maven2, default, releases)"
session: org.eclipse.aether.RepositorySystemSession =
{org.eclipse.aether.DefaultRepositorySystemSession@41690}
trace: org.eclipse.aether.RequestTrace =
{org.eclipse.aether.RequestTrace@41695} "ant:ant:pom:1.6.5 < [apache-snapshots
(https://repository.apache.org/content/groups/snapshots-group, default,
snapshots), sonatype-ops4j-snapshots
(https://oss.sonatype.org/content/repositories/ops4j-snapshots, default,
snapshots), prime-repo (https://repository.primefaces.org, default,
releases+snapshots), sonatype-nexus-snapshots
(https://oss.sonatype.org/content/repositories/snapshots, default, snapshots),
central (https://repo.maven.apache.org/maven2, default, releases)]"
data: java.lang.Object =
{org.eclipse.aether.resolution.ArtifactRequest@41641} "ant:ant:pom:1.6.5 <
[apache-snapshots
(https://repository.apache.org/content/groups/snapshots-group, default,
snapshots), sonatype-ops4j-snapshots
(https://oss.sonatype.org/content/repositories/ops4j-snapshots, default,
snapshots), prime-repo (https://repository.primefaces.org, default,
releases+snapshots), sonatype-nexus-snapshots
(https://oss.sonatype.org/content/repositories/snapshots, default, snapshots),
central (https://repo.maven.apache.org/maven2, default, releases)]"
artifact: org.eclipse.aether.artifact.Artifact =
{org.eclipse.aether.artifact.DefaultArtifact@41705} "ant:ant:pom:1.6.5"
context: java.lang.String = {@41707} ""
node: org.eclipse.aether.graph.DependencyNode = null
repositories: java.util.List = {java.util.ArrayList@41706} size = 5
trace: org.eclipse.aether.RequestTrace = null
parent: org.eclipse.aether.RequestTrace = null
type: org.eclipse.aether.RepositoryEvent$EventType = {@41689}
"ARTIFACT_RESOLVED"
```
> Provide contextual data in trace data for collector invoked requests
>
>
> Key: MRESOLVER-262
> URL: https://issues.apache.org/jira/browse/MRESOLVER-262
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamás Cservenák
>Priority: Major
> Fix For: 1.8.1
>
>
> During collection several RepositoryEvents are fired, but they does not carry
> any context related data regarding artifact collection.
> Simplest solution would be to extend RequestTrace to provide:
> * request context
> * the artifact path (from root to leaf)
> * leaf artifact being collected
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-resolver] grgrzybek commented on pull request #182: [MRESOLVER-262] Provide contextual data in trace during collect
grgrzybek commented on PR #182:
URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151057136
Another plugin doing its own resolution:
`com.vaadin.integration.maven.UpdateWidgetsetMojo` - my listener is called, but
there's only one RequestTrace available:
```
result = {org.eclipse.aether.RepositoryEvent@41639} "ARTIFACT_RESOLVED
ant:ant:pom:1.6.5 (/data/tmp/.m2-ext2-df/ant/ant/1.6.5/ant-1.6.5.pom) @ central
(https://repo.maven.apache.org/maven2, default, releases)"
artifact: org.eclipse.aether.artifact.Artifact =
{org.eclipse.aether.artifact.DefaultArtifact@41691} "ant:ant:pom:1.6.5"
exceptions: java.util.List = {java.util.Collections$EmptyList@41694} size
= 0
file: java.io.File = {java.io.File@41693}
"/data/tmp/.m2-ext2-df/ant/ant/1.6.5/ant-1.6.5.pom"
metadata: org.eclipse.aether.metadata.Metadata = null
repository: org.eclipse.aether.repository.ArtifactRepository =
{org.eclipse.aether.repository.RemoteRepository@41692} "central
(https://repo.maven.apache.org/maven2, default, releases)"
session: org.eclipse.aether.RepositorySystemSession =
{org.eclipse.aether.DefaultRepositorySystemSession@41690}
trace: org.eclipse.aether.RequestTrace =
{org.eclipse.aether.RequestTrace@41695} "ant:ant:pom:1.6.5 < [apache-snapshots
(https://repository.apache.org/content/groups/snapshots-group, default,
snapshots), sonatype-ops4j-snapshots
(https://oss.sonatype.org/content/repositories/ops4j-snapshots, default,
snapshots), prime-repo (https://repository.primefaces.org, default,
releases+snapshots), sonatype-nexus-snapshots
(https://oss.sonatype.org/content/repositories/snapshots, default, snapshots),
central (https://repo.maven.apache.org/maven2, default, releases)]"
data: java.lang.Object =
{org.eclipse.aether.resolution.ArtifactRequest@41641} "ant:ant:pom:1.6.5 <
[apache-snapshots
(https://repository.apache.org/content/groups/snapshots-group, default,
snapshots), sonatype-ops4j-snapshots
(https://oss.sonatype.org/content/repositories/ops4j-snapshots, default,
snapshots), prime-repo (https://repository.primefaces.org, default,
releases+snapshots), sonatype-nexus-snapshots
(https://oss.sonatype.org/content/repositories/snapshots, default, snapshots),
central (https://repo.maven.apache.org/maven2, default, releases)]"
artifact: org.eclipse.aether.artifact.Artifact =
{org.eclipse.aether.artifact.DefaultArtifact@41705} "ant:ant:pom:1.6.5"
context: java.lang.String = {@41707} ""
node: org.eclipse.aether.graph.DependencyNode = null
repositories: java.util.List = {java.util.ArrayList@41706} size = 5
trace: org.eclipse.aether.RequestTrace = null
parent: org.eclipse.aether.RequestTrace = null
type: org.eclipse.aether.RepositoryEvent$EventType = {@41689}
"ARTIFACT_RESOLVED"
```
--
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-filtering] olamy commented on a diff in pull request #38: [MSHARED-1080] Parent POM 36, Java8, drop legacy.
olamy commented on code in PR #38: URL: https://github.com/apache/maven-filtering/pull/38#discussion_r893427448 ## src/main/java/org/apache/maven/shared/filtering/DefaultMavenFileFilter.java: ## @@ -105,8 +110,6 @@ public void copyFile( File from, File to, boolean filtering, Listhttps://github.com/takari/io.takari.incrementalbuild (last commit almost 2 yo ago). -- 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-262) Provide contextual data in trace data for collector invoked requests
[ https://issues.apache.org/jira/browse/MRESOLVER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552166#comment-17552166 ] ASF GitHub Bot commented on MRESOLVER-262: -- grgrzybek commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151039187 > try out new transport darn, I always lag behind... What kind of transport? ;) > Provide contextual data in trace data for collector invoked requests > > > Key: MRESOLVER-262 > URL: https://issues.apache.org/jira/browse/MRESOLVER-262 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Priority: Major > Fix For: 1.8.1 > > > During collection several RepositoryEvents are fired, but they does not carry > any context related data regarding artifact collection. > Simplest solution would be to extend RequestTrace to provide: > * request context > * the artifact path (from root to leaf) > * leaf artifact being collected -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-resolver] grgrzybek commented on pull request #182: [MRESOLVER-262] Provide contextual data in trace during collect
grgrzybek commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151039187 > try out new transport darn, I always lag behind... What kind of transport? ;) -- 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-262) Provide contextual data in trace data for collector invoked requests
[ https://issues.apache.org/jira/browse/MRESOLVER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552165#comment-17552165 ] ASF GitHub Bot commented on MRESOLVER-262: -- cstamas commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151036420 @grgrzybek one more thing... IF you are testing already, try out new transport? :wink: > Provide contextual data in trace data for collector invoked requests > > > Key: MRESOLVER-262 > URL: https://issues.apache.org/jira/browse/MRESOLVER-262 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Priority: Major > Fix For: 1.8.1 > > > During collection several RepositoryEvents are fired, but they does not carry > any context related data regarding artifact collection. > Simplest solution would be to extend RequestTrace to provide: > * request context > * the artifact path (from root to leaf) > * leaf artifact being collected -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-resolver] cstamas commented on pull request #182: [MRESOLVER-262] Provide contextual data in trace during collect
cstamas commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151036420 @grgrzybek one more thing... IF you are testing already, try out new transport? :wink: -- 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-262) Provide contextual data in trace data for collector invoked requests
[ https://issues.apache.org/jira/browse/MRESOLVER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552164#comment-17552164 ] ASF GitHub Bot commented on MRESOLVER-262: -- grgrzybek commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151034135 New version of tracking extension: https://github.com/grgrzybek/tracking-maven-extension/commits/resolver-1.8.x I've performed these tests building https://github.com/ops4j/org.ops4j.pax.web project: * Maven 3.8.6 with maven-resolver 1.8.1-SNAPSHOT with this #182 merged and `-Dmaven.ext.class.path` pointing to my extension * Maven 3.8.6 with maven-resolver 1.8.1-SNAPSHOT with this #182 merged without my extension * Maven 3.8.6 with maven-resolver 1.8.1-SNAPSHOT with this #182 merged and `-Dmaven.ext.class.path` pointing to my extension and with `-Daether.collector.impl=bf` * Maven 3.8.6 with maven-resolver 1.8.1-SNAPSHOT with this #182 merged without my extension and with `-Daether.collector.impl=bf` * Maven 3.8.5 with normal maven-resolver 1.6.3 and then 2nd time each of the above again on previously populated repo. Here are the results (tme = [tracking maven extension](https://github.com/grgrzybek/tracking-maven-extension/commits/resolver-1.8.x )): | | fresh repository | existing repository | |---|---|---| |mvn 3.8.6 + resolver 1.8.1 + #182 + tme + DF|5:25 min|1:08 min| |mvn 3.8.6 + resolver 1.8.1 + #182 + DF|5:09 min|1:07 min| |mvn 3.8.6 + resolver 1.8.1 + #182 + tme + BF|5:15 min|1:07 min| |mvn 3.8.6 + resolver 1.8.1 + #182 + BF|5:04 min|1:07 min| |mvn 3.8.5 + resolver 1.6.3|5:19 min|1:07 min| It's too small sample to treat it as proper performance test, but it can be a rough estimate. When nothing is downloaded (already populated repo) the times are almost the same. * When downloading is involved the extension's listener (where all the `.tracking` content is created) adds 10-15 seconds to the processing (~4-5%). * BF is slightly faster than DF. There are small difference between BF and DF when checking the reversed dependency trees - these are fully expected and actually show the difference in graph navigation. For example for aopalliance:aopalliance:1.0 I had: DF: ``` aopalliance:aopalliance:pom:1.0 aopalliance:aopalliance:jar:1.0 (compile) (plugin) org.sonatype.sisu:sisu-guice:jar:no_aop:3.1.0 (compile) (plugin) org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M5 (compile) (plugin) org.apache.maven:maven-plugin-api:jar:3.1.1 (compile) (plugin) org.apache.maven.enforcer:enforcer-api:jar:3.0.0 (compile) (plugin) org.commonjava.maven.enforcer:enforce-managed-deps-rule:jar:1.3 (runtime) (plugin) org.apache.maven.plugins:maven-enforcer-plugin:jar:3.0.0 () (plugin) Repository: central (https://repo.maven.apache.org/maven2, default, releases) ``` BF: ``` aopalliance:aopalliance:pom:1.0 aopalliance:aopalliance:jar:1.0 (compile) (plugin) org.sonatype.sisu:sisu-guice:jar:no_aop:3.1.0 (compile) (plugin) org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M5 (compile) (plugin) org.apache.maven:maven-plugin-api:jar:3.1.1 (compile) (plugin) org.apache.maven.plugins:maven-enforcer-plugin:jar:3.0.0 () (plugin) Repository: central (https://repo.maven.apache.org/maven2, default, releases) ``` I'm going to have a look now at the plugins I've mentioned earlier (org.apache.camel.springboot:camel-spring-boot-generator-maven-plugin and org.apache.karaf.tooling:karaf-maven-plugin). Summarizing - the resolver changes are great! thanks @cstamas ! (cc: @gnodet ) > Provide contextual data in trace data for collector invoked requests > > > Key: MRESOLVER-262 > URL: https://issues.apache.org/jira/browse/MRESOLVER-262 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Priority: Major > Fix For: 1.8.1 > > > During collection several RepositoryEvents are fired, but they does not carry > any context related data regarding artifact collection. > Simplest solution would be to extend RequestTrace to provide: > * request context > * the artifact path (from root to leaf) > * leaf artifact being collected -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-resolver] grgrzybek commented on pull request #182: [MRESOLVER-262] Provide contextual data in trace during collect
grgrzybek commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1151034135 New version of tracking extension: https://github.com/grgrzybek/tracking-maven-extension/commits/resolver-1.8.x I've performed these tests building https://github.com/ops4j/org.ops4j.pax.web project: * Maven 3.8.6 with maven-resolver 1.8.1-SNAPSHOT with this #182 merged and `-Dmaven.ext.class.path` pointing to my extension * Maven 3.8.6 with maven-resolver 1.8.1-SNAPSHOT with this #182 merged without my extension * Maven 3.8.6 with maven-resolver 1.8.1-SNAPSHOT with this #182 merged and `-Dmaven.ext.class.path` pointing to my extension and with `-Daether.collector.impl=bf` * Maven 3.8.6 with maven-resolver 1.8.1-SNAPSHOT with this #182 merged without my extension and with `-Daether.collector.impl=bf` * Maven 3.8.5 with normal maven-resolver 1.6.3 and then 2nd time each of the above again on previously populated repo. Here are the results (tme = [tracking maven extension](https://github.com/grgrzybek/tracking-maven-extension/commits/resolver-1.8.x )): | | fresh repository | existing repository | |---|---|---| |mvn 3.8.6 + resolver 1.8.1 + #182 + tme + DF|5:25 min|1:08 min| |mvn 3.8.6 + resolver 1.8.1 + #182 + DF|5:09 min|1:07 min| |mvn 3.8.6 + resolver 1.8.1 + #182 + tme + BF|5:15 min|1:07 min| |mvn 3.8.6 + resolver 1.8.1 + #182 + BF|5:04 min|1:07 min| |mvn 3.8.5 + resolver 1.6.3|5:19 min|1:07 min| It's too small sample to treat it as proper performance test, but it can be a rough estimate. When nothing is downloaded (already populated repo) the times are almost the same. * When downloading is involved the extension's listener (where all the `.tracking` content is created) adds 10-15 seconds to the processing (~4-5%). * BF is slightly faster than DF. There are small difference between BF and DF when checking the reversed dependency trees - these are fully expected and actually show the difference in graph navigation. For example for aopalliance:aopalliance:1.0 I had: DF: ``` aopalliance:aopalliance:pom:1.0 aopalliance:aopalliance:jar:1.0 (compile) (plugin) org.sonatype.sisu:sisu-guice:jar:no_aop:3.1.0 (compile) (plugin) org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M5 (compile) (plugin) org.apache.maven:maven-plugin-api:jar:3.1.1 (compile) (plugin) org.apache.maven.enforcer:enforcer-api:jar:3.0.0 (compile) (plugin) org.commonjava.maven.enforcer:enforce-managed-deps-rule:jar:1.3 (runtime) (plugin) org.apache.maven.plugins:maven-enforcer-plugin:jar:3.0.0 () (plugin) Repository: central (https://repo.maven.apache.org/maven2, default, releases) ``` BF: ``` aopalliance:aopalliance:pom:1.0 aopalliance:aopalliance:jar:1.0 (compile) (plugin) org.sonatype.sisu:sisu-guice:jar:no_aop:3.1.0 (compile) (plugin) org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M5 (compile) (plugin) org.apache.maven:maven-plugin-api:jar:3.1.1 (compile) (plugin) org.apache.maven.plugins:maven-enforcer-plugin:jar:3.0.0 () (plugin) Repository: central (https://repo.maven.apache.org/maven2, default, releases) ``` I'm going to have a look now at the plugins I've mentioned earlier (org.apache.camel.springboot:camel-spring-boot-generator-maven-plugin and org.apache.karaf.tooling:karaf-maven-plugin). Summarizing - the resolver changes are great! thanks @cstamas ! (cc: @gnodet ) -- 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] (MDEPLOY-293) Maven deploy fails with 401 Unauthorized when using £ in password
[
https://issues.apache.org/jira/browse/MDEPLOY-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552160#comment-17552160
]
Michael Osipov commented on MDEPLOY-293:
The platform encoding is irrelevant. Provide me screenshots of the hex values
intercepted by Wireshark, not decoded content.
> Maven deploy fails with 401 Unauthorized when using £ in password
> -
>
> Key: MDEPLOY-293
> URL: https://issues.apache.org/jira/browse/MDEPLOY-293
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Nélson Cunha
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: image-2022-06-08-20-06-39-388.png,
> image-2022-06-08-20-09-57-536.png
>
>
> Hello.
> I'm using Apache Maven 3.6.3 and maven-deploy-plugin 2.8.2 on Oracle's Java
> version 1.8.0_321 and I'm currently receiving the 401 Unauthorized error
> when deploying an artifact to Sonatype Nexus:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on
> project XXX: Failed to deploy artifacts: Could not transfer artifact
> XXX:XXX:pom:4.0.0-20220608.184337-1 from/to nexus-snapshots
> (http://.../repository/maven-snapshots/): Transfer failed for
> http://...-4.0.0-20220608.184337-1.pom 401 Unauthorized -> [Help 1]{noformat}
>
> This error showed up after I changed my password with a leading {{£}}
> character.
>
> Using Wireshark to capture the HTTP packages exchanged between the maven
> client and the nexus repository, I see 3 interactions:
> # unauthenticated GET request for a maven-metadata.xml file, followed by a
> 401 response
> # authenticated GET request for the same maven-metadata.xml file, followed
> by a 404 response
> # authenticated PUT request for the pom file, followed by a 401 response
>
> Now, analyzing the headers for the second and third request I noticed the
> base64 on the Authentication header is not the same.
> * 2nd request: GET metadata
> !image-2022-06-08-20-06-39-388.png!
>
> * 3rd request PUT pom
> !image-2022-06-08-20-09-57-536.png!
>
> The decoded base64 with the username:password, shows that, as expected, the
> request that received a 404 holds the right password, but on the other hand,
> the PUT request that got a 401 has a password with a {{?}} for the {{{}£{}}}.
>
> All the servers on my {{settings.xml}} hold the same user/password and I have
> tried with the passwords encoded and in plain text.
>
>
> Further tests with base64 encoding and decoding showed that the "wrong"
> password is the actual password but encoded from an ANSI code page where the
> password accepted by Nexus is encoded from utf8.
>
> I noticed the 401 responses don't specify the encoding on the
> {{WWW-Authenticate}} header, which should clear up which encoding to use, but
> still for some reason the two requests are apparently using different
> encodings.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-filtering] cstamas commented on a diff in pull request #38: [MSHARED-1080] Parent POM 36, Java8, drop legacy.
cstamas commented on code in PR #38: URL: https://github.com/apache/maven-filtering/pull/38#discussion_r893344830 ## src/main/java/org/apache/maven/shared/filtering/DefaultMavenFileFilter.java: ## @@ -105,8 +110,6 @@ public void copyFile( File from, File to, boolean filtering, Listhttps://github.com/takari/io.takari.incrementalbuild -- 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-filtering] cstamas commented on a diff in pull request #38: [MSHARED-1080] Parent POM 36, Java8, drop legacy.
cstamas commented on code in PR #38: URL: https://github.com/apache/maven-filtering/pull/38#discussion_r893344830 ## src/main/java/org/apache/maven/shared/filtering/DefaultMavenFileFilter.java: ## @@ -105,8 +110,6 @@ public void copyFile( File from, File to, boolean filtering, Listhttps://github.com/takari/io.takari.incrementalbuild -- 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-filtering] cstamas commented on a diff in pull request #38: [MSHARED-1080] Parent POM 36, Java8, drop legacy.
cstamas commented on code in PR #38: URL: https://github.com/apache/maven-filtering/pull/38#discussion_r893344830 ## src/main/java/org/apache/maven/shared/filtering/DefaultMavenFileFilter.java: ## @@ -105,8 +110,6 @@ public void copyFile( File from, File to, boolean filtering, Listhttps://github.com/takari/io.takari.incrementalbuild -- 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-filtering] olamy commented on pull request #38: [MSHARED-1080] Parent POM 36, Java8, drop legacy.
olamy commented on PR #38: URL: https://github.com/apache/maven-filtering/pull/38#issuecomment-1150954083 @rakus ping -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-filtering] olamy commented on a diff in pull request #38: [MSHARED-1080] Parent POM 36, Java8, drop legacy.
olamy commented on code in PR #38: URL: https://github.com/apache/maven-filtering/pull/38#discussion_r893341016 ## src/main/java/org/apache/maven/shared/filtering/DefaultMavenFileFilter.java: ## @@ -105,8 +110,6 @@ public void copyFile( File from, File to, boolean filtering, Listhttps://github.com/codehaus-plexus/plexus-build-api/issues -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-filtering] cstamas commented on a diff in pull request #38: [MSHARED-1080] Parent POM 36, Java8, drop legacy.
cstamas commented on code in PR #38: URL: https://github.com/apache/maven-filtering/pull/38#discussion_r893340750 ## src/main/java/org/apache/maven/shared/filtering/DefaultMavenFileFilter.java: ## @@ -105,8 +110,6 @@ public void copyFile( File from, File to, boolean filtering, List
[GitHub] [maven-filtering] olamy commented on pull request #38: [MSHARED-1080] Parent POM 36, Java8, drop legacy.
olamy commented on PR #38: URL: https://github.com/apache/maven-filtering/pull/38#issuecomment-1150943827 @fbricon still active m2e? any idea if this BuildContext is still in use? or maybe you can ping someone else? thanks -- 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-filtering] olamy commented on a diff in pull request #38: [MSHARED-1080] Parent POM 36, Java8, drop legacy.
olamy commented on code in PR #38: URL: https://github.com/apache/maven-filtering/pull/38#discussion_r893330776 ## src/main/java/org/apache/maven/shared/filtering/DefaultMavenFileFilter.java: ## @@ -105,8 +110,6 @@ public void copyFile( File from, File to, boolean filtering, List
[GitHub] [maven-filtering] cstamas commented on a diff in pull request #38: [MSHARED-1080] Parent POM 36, Java8, drop legacy.
cstamas commented on code in PR #38: URL: https://github.com/apache/maven-filtering/pull/38#discussion_r893322895 ## src/main/java/org/apache/maven/shared/filtering/DefaultMavenFileFilter.java: ## @@ -105,8 +110,6 @@ public void copyFile( File from, File to, boolean filtering, List
[GitHub] [maven-filtering] olamy commented on a diff in pull request #38: [MSHARED-1080] Parent POM 36, Java8, drop legacy.
olamy commented on code in PR #38: URL: https://github.com/apache/maven-filtering/pull/38#discussion_r893306287 ## src/main/java/org/apache/maven/shared/filtering/DefaultMavenFileFilter.java: ## @@ -105,8 +110,6 @@ public void copyFile( File from, File to, boolean filtering, Listhttps://github.com/search?q=org%3Aeclipse-m2e+BuildContext&type=code for sure this very old repo is just interface which doesn't need much changes so that's probably the reason. disclaimer i'm not using m2e 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] (MDEPLOY-293) Maven deploy fails with 401 Unauthorized when using £ in password
[
https://issues.apache.org/jira/browse/MDEPLOY-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552082#comment-17552082
]
Nélson Cunha commented on MDEPLOY-293:
--
Setting {{{}MAVEN_OPTS="-Dfile.encoding=UTF-8"{}}}, changed the platform
encoding ({{{}Default locale: en_US, platform encoding: UTF-8{}}}) but produced
no effect on the deploy's http request credentials.
> Maven deploy fails with 401 Unauthorized when using £ in password
> -
>
> Key: MDEPLOY-293
> URL: https://issues.apache.org/jira/browse/MDEPLOY-293
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Nélson Cunha
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: image-2022-06-08-20-06-39-388.png,
> image-2022-06-08-20-09-57-536.png
>
>
> Hello.
> I'm using Apache Maven 3.6.3 and maven-deploy-plugin 2.8.2 on Oracle's Java
> version 1.8.0_321 and I'm currently receiving the 401 Unauthorized error
> when deploying an artifact to Sonatype Nexus:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on
> project XXX: Failed to deploy artifacts: Could not transfer artifact
> XXX:XXX:pom:4.0.0-20220608.184337-1 from/to nexus-snapshots
> (http://.../repository/maven-snapshots/): Transfer failed for
> http://...-4.0.0-20220608.184337-1.pom 401 Unauthorized -> [Help 1]{noformat}
>
> This error showed up after I changed my password with a leading {{£}}
> character.
>
> Using Wireshark to capture the HTTP packages exchanged between the maven
> client and the nexus repository, I see 3 interactions:
> # unauthenticated GET request for a maven-metadata.xml file, followed by a
> 401 response
> # authenticated GET request for the same maven-metadata.xml file, followed
> by a 404 response
> # authenticated PUT request for the pom file, followed by a 401 response
>
> Now, analyzing the headers for the second and third request I noticed the
> base64 on the Authentication header is not the same.
> * 2nd request: GET metadata
> !image-2022-06-08-20-06-39-388.png!
>
> * 3rd request PUT pom
> !image-2022-06-08-20-09-57-536.png!
>
> The decoded base64 with the username:password, shows that, as expected, the
> request that received a 404 holds the right password, but on the other hand,
> the PUT request that got a 401 has a password with a {{?}} for the {{{}£{}}}.
>
> All the servers on my {{settings.xml}} hold the same user/password and I have
> tried with the passwords encoded and in plain text.
>
>
> Further tests with base64 encoding and decoding showed that the "wrong"
> password is the actual password but encoded from an ANSI code page where the
> password accepted by Nexus is encoded from utf8.
>
> I noticed the 401 responses don't specify the encoding on the
> {{WWW-Authenticate}} header, which should clear up which encoding to use, but
> still for some reason the two requests are apparently using different
> encodings.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-filtering] cstamas commented on a diff in pull request #38: [MSHARED-1080] Parent POM 36, Java8, drop legacy.
cstamas commented on code in PR #38: URL: https://github.com/apache/maven-filtering/pull/38#discussion_r893287841 ## src/main/java/org/apache/maven/shared/filtering/DefaultMavenFileFilter.java: ## @@ -105,8 +110,6 @@ public void copyFile( File from, File to, boolean filtering, List
[jira] [Commented] (MJAR-275) outputTimestamp not applied to module-info; breaks reproducible builds
[
https://issues.apache.org/jira/browse/MJAR-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552063#comment-17552063
]
Jorge Solórzano commented on MJAR-275:
--
Please note that as Michael points out there are two issues here:
# Modification of timestamps
# Incorporation of patch JDK version information
The fix in plexus-archiver #205 only handles the first one, the timestamps, but
when you use the same version of the JDK to compile the module declaration it
adds the JDK patch version to the module descriptor making it non reproducible
(unless you use the exact same JDK version).
Anyway, to overcome this limitation you can build the module descriptor
targeting Java 9 using a newer JDK (e.g. using JDK 11 to compile a
module-info.java with --release 9).
> outputTimestamp not applied to module-info; breaks reproducible builds
> --
>
> Key: MJAR-275
> URL: https://issues.apache.org/jira/browse/MJAR-275
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 3.2.0
> Environment: Mac OS X 10.14.6
> JDK 15 (build 15+36)
> JDK 11 (build 11.0.8+10)
>Reporter: Anand Beh
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: MCOMPILER-439.zip, Screenshot 2020-10-25 at 2.35.59
> PM.png
>
>
> Setting {{project.build.outputTimestamp}} to a fixed value allows creating
> reproducible builds per this guide:
> [https://maven.apache.org/guides/mini/guide-reproducible-builds.html
> |https://maven.apache.org/guides/mini/guide-reproducible-builds.html]However,
> if one adds a module-info file to the project, reproducible builds break.
> This is caused by module-info.class using the latest timestamp and not
> {{project.build.outputTimestamp}}. I was able to identify the problem using
> diffoscope: [https://diffoscope.org/.|https://diffoscope.org/] With it I
> determined the timestamp across 2 builds was constant for all but the
> module-info.class:
>
> {code:java}
> -rw 2.0 fat 862 bl defN 20-Oct-17 00:40
> space/arim/libertybans/api/select/SelectionOrder.class
> │ -rw 2.0 fat 1113 bl defN 20-Oct-17 00:40
> space/arim/libertybans/api/select/SelectionOrderBuilder.class
> │ -rw 2.0 fat 2285 bl defN 20-Oct-17 00:40
> META-INF/maven/space.arim.libertybans/bans-api/pom.xml
> │ -rw 2.0 fat 74 bl defN 20-Oct-17 00:40
> META-INF/maven/space.arim.libertybans/bans-api/pom.properties
> │ --rw 2.0 fat 557 bl defN 20-Oct-25 12:39 module-info.class
> │ +-rw 2.0 fat 557 bl defN 20-Oct-25 12:41 module-info.class
> {code}
>
> Note the + and - which are diffoscope's way of indicating the difference
> between the .jar files. Here the {{project.build.outputTimestamp}} is on 17
> October. As shown, module-info has a "rebellious" timestamp.
>
> *EDIT:*
> Example project to reproduce the bug:
> [https://github.com/A248/MJAR-275|https://github.com/A248/MCOMPILER-439]
> (Renamed from [https://github.com/A248/MCOMPILER-439])
> Source code is also provided as an attachment below
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MRESOLVER-262) Provide contextual data in trace data for collector invoked requests
[ https://issues.apache.org/jira/browse/MRESOLVER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552054#comment-17552054 ] ASF GitHub Bot commented on MRESOLVER-262: -- grgrzybek commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1150864268 Dependencies can be tracked as expected. It works different for child→parent relationship, because the path is not passed down with `RequestTrace`. Most of the projects being built on fresh repo starts with: ``` Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.pom Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.pom (3.9 kB at 8.9 kB/s) Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-plugins/22/maven-plugins-22.pom Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-plugins/22/maven-plugins-22.pom (13 kB at 157 kB/s) Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven-parent/21/maven-parent-21.pom Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven-parent/21/maven-parent-21.pom (26 kB at 277 kB/s) Downloading from central: https://repo.maven.apache.org/maven2/org/apache/apache/10/apache-10.pom Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/apache/10/apache-10.pom (15 kB at 197 kB/s) Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.jar Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.5/maven-clean-plugin-2.5.jar (25 kB at 254 kB/s) ``` However for org.apache:apache:pom:10, I could track this information (in fresh M2 repo in `org/apache/apache/10/.tracking/org.apache.maven.plugins_maven-clean-plugin_2.5.plugin` file): ``` org.apache:apache:pom:10 org.apache.maven.plugins:maven-clean-plugin:2.5 org.apache.maven:maven-core:3.8.6.1:default-lifecycle-bindings (implicit) Repository: central (https://repo.maven.apache.org/maven2, default, releases) ``` It'd be great to insert these: * org/apache/maven/plugins/maven-plugins/22 * org/apache/maven/maven-parent/21 but for now let's leave as is - parent-child relationship is much less relevant than normal dependencies. What's most important is `log4j/log4j/1.2.12/.tracking/org.apache.maven.plugins_maven-compiler-plugin_jar_3.1.dep` file with: ``` log4j:log4j:jar:1.2.12 (compile) (plugin) org.apache.xbean:xbean-reflect:jar:3.4 (compile) (plugin) org.codehaus.plexus:plexus-container-default:jar:1.5.5 (compile) (plugin) org.apache.maven.plugins:maven-compiler-plugin:jar:3.1 () (plugin) Repository: central (https://repo.maven.apache.org/maven2, default, releases) ``` > Provide contextual data in trace data for collector invoked requests > > > Key: MRESOLVER-262 > URL: https://issues.apache.org/jira/browse/MRESOLVER-262 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Priority: Major > Fix For: 1.8.1 > > > During collection several RepositoryEvents are fired, but they does not carry > any context related data regarding artifact collection. > Simplest solution would be to extend RequestTrace to provide: > * request context > * the artifact path (from root to leaf) > * leaf artifact being collected -- This message was sent by Atlassian Jira (v8.20.7#820007)
