[jira] [Commented] (MBUILDCACHE-32) Do not print exception when probing builds in remote repo
[
https://issues.apache.org/jira/browse/MBUILDCACHE-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742659#comment-17742659
]
ASF GitHub Bot commented on MBUILDCACHE-32:
---
ferdnyc commented on code in PR #33:
URL:
https://github.com/apache/maven-build-cache-extension/pull/33#discussion_r1261966151
##
src/main/java/org/apache/maven/buildcache/RemoteCacheRepositoryImpl.java:
##
@@ -165,9 +166,28 @@ public Optional getResourceContent( String url )
throws IOException
transporter.get( task );
return Optional.of( task.getDataBytes() );
}
+catch ( ResourceDoesNotExistException e )
+{
+if ( LOGGER.isDebugEnabled() )
+{
+LOGGER.debug( "Cache item not found: {}", getFullUrl( url ), e
);
+}
+else
+{
+LOGGER.info( "Cache item not found: {}", getFullUrl( url ) );
+}
+return Optional.empty();
+}
catch ( Exception e )
{
-LOGGER.info( "Cannot download {}", getFullUrl( url ), e );
+if ( LOGGER.isDebugEnabled() )
+{
+LOGGER.debug( "Cannot download cache item {}", getFullUrl( url
), e );
+}
+else
+{
+LOGGER.error( "Cannot download cache item {}: {}", getFullUrl(
url ), e );
+}
Review Comment:
@alexthomasmc Is this the remote cache "not working", though, or can this
also just represent a cache miss / expired cache?
Cache misses certainly are not errors, heck they're not even problems,
they're a standard aspect of how caching works. Data stored in a cache can be
wiped out at any moment, for any reason (or even no reason at all). Caches go
missing all the time.
When a build system fails to obtain a cached artifact, it simply needs to
generate it anew. It can do that, it has the technology.
> Do not print exception when probing builds in remote repo
> -
>
> Key: MBUILDCACHE-32
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-32
> Project: Maven Build Cache Extension
> Issue Type: Bug
>Reporter: Alexander Ashitkin
>Priority: Major
> Labels: pull-request-available
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> When cache engine tries to discover existing cache by checksum, it sends get
> request.
> This request is normally getting 404s, because cache is not guaranteed to
> exist.
> It's a normal situation and exception should not be printed in such case as
> it meaninglessly pollutes logs:
> {code:java}
> org.apache.maven.wagon.ResourceDoesNotExistException: resource missing at
> https://my-cache/.../buildinfo.xml, status: 404 Not Found
> at
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1191)
> at
> org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillInputData
> (AbstractHttpClientWagon.java:1140)
> at org.apache.maven.wagon.StreamWagon.getInputStream
> (StreamWagon.java:126)
> at org.apache.maven.wagon.StreamWagon.getIfNewerToStream
> (StreamWagon.java:226)
> at org.apache.maven.wagon.StreamWagon.getToStream (StreamWagon.java:262)
> at org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run
> (WagonTransporter.java:533)
> at org.eclipse.aether.transport.wagon.WagonTransporter.execute
> (WagonTransporter.java:425)
> at org.eclipse.aether.transport.wagon.WagonTransporter.get
> (WagonTransporter.java:400)
> at
> org.apache.maven.buildcache.RemoteCacheRepositoryImpl.getResourceContent
> (RemoteCacheRepositoryImpl.java:165)
> at org.apache.maven.buildcache.RemoteCacheRepositoryImpl.findBuild
> (RemoteCacheRepositoryImpl.java:114)
> at org.apache.maven.buildcache.LocalCacheRepositoryImpl.findBuild
> (LocalCacheRepositoryImpl.java:183)
> at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild
> (CacheControllerImpl.java:212)
> at org.apache.maven.buildcache.CacheControllerImpl.findCachedBuild
> (CacheControllerImpl.java:179)
> at org.apache.maven.buildcache.BuildCacheMojosExecutionStrategy.execute
> (BuildCacheMojosExecutionStrategy.java:114)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:179)
> {code}
> {{Need to create method similar to
> RemoteCacheRepositoryImpl#getResourceContent, but }}{{getResourceContentQuiet
> and use it when probing buildinfo.xml. the method should not log exceptions}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-build-cache-extension] ferdnyc commented on a diff in pull request #33: [MBUILDCACHE-32] Do not print exception when probing builds
ferdnyc commented on code in PR #33:
URL:
https://github.com/apache/maven-build-cache-extension/pull/33#discussion_r1261966151
##
src/main/java/org/apache/maven/buildcache/RemoteCacheRepositoryImpl.java:
##
@@ -165,9 +166,28 @@ public Optional getResourceContent( String url )
throws IOException
transporter.get( task );
return Optional.of( task.getDataBytes() );
}
+catch ( ResourceDoesNotExistException e )
+{
+if ( LOGGER.isDebugEnabled() )
+{
+LOGGER.debug( "Cache item not found: {}", getFullUrl( url ), e
);
+}
+else
+{
+LOGGER.info( "Cache item not found: {}", getFullUrl( url ) );
+}
+return Optional.empty();
+}
catch ( Exception e )
{
-LOGGER.info( "Cannot download {}", getFullUrl( url ), e );
+if ( LOGGER.isDebugEnabled() )
+{
+LOGGER.debug( "Cannot download cache item {}", getFullUrl( url
), e );
+}
+else
+{
+LOGGER.error( "Cannot download cache item {}: {}", getFullUrl(
url ), e );
+}
Review Comment:
@alexthomasmc Is this the remote cache "not working", though, or can this
also just represent a cache miss / expired cache?
Cache misses certainly are not errors, heck they're not even problems,
they're a standard aspect of how caching works. Data stored in a cache can be
wiped out at any moment, for any reason (or even no reason at all). Caches go
missing all the time.
When a build system fails to obtain a cached artifact, it simply needs to
generate it anew. It can do that, it has the technology.
--
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] (MBUILDCACHE-60) Remove Guava dependency
[ https://issues.apache.org/jira/browse/MBUILDCACHE-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742657#comment-17742657 ] ASF GitHub Bot commented on MBUILDCACHE-60: --- ferdnyc commented on PR #86: URL: https://github.com/apache/maven-build-cache-extension/pull/86#issuecomment-1633517427 I'm with @elharo — I _hate_ merging my own code to a public repo, and will generally only do it if it's a non-code change or I can definitively state that merging won't impact other users. Otherwise, I figure a second pair of eyes is a sensible precaution on almost **any** code change, and when there are multiple people with commit access a good general rule is to have someone other than the PR author do the merge. I try to review others' changes as much as I can, in the hopes they'll return the favor. In that spirit, I've pitched in with an inexpert review of the changes here. > Remove Guava dependency > --- > > Key: MBUILDCACHE-60 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-60 > Project: Maven Build Cache Extension > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-build-cache-extension] ferdnyc commented on pull request #86: [MBUILDCACHE-60] Remove undeclared Guava dependency with Arrays.asList
ferdnyc commented on PR #86: URL: https://github.com/apache/maven-build-cache-extension/pull/86#issuecomment-1633517427 I'm with @elharo — I _hate_ merging my own code to a public repo, and will generally only do it if it's a non-code change or I can definitively state that merging won't impact other users. Otherwise, I figure a second pair of eyes is a sensible precaution on almost **any** code change, and when there are multiple people with commit access a good general rule is to have someone other than the PR author do the merge. I try to review others' changes as much as I can, in the hopes they'll return the favor. In that spirit, I've pitched in with an inexpert review of the changes 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] (MBUILDCACHE-60) Remove Guava dependency
[ https://issues.apache.org/jira/browse/MBUILDCACHE-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742656#comment-17742656 ] ASF GitHub Bot commented on MBUILDCACHE-60: --- ferdnyc commented on code in PR #86: URL: https://github.com/apache/maven-build-cache-extension/pull/86#discussion_r1261953392 ## src/test/java/org/apache/maven/buildcache/LifecyclePhasesHelperTest.java: ## @@ -19,9 +19,9 @@ package org.apache.maven.buildcache; import java.util.ArrayList; Review Comment: I notice you left the `ArrayList` import here (as opposed to in the other files), is that still needed? > Remove Guava dependency > --- > > Key: MBUILDCACHE-60 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-60 > Project: Maven Build Cache Extension > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Minor > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-build-cache-extension] ferdnyc commented on a diff in pull request #86: [MBUILDCACHE-60] Remove undeclared Guava dependency with Arrays.asList
ferdnyc commented on code in PR #86: URL: https://github.com/apache/maven-build-cache-extension/pull/86#discussion_r1261953392 ## src/test/java/org/apache/maven/buildcache/LifecyclePhasesHelperTest.java: ## @@ -19,9 +19,9 @@ package org.apache.maven.buildcache; import java.util.ArrayList; Review Comment: I notice you left the `ArrayList` import here (as opposed to in the other files), is that still needed? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-site] dependabot[bot] closed pull request #427: Bump plantuml from 1.2023.6 to 1.2023.9
dependabot[bot] closed pull request #427: Bump plantuml from 1.2023.6 to 1.2023.9 URL: https://github.com/apache/maven-site/pull/427 -- 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-site] dependabot[bot] opened a new pull request, #436: Bump plantuml from 1.2023.6 to 1.2023.10
dependabot[bot] opened a new pull request, #436: URL: https://github.com/apache/maven-site/pull/436 Bumps [plantuml](https://github.com/plantuml/plantuml) from 1.2023.6 to 1.2023.10. Commits https://github.com/plantuml/plantuml/commit/29bcbfee89bc9df3ab3d2a40194604a157349896;>29bcbfe chore: prepare version 1.2023.10 https://github.com/plantuml/plantuml/commit/835f82a8d670e3dabe4bce2fbf1c362a756c9f9c;>835f82a fix: add together in LanguageDescriptor and improve CommandStyleImport https://github.com/plantuml/plantuml/commit/11b70de43f437245f4bb608207b0c14677dbd46b;>11b70de Merge pull request https://redirect.github.com/plantuml/plantuml/issues/1456;>#1456 from soloturn/java20 https://github.com/plantuml/plantuml/commit/75443a5d286e039fe34fe81a3f27a82612e18365;>75443a5 java-20 deprecates new URL(), use new URI() https://github.com/plantuml/plantuml/commit/32c856503fa3465710153e4fd15da8cc0fdb7000;>32c8565 ignore vscode files https://github.com/plantuml/plantuml/commit/5d445ae80187863aa86177f90646823fa9ddca04;>5d445ae java-20, create uri directly, not via url. https://github.com/plantuml/plantuml/commit/f530bf4d308942d5e8081478f20054e620ff7de5;>f530bf4 java-20, update to gradle-8.2. https://github.com/plantuml/plantuml/commit/ebeea26ecbb71ae5d21468f4e24dfc8f9d215de7;>ebeea26 Merge pull request https://redirect.github.com/plantuml/plantuml/issues/1472;>#1472 from travkin79/patch/1470 https://github.com/plantuml/plantuml/commit/0972786515c7c926e450ad4fec8ad0a4eefc6f21;>0972786 Replace URL with SURL to securely access URLs https://github.com/plantuml/plantuml/commit/b45451312a75b3308195aab7dbf62027394a51e8;>b454513 Merge pull request https://redirect.github.com/plantuml/plantuml/issues/1473;>#1473 from travkin79/patch/1336 Additional commits viewable in https://github.com/plantuml/plantuml/compare/v1.2023.6...v1.2023.10;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7838) Local repository breaks exec plugin
[
https://issues.apache.org/jira/browse/MNG-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742444#comment-17742444
]
ASF GitHub Bot commented on MNG-7838:
-
rmannibucau commented on PR #1199:
URL: https://github.com/apache/maven/pull/1199#issuecomment-1632619278
@gnodet does not look helping much (and didnt manage to get it functional),
guess it is cause it does not take the highest "lastModified" value from
[local-repo, m2/repo] - last one being the aether resolver indeed.
> Local repository breaks exec plugin
> ---
>
> Key: MNG-7838
> URL: https://issues.apache.org/jira/browse/MNG-7838
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-5
>Reporter: Romain Manni-Bucau
>Assignee: Guillaume Nodet
>Priority: Major
>
> Didn't fully investigate but in a multimodule project with modules A and B
> and A used in B with exec plugin (exec:java, add project deps =true), doing
> `cd A && mvn install && cd ../B && mvn package exec:java` keeps using an
> outdated version of A whereas it shouldnt.
>
> here some logs when replacing second command by one from the root module:
>
> {code:java}
> [INFO] --- exec:3.0.0:java (generate-model) @ B ---
> [WARNING] File
> 'app/A/target/classes/com/app/tools/soap/GenerateLightModels$Elt.class' is
> more recent than the packaged artifact for 'A', please run a full `mvn
> package` build
> [WARNING] File
> 'app/A/target/classes/com/app/tools/soap/GenerateLightModels$Elt.class' is
> more recent than the packaged artifact for 'A', please run a full `mvn
> package` build
> [WARNING] File
> 'app/A/target/classes/com/app/tools/soap/GenerateLightModels$Elt.class' is
> more recent than the packaged artifact for 'A', please run a full `mvn
> package` build
> [INFOS]ㅤGenerated 73 files in
> /opt/rmannibucau/dev/app/B/target/generated-sources/models (some.xsd)
> [INFO] {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-383) java.net.SocketException: Connection reset
[
https://issues.apache.org/jira/browse/MRESOLVER-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742303#comment-17742303
]
Konrad Windszus edited comment on MRESOLVER-383 at 7/12/23 2:10 PM:
[~cstamas] Should we rather try to update to HTTP Client 5.x like recommended
in HTTPCLIENT-2282 (which would implicitly support HTTP/2, MRESOLVER-384) and
provide a patch for improved stale connection handling to HTTP Client or come
up with our own solution for the legacy 4.5.x client?
was (Author: kwin):
[~cstamas] Should we rather try to update to HTTP Client 5.x like recommended
in HTTPCLIENT-2282 and provide a patch for improved stale connection handling
to HTTP Client or come up with our own solution for the legacy 4.5.x client?
> java.net.SocketException: Connection reset
> --
>
> Key: MRESOLVER-383
> URL: https://issues.apache.org/jira/browse/MRESOLVER-383
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Konrad Windszus
>Priority: Major
>
> Although in MRESOLVER-361 the retry handler by default is now using
> https://www.javadoc.io/doc/org.apache.httpcomponents/httpclient/latest/org/apache/http/impl/client/StandardHttpRequestRetryHandler.html
> that one still does not sufficiently deal with Connection resets.
> A regular connection reset leads to an exception like the following (without
> any noticable retry attempts)
> {code}
> [ERROR] Failed to execute goal on project vault-davex: Could not resolve
> dependencies for project
> org.apache.jackrabbit.vault:vault-davex:jar:3.6.9-SNAPSHOT: Failed to collect
> dependencies at org.apache.jackrabbit:jackrabbit-jcr-client:jar:2.20.10:
> Failed to read artifact descriptor for
> org.apache.jackrabbit:jackrabbit-jcr-client:jar:2.20.10: The following
> artifacts could not be resolved:
> org.apache.jackrabbit:jackrabbit-jcr-client:pom:2.20.10 (absent): Could not
> transfer artifact org.apache.jackrabbit:jackrabbit-jcr-client:pom:2.20.10
> from/to central (https://repo.maven.apache.org/maven2): Connection reset ->
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project vault-davex: Could not resolve dependencies for project
> org.apache.jackrabbit.vault:vault-davex:jar:3.6.9-SNAPSHOT: Failed to collect
> dependencies at org.apache.jackrabbit:jackrabbit-jcr-client:jar:2.20.10
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:243)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:136)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:355)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:313)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:212)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:174)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:75)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:162)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at
[jira] [Comment Edited] (SUREFIRE-2187) ps -p does not work in alpine or busy box by default
[
https://issues.apache.org/jira/browse/SUREFIRE-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742315#comment-17742315
]
Michael Osipov edited comment on SUREFIRE-2187 at 7/12/23 8:25 AM:
---
It is extremely hard to cover all flavors of {{ps}}.
was (Author: michael-o):
It is extremely hard to cover all flavors of {{ps]].
> ps -p does not work in alpine or busy box by default
>
>
> Key: SUREFIRE-2187
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2187
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0
>Reporter: Martin Sillence
>Priority: Minor
>
> Our builds were failing with the error:
> System.exit() or native command error interrupted process checker.
> java.lang.IllegalStateException: Cannot use PPID 687 process information.
> Going to use NOOP events.
> at
> org.apache.maven.surefire.booter.PpidChecker.checkProcessInfo(PpidChecker.java:155)
> checking the code it looks like you run ps -p:
> [https://github.com/apache/maven-surefire/blob/47eb1974ef2fb77c621e5cb0c47ac10ab8f4753d/surefire-booter/src/main/java/org/apache/maven/surefire/booter/PpidChecker.java#L186C59-L186C71]
>
> installing procps in alipine seems to fix it
>
> I wonder if it is possible add something to check if ps supports the -p flag
> as I imagine I'm not the only one to use alpine to build software?
> Simply adding an error that the ps doesn't support -p would save significant
> time
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2187) ps -p does not work in alpine or busy box by default
[
https://issues.apache.org/jira/browse/SUREFIRE-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742315#comment-17742315
]
Michael Osipov commented on SUREFIRE-2187:
--
It is extremely hard to cover all flavors of {{ps]].
> ps -p does not work in alpine or busy box by default
>
>
> Key: SUREFIRE-2187
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2187
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Maven Surefire Plugin
>Affects Versions: 3.0.0
>Reporter: Martin Sillence
>Priority: Minor
>
> Our builds were failing with the error:
> System.exit() or native command error interrupted process checker.
> java.lang.IllegalStateException: Cannot use PPID 687 process information.
> Going to use NOOP events.
> at
> org.apache.maven.surefire.booter.PpidChecker.checkProcessInfo(PpidChecker.java:155)
> checking the code it looks like you run ps -p:
> [https://github.com/apache/maven-surefire/blob/47eb1974ef2fb77c621e5cb0c47ac10ab8f4753d/surefire-booter/src/main/java/org/apache/maven/surefire/booter/PpidChecker.java#L186C59-L186C71]
>
> installing procps in alipine seems to fix it
>
> I wonder if it is possible add something to check if ps supports the -p flag
> as I imagine I'm not the only one to use alpine to build software?
> Simply adding an error that the ps doesn't support -p would save significant
> time
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742314#comment-17742314
]
Delany edited comment on MRESOLVER-372 at 7/12/23 8:19 AM:
---
Can happen at the end of a large deployAtEnd build (on CI machine)
{code:java}
09:46:47 [INFO] Retrying deployment attempt 3 of 3
...
09:50:10 Caused by: java.nio.file.AccessDeniedException:
maven-metadata--snapshots.xml.12223878285861141839.tmp ->
maven-metadata--snapshots.xml
09:50:10 at sun.nio.fs.WindowsException.translateToIOException
(WindowsException.java:89)
09:50:10 at sun.nio.fs.WindowsException.rethrowAsIOException
(WindowsException.java:103)
09:50:10 at sun.nio.fs.WindowsFileCopy.move (WindowsFileCopy.java:309)
09:50:10 at sun.nio.fs.WindowsFileSystemProvider.move
(WindowsFileSystemProvider.java:292)
09:50:10 at java.nio.file.Files.move (Files.java:1422)
09:50:10 at org.eclipse.aether.util.FileUtils$2.move (FileUtils.java:108)
09:50:10 at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask
(BasicRepositoryConnector.java:500)
09:50:10 at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
(BasicRepositoryConnector.java:414)
09:50:10 at
org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
(BasicRepositoryConnector.java:215)
09:50:10 at org.eclipse.aether.internal.impl.DefaultDeployer.upload
(DefaultDeployer.java:367)
09:50:10 at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
(DefaultDeployer.java:238)
09:50:10 at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
(DefaultDeployer.java:201)
09:50:10 at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy
(DefaultRepositorySystem.java:392)
09:50:10 at org.apache.maven.plugins.deploy.AbstractDeployMojo.deploy
(AbstractDeployMojo.java:139)
09:50:10 at org.apache.maven.plugins.deploy.DeployMojo.deployAllAtOnce
(DeployMojo.java:251)
09:50:10 at org.apache.maven.plugins.deploy.DeployMojo.execute
(DeployMojo.java:218) {code}
Maven 3.9.3
-Daether.syncContext.named.factory=file-lock
-Daether.syncContext.named.nameMapper=file-gav
was (Author: delany):
Can happen at the end of a large deployAtEnd build
{code:java}
09:46:47 [INFO] Retrying deployment attempt 3 of 3
...
09:50:10 Caused by: java.nio.file.AccessDeniedException:
maven-metadata--snapshots.xml.12223878285861141839.tmp ->
maven-metadata--snapshots.xml
09:50:10 at sun.nio.fs.WindowsException.translateToIOException
(WindowsException.java:89)
09:50:10 at sun.nio.fs.WindowsException.rethrowAsIOException
(WindowsException.java:103)
09:50:10 at sun.nio.fs.WindowsFileCopy.move (WindowsFileCopy.java:309)
09:50:10 at sun.nio.fs.WindowsFileSystemProvider.move
(WindowsFileSystemProvider.java:292)
09:50:10 at java.nio.file.Files.move (Files.java:1422)
09:50:10 at org.eclipse.aether.util.FileUtils$2.move (FileUtils.java:108)
09:50:10 at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask
(BasicRepositoryConnector.java:500)
09:50:10 at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
(BasicRepositoryConnector.java:414)
09:50:10 at
org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
(BasicRepositoryConnector.java:215)
09:50:10 at org.eclipse.aether.internal.impl.DefaultDeployer.upload
(DefaultDeployer.java:367)
09:50:10 at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
(DefaultDeployer.java:238)
09:50:10 at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
(DefaultDeployer.java:201)
09:50:10 at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy
(DefaultRepositorySystem.java:392)
09:50:10 at org.apache.maven.plugins.deploy.AbstractDeployMojo.deploy
(AbstractDeployMojo.java:139)
09:50:10 at org.apache.maven.plugins.deploy.DeployMojo.deployAllAtOnce
(DeployMojo.java:251)
09:50:10 at org.apache.maven.plugins.deploy.DeployMojo.execute
(DeployMojo.java:218) {code}
Maven 3.9.3
-Daether.syncContext.named.factory=file-lock
-Daether.syncContext.named.nameMapper=file-gav
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Major
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
>
[jira] [Created] (SUREFIRE-2187) ps -p does not work in alpine or busy box by default
Martin Sillence created SUREFIRE-2187: - Summary: ps -p does not work in alpine or busy box by default Key: SUREFIRE-2187 URL: https://issues.apache.org/jira/browse/SUREFIRE-2187 Project: Maven Surefire Issue Type: New Feature Components: Maven Surefire Plugin Affects Versions: 3.0.0 Reporter: Martin Sillence Our builds were failing with the error: System.exit() or native command error interrupted process checker. java.lang.IllegalStateException: Cannot use PPID 687 process information. Going to use NOOP events. at org.apache.maven.surefire.booter.PpidChecker.checkProcessInfo(PpidChecker.java:155) checking the code it looks like you run ps -p: [https://github.com/apache/maven-surefire/blob/47eb1974ef2fb77c621e5cb0c47ac10ab8f4753d/surefire-booter/src/main/java/org/apache/maven/surefire/booter/PpidChecker.java#L186C59-L186C71] installing procps in alipine seems to fix it I wonder if it is possible add something to check if ps supports the -p flag as I imagine I'm not the only one to use alpine to build software? Simply adding an error that the ps doesn't support -p would save significant time -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742314#comment-17742314
]
Delany commented on MRESOLVER-372:
--
Can happen at the end of a large deployAtEnd build
{code:java}
09:46:47 [INFO] Retrying deployment attempt 3 of 3
...
09:50:10 Caused by: java.nio.file.AccessDeniedException:
maven-metadata--snapshots.xml.12223878285861141839.tmp ->
maven-metadata--snapshots.xml
09:50:10 at sun.nio.fs.WindowsException.translateToIOException
(WindowsException.java:89)
09:50:10 at sun.nio.fs.WindowsException.rethrowAsIOException
(WindowsException.java:103)
09:50:10 at sun.nio.fs.WindowsFileCopy.move (WindowsFileCopy.java:309)
09:50:10 at sun.nio.fs.WindowsFileSystemProvider.move
(WindowsFileSystemProvider.java:292)
09:50:10 at java.nio.file.Files.move (Files.java:1422)
09:50:10 at org.eclipse.aether.util.FileUtils$2.move (FileUtils.java:108)
09:50:10 at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask
(BasicRepositoryConnector.java:500)
09:50:10 at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
(BasicRepositoryConnector.java:414)
09:50:10 at
org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
(BasicRepositoryConnector.java:215)
09:50:10 at org.eclipse.aether.internal.impl.DefaultDeployer.upload
(DefaultDeployer.java:367)
09:50:10 at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
(DefaultDeployer.java:238)
09:50:10 at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
(DefaultDeployer.java:201)
09:50:10 at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy
(DefaultRepositorySystem.java:392)
09:50:10 at org.apache.maven.plugins.deploy.AbstractDeployMojo.deploy
(AbstractDeployMojo.java:139)
09:50:10 at org.apache.maven.plugins.deploy.DeployMojo.deployAllAtOnce
(DeployMojo.java:251)
09:50:10 at org.apache.maven.plugins.deploy.DeployMojo.execute
(DeployMojo.java:218) {code}
Maven 3.9.3
-Daether.syncContext.named.factory=file-lock
-Daether.syncContext.named.nameMapper=file-gav
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Christoph Läubrich
>Priority: Major
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> at java.base/java.nio.file.Files.move(Files.java:1432)
> at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-383) java.net.SocketException: Connection reset
[
https://issues.apache.org/jira/browse/MRESOLVER-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742303#comment-17742303
]
Konrad Windszus commented on MRESOLVER-383:
---
[~cstamas] Should we rather try to update to HTTP Client 5.x like recommended
in HTTPCLIENT-2282 and provide a patch for improved stale connection handling
to HTTP Client or come up with our own solution for the legacy 4.5.x client?
> java.net.SocketException: Connection reset
> --
>
> Key: MRESOLVER-383
> URL: https://issues.apache.org/jira/browse/MRESOLVER-383
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 1.9.13
>Reporter: Konrad Windszus
>Priority: Major
>
> Although in MRESOLVER-361 the retry handler by default is now using
> https://www.javadoc.io/doc/org.apache.httpcomponents/httpclient/latest/org/apache/http/impl/client/StandardHttpRequestRetryHandler.html
> that one still does not sufficiently deal with Connection resets.
> A regular connection reset leads to an exception like the following (without
> any noticable retry attempts)
> {code}
> [ERROR] Failed to execute goal on project vault-davex: Could not resolve
> dependencies for project
> org.apache.jackrabbit.vault:vault-davex:jar:3.6.9-SNAPSHOT: Failed to collect
> dependencies at org.apache.jackrabbit:jackrabbit-jcr-client:jar:2.20.10:
> Failed to read artifact descriptor for
> org.apache.jackrabbit:jackrabbit-jcr-client:jar:2.20.10: The following
> artifacts could not be resolved:
> org.apache.jackrabbit:jackrabbit-jcr-client:pom:2.20.10 (absent): Could not
> transfer artifact org.apache.jackrabbit:jackrabbit-jcr-client:pom:2.20.10
> from/to central (https://repo.maven.apache.org/maven2): Connection reset ->
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project vault-davex: Could not resolve dependencies for project
> org.apache.jackrabbit.vault:vault-davex:jar:3.6.9-SNAPSHOT: Failed to collect
> dependencies at org.apache.jackrabbit:jackrabbit-jcr-client:jar:2.20.10
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:243)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:136)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:355)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:313)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:212)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:174)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:75)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:162)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:348)
> Caused by:
[jira] [Commented] (MSOURCES-137) umask makes artifacts generated by maven-source-plugin not easy to reproduce
[
https://issues.apache.org/jira/browse/MSOURCES-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742302#comment-17742302
]
Herve Boutemy commented on MSOURCES-137:
root cause found in plexus-archiver
https://github.com/codehaus-plexus/plexus-archiver/pull/293
> umask makes artifacts generated by maven-source-plugin not easy to reproduce
>
>
> Key: MSOURCES-137
> URL: https://issues.apache.org/jira/browse/MSOURCES-137
> Project: Maven Source Plugin
> Issue Type: Improvement
>Affects Versions: 3.3.0
>Reporter: Andreas Veithen
>Priority: Minor
>
> It appears that inside the archive created by maven-source-plugin, the
> permissions of {{META-INF/maven/\*/\*/pom.properties}} depend on the current
> umask.
> Steps to reproduce:
> {code:java}
> $ umask 022
> $ mvn clean install
> $ umask 002
> $ mvn clean verify artifact:compare
> {code}
> This can be used on any project attaching a source jar (e.g.
> [https://github.com/apache/ws-axiom/]).
> Example diffoscope output:
> {code:java}
> --- target/reference/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar
> +++ target/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar
> │┄ Archive contents identical but files differ, possibly due to different
> compression levels. Falling back to binary comparison.
> ├── zipinfo {}
> │ @@ -14,9 +14,9 @@
> │ -rw-r--r-- 2.0 unx 170 b- defN 22-Mar-13 11:17 META-INF/NOTICE
> │ -rw-r--r-- 2.0 unx 1365 b- defN 22-Mar-13 11:17
> org/apache/axiom/weaver/annotation/FactoryMethod.java
> │ -rw-r--r-- 2.0 unx 1101 b- defN 22-Mar-13 11:17
> org/apache/axiom/weaver/annotation/Inject.java
> │ -rw-r--r-- 2.0 unx 1095 b- defN 22-Mar-13 11:17
> org/apache/axiom/weaver/annotation/Mixin.java
> │ -rw-r--r-- 2.0 unx 1100 b- defN 22-Mar-13 11:17
> org/apache/axiom/weaver/annotation/Singleton.java
> │ -rw-r--r-- 2.0 unx 1136 b- defN 22-Mar-13 11:17
> org/apache/axiom/weaver/annotation/WeavablePackage.java
> │ -rw-r--r-- 2.0 unx 1411 b- defN 22-Mar-13 11:17
> META-INF/maven/org.apache.ws.commons.axiom/axiom-weaver-annotations/pom.xml
> │ --rw-r--r-- 2.0 unx 95 b- defN 22-Mar-13 11:17
> META-INF/maven/org.apache.ws.commons.axiom/axiom-weaver-annotations/pom.properties
> │ +-rw-rw-r-- 2.0 unx 95 b- defN 22-Mar-13 11:17
> META-INF/maven/org.apache.ws.commons.axiom/axiom-weaver-annotations/pom.properties
> │ 20 files, 19157 bytes uncompressed, 8089 bytes compressed: 57.8%
> │ --- target/reference/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar
> ├── +++ target/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar
> │ @@ -676,15 +676,15 @@
> │ 2a30: a481 b020 4d45 5441 . ..META
> │ 2a40: 2d49 4e46 2f6d 6176 656e 2f6f 7267 2e61 -INF/maven/org.a
> │ 2a50: 7061 6368 652e 7773 2e63 6f6d 6d6f 6e73 pache.ws.commons
> │ 2a60: 2e61 7869 6f6d 2f61 7869 6f6d 2d77 6561 .axiom/axiom-wea
> │ 2a70: 7665 722d 616e 6e6f 7461 7469 6f6e 732f ver-annotations/
> │ 2a80: 706f 6d2e 786d 6c50 4b01 0214 0314 pom.xmlPK...
> │ 2a90: 0808 0022 5a6d 54b9 68bb 2558 005f ..."ZmT.h.%X..._
> │ -2aa0: 0052 00a4 ...R
> │ +2aa0: 0052 00b4 ...R
> │ 2ab0: 81e8 2300 004d 4554 412d 494e 462f 6d61 ..#..META-INF/ma
> │ 2ac0: 7665 6e2f 6f72 672e 6170 6163 6865 2e77 ven/org.apache.w
> │ 2ad0: 732e 636f 6d6d 6f6e 732e 6178 696f 6d2f s.commons.axiom/
> │ 2ae0: 6178 696f 6d2d 7765 6176 6572 2d61 6e6e axiom-weaver-ann
> │ 2af0: 6f74 6174 696f 6e73 2f70 6f6d 2e70 726f otations/pom.pro
> │ 2b00: 7065 7274 6965 7350 4b05 0600 0014 pertiesPK...
> │ 2b10: 0014 0057 0600 00b0 2400 00 ...W$
> {code}
> Note that although maven-jar-plugin adds the same {{pom.properties}} file to
> the archive, it isn't affected by this problem.
> I discovered this while trying to check the reproducibility of Apache Axiom
> builds in a Github Codespace, where file permissions are set in a peculiar
> way; see [https://github.com/orgs/community/discussions/26026].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSOURCES-137) umask makes artifacts generated by maven-source-plugin not easy to reproduce
[
https://issues.apache.org/jira/browse/MSOURCES-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742290#comment-17742290
]
Herve Boutemy commented on MSOURCES-137:
while testing, I found that m-source-p 3.2.1 was having the expected behaviour,
but 3.3.0 injected the current issue
> umask makes artifacts generated by maven-source-plugin not easy to reproduce
>
>
> Key: MSOURCES-137
> URL: https://issues.apache.org/jira/browse/MSOURCES-137
> Project: Maven Source Plugin
> Issue Type: Improvement
>Affects Versions: 3.3.0
>Reporter: Andreas Veithen
>Priority: Minor
>
> It appears that inside the archive created by maven-source-plugin, the
> permissions of {{META-INF/maven/\*/\*/pom.properties}} depend on the current
> umask.
> Steps to reproduce:
> {code:java}
> $ umask 022
> $ mvn clean install
> $ umask 002
> $ mvn clean verify artifact:compare
> {code}
> This can be used on any project attaching a source jar (e.g.
> [https://github.com/apache/ws-axiom/]).
> Example diffoscope output:
> {code:java}
> --- target/reference/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar
> +++ target/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar
> │┄ Archive contents identical but files differ, possibly due to different
> compression levels. Falling back to binary comparison.
> ├── zipinfo {}
> │ @@ -14,9 +14,9 @@
> │ -rw-r--r-- 2.0 unx 170 b- defN 22-Mar-13 11:17 META-INF/NOTICE
> │ -rw-r--r-- 2.0 unx 1365 b- defN 22-Mar-13 11:17
> org/apache/axiom/weaver/annotation/FactoryMethod.java
> │ -rw-r--r-- 2.0 unx 1101 b- defN 22-Mar-13 11:17
> org/apache/axiom/weaver/annotation/Inject.java
> │ -rw-r--r-- 2.0 unx 1095 b- defN 22-Mar-13 11:17
> org/apache/axiom/weaver/annotation/Mixin.java
> │ -rw-r--r-- 2.0 unx 1100 b- defN 22-Mar-13 11:17
> org/apache/axiom/weaver/annotation/Singleton.java
> │ -rw-r--r-- 2.0 unx 1136 b- defN 22-Mar-13 11:17
> org/apache/axiom/weaver/annotation/WeavablePackage.java
> │ -rw-r--r-- 2.0 unx 1411 b- defN 22-Mar-13 11:17
> META-INF/maven/org.apache.ws.commons.axiom/axiom-weaver-annotations/pom.xml
> │ --rw-r--r-- 2.0 unx 95 b- defN 22-Mar-13 11:17
> META-INF/maven/org.apache.ws.commons.axiom/axiom-weaver-annotations/pom.properties
> │ +-rw-rw-r-- 2.0 unx 95 b- defN 22-Mar-13 11:17
> META-INF/maven/org.apache.ws.commons.axiom/axiom-weaver-annotations/pom.properties
> │ 20 files, 19157 bytes uncompressed, 8089 bytes compressed: 57.8%
> │ --- target/reference/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar
> ├── +++ target/axiom-weaver-annotations-2.0.0-SNAPSHOT-sources.jar
> │ @@ -676,15 +676,15 @@
> │ 2a30: a481 b020 4d45 5441 . ..META
> │ 2a40: 2d49 4e46 2f6d 6176 656e 2f6f 7267 2e61 -INF/maven/org.a
> │ 2a50: 7061 6368 652e 7773 2e63 6f6d 6d6f 6e73 pache.ws.commons
> │ 2a60: 2e61 7869 6f6d 2f61 7869 6f6d 2d77 6561 .axiom/axiom-wea
> │ 2a70: 7665 722d 616e 6e6f 7461 7469 6f6e 732f ver-annotations/
> │ 2a80: 706f 6d2e 786d 6c50 4b01 0214 0314 pom.xmlPK...
> │ 2a90: 0808 0022 5a6d 54b9 68bb 2558 005f ..."ZmT.h.%X..._
> │ -2aa0: 0052 00a4 ...R
> │ +2aa0: 0052 00b4 ...R
> │ 2ab0: 81e8 2300 004d 4554 412d 494e 462f 6d61 ..#..META-INF/ma
> │ 2ac0: 7665 6e2f 6f72 672e 6170 6163 6865 2e77 ven/org.apache.w
> │ 2ad0: 732e 636f 6d6d 6f6e 732e 6178 696f 6d2f s.commons.axiom/
> │ 2ae0: 6178 696f 6d2d 7765 6176 6572 2d61 6e6e axiom-weaver-ann
> │ 2af0: 6f74 6174 696f 6e73 2f70 6f6d 2e70 726f otations/pom.pro
> │ 2b00: 7065 7274 6965 7350 4b05 0600 0014 pertiesPK...
> │ 2b10: 0014 0057 0600 00b0 2400 00 ...W$
> {code}
> Note that although maven-jar-plugin adds the same {{pom.properties}} file to
> the archive, it isn't affected by this problem.
> I discovered this while trying to check the reproducibility of Apache Axiom
> builds in a Github Codespace, where file permissions are set in a peculiar
> way; see [https://github.com/orgs/community/discussions/26026].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7532) Revert MNG-6931 deprecation since list shows no consensus on that
[
https://issues.apache.org/jira/browse/MNG-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742287#comment-17742287
]
ASF GitHub Bot commented on MNG-7532:
-
rmannibucau commented on PR #793:
URL: https://github.com/apache/maven/pull/793#issuecomment-1631926675
@gnodet let's ignore a second the classloading errors and take a simple
functional case: you want logger X to be logged particularly and the app knows
the provider it uses so can configure it directly - this is a common case as we
discussed on slack. I'll use JUL binding for the example but it is not rare it
is logback or log4j2 too.
Do we want to say to users "no, will never work until you implement another
classloading abstraction to isolate yourself from plugin ecosystem"? Not on my
side.
Here is a simple mojo showing it:
```pom.xml
org.slf4j
slf4j-api
1.7.36
org.slf4j
slf4j-jdk14
1.7.36
```
```java
@Mojo(name = "demo", defaultPhase = NONE)
public class MyMojo extends AbstractMojo {
@Override
public void execute() {
run();
}
private void run() {
final var loggerName = getClass().getName();
final var logger = Logger.getLogger(loggerName);
final var delegate = Logger.getLogger("");
logger.addHandler(new Handler() {
@Override
public void publish(final LogRecord record) { // just a hack to
get console logger but not close it
delegate.getHandlers()[0].publish(record);
}
@Override
public void flush() {
// no-op
}
@Override
public void close() throws SecurityException {
// no-op
}
});
LoggerFactory.getLogger(loggerName)
.info("I am here");
}
}
```
Indeed you have to assume the logging configuration is not part of the
execute method but a transitive one - a bit like spring logging system.
Running this mojo we get:
```
[INFO] -
> Revert MNG-6931 deprecation since list shows no consensus on that
> -
>
> Key: MNG-7532
> URL: https://issues.apache.org/jira/browse/MNG-7532
> Project: Maven
> Issue Type: Task
>Reporter: Romain Manni-Bucau
>Priority: Major
>
> There are several threads on the dev list asking for the drop of slf4j and at
> least keeping a logging abstraction for not internal dev (= core can use
> slf4j but not mojo/extensions).
> Work is being done to abstract plugin api so let's keep the
> deprecation/replacement of our Log API in this track and keep it the official
> way for now.
> one of the multiple refs:
> https://www.mail-archive.com/dev@maven.apache.org/msg123452.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] rmannibucau commented on pull request #793: [MNG-7532] Log shouldn't have been deprecated so ensure it is not
rmannibucau commented on PR #793:
URL: https://github.com/apache/maven/pull/793#issuecomment-1631926675
@gnodet let's ignore a second the classloading errors and take a simple
functional case: you want logger X to be logged particularly and the app knows
the provider it uses so can configure it directly - this is a common case as we
discussed on slack. I'll use JUL binding for the example but it is not rare it
is logback or log4j2 too.
Do we want to say to users "no, will never work until you implement another
classloading abstraction to isolate yourself from plugin ecosystem"? Not on my
side.
Here is a simple mojo showing it:
```pom.xml
org.slf4j
slf4j-api
1.7.36
org.slf4j
slf4j-jdk14
1.7.36
```
```java
@Mojo(name = "demo", defaultPhase = NONE)
public class MyMojo extends AbstractMojo {
@Override
public void execute() {
run();
}
private void run() {
final var loggerName = getClass().getName();
final var logger = Logger.getLogger(loggerName);
final var delegate = Logger.getLogger("");
logger.addHandler(new Handler() {
@Override
public void publish(final LogRecord record) { // just a hack to
get console logger but not close it
delegate.getHandlers()[0].publish(record);
}
@Override
public void flush() {
// no-op
}
@Override
public void close() throws SecurityException {
// no-op
}
});
LoggerFactory.getLogger(loggerName)
.info("I am here");
}
}
```
Indeed you have to assume the logging configuration is not part of the
execute method but a transitive one - a bit like spring logging system.
Running this mojo we get:
```
[INFO] --- demo:0.0.1-SNAPSHOT:demo (run) @ consumer ---
[INFO] I am here
```
Which is not really the expectation:
```
juil. 12, 2023 8:24:12 AM com.github.rmannibucau.maven.reproducer.Main main
INFO: I am in xml
juil. 12, 2023 8:24:12 AM com.github.rmannibucau.maven.reproducer.Main main
INFO: I am in xml
```
So we can see that the format is wrong - which can be an issue for downside
parsing, the plugin will not enable to test grokking for ex, but the setup is
not even respected in maven (the duplicated log is an intentional coding bug
but does not surface with maven). Worse, maven ignores
`logger.setUseParentHandlers(false);` code - which is intended to fix the
duplicated line.
So maven does not enable to do any log related work there.
So I really think we should give the control of that to mojo:
* slf4j can be imported or not in the limit of the strict API - not the SPI
* JUL should likely be isolated like in tomcat per mojo - default = inherit
but a toggle would enable to let the plugin use its own config/custom logging
manager if the system prop is set there (by delegation we can do it)
The last trick we'll see - since we spoke of slf4j 2 - is that it does not
use its classloading custom lookup anymore for the logger factory but a plain
ServiceLoader JPMS based so ClassRealm is not ready for that at all. Guess
we'll need to work on that at some point so I don't think we'll need a
workaround in our SLF4J impl to delegate to plugin impl if any but means we
will still have some issues with slf4j.
Hope it helps
--
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
