[jira] [Commented] (MPOM-344) Update maven-remote-resources-plugin to 3.1.0
[ https://issues.apache.org/jira/browse/MPOM-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696416#comment-17696416 ] Herve Boutemy commented on MPOM-344: [~rec] you're right: this one is an issue for MASFRES, and will probably require to ask Sonatype to fix data in Maven Central... > Update maven-remote-resources-plugin to 3.1.0 > - > > Key: MPOM-344 > URL: https://issues.apache.org/jira/browse/MPOM-344 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf >Affects Versions: ASF-29 >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: ASF-30 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPOM-344) Update maven-remote-resources-plugin to 3.1.0
[ https://issues.apache.org/jira/browse/MPOM-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MPOM-344: --- Affects Version/s: ASF-29 > Update maven-remote-resources-plugin to 3.1.0 > - > > Key: MPOM-344 > URL: https://issues.apache.org/jira/browse/MPOM-344 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf >Affects Versions: ASF-29 >Reporter: Sylwester Lachiewicz >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPOM-344) Update maven-remote-resources-plugin to 3.1.0
[ https://issues.apache.org/jira/browse/MPOM-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MPOM-344: --- Fix Version/s: ASF-30 > Update maven-remote-resources-plugin to 3.1.0 > - > > Key: MPOM-344 > URL: https://issues.apache.org/jira/browse/MPOM-344 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf >Affects Versions: ASF-29 >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: ASF-30 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRRESOURCES-125) Unexpected warnings "Invalid project model for artifact [sisu-guice:org.sonatype.sisu:3.2.3]. It will be ignored by the remote resources Mojo."
[ https://issues.apache.org/jira/browse/MRRESOURCES-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MRRESOURCES-125. - Fix Version/s: 3.1.0 Assignee: Olivier Lamy Resolution: Duplicate Olivier already fixed it in MRRESOURCES-121 , just requires 3.1.0 to be released > Unexpected warnings "Invalid project model for artifact > [sisu-guice:org.sonatype.sisu:3.2.3]. It will be ignored by the remote > resources Mojo." > --- > > Key: MRRESOURCES-125 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-125 > Project: Maven Remote Resources Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Guillaume Nodet >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.1.0 > > > I have a bunch of warnings when building m-plugin-tools, during the > m-remote-resources-p execution. They look like > {code} > [WARN] Invalid project model for artifact > [sisu-guice:org.sonatype.sisu:3.2.3]. It will be ignored by the remote > resources Mojo. > {code} > but are related to errors like > {code} > [ERROR] Failed to determine Java version for profile jdk7-plugin-fix-version > @ org.apache.commons:commons-parent:39, > /Users/gnodet/.m2/repository/org/apache/commons/commons-parent/39/commons-parent-39.pom, > line 1343, column 14 > {code} > The pom looks like: > {code} > > [1.7,) > > {code} > Also the warning uses {{artifactId:groupId:version}} instead of the more used > {{groupId:artifactId:version}} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRRESOURCES-125) Unexpected warnings "Invalid project model for artifact [sisu-guice:org.sonatype.sisu:3.2.3]. It will be ignored by the remote resources Mojo."
[ https://issues.apache.org/jira/browse/MRRESOURCES-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696413#comment-17696413 ] Herve Boutemy commented on MRRESOURCES-125: --- same cause as MPIR-429 and MDEP-630: same solution to be applied :) > Unexpected warnings "Invalid project model for artifact > [sisu-guice:org.sonatype.sisu:3.2.3]. It will be ignored by the remote > resources Mojo." > --- > > Key: MRRESOURCES-125 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-125 > Project: Maven Remote Resources Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Guillaume Nodet >Priority: Major > > I have a bunch of warnings when building m-plugin-tools, during the > m-remote-resources-p execution. They look like > {code} > [WARN] Invalid project model for artifact > [sisu-guice:org.sonatype.sisu:3.2.3]. It will be ignored by the remote > resources Mojo. > {code} > but are related to errors like > {code} > [ERROR] Failed to determine Java version for profile jdk7-plugin-fix-version > @ org.apache.commons:commons-parent:39, > /Users/gnodet/.m2/repository/org/apache/commons/commons-parent/39/commons-parent-39.pom, > line 1343, column 14 > {code} > The pom looks like: > {code} > > [1.7,) > > {code} > Also the warning uses {{artifactId:groupId:version}} instead of the more used > {{groupId:artifactId:version}} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7719) Maven 3.9.0 native http transport ignores username/password for basic auth
[ https://issues.apache.org/jira/browse/MNG-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Gent updated MNG-7719: --- Description: In 3.9.0 the default maven http transport switched from wagon to native. It appears that the native transport does not respect: {code:xml} some-repo some-username basic-auth-password {code} Now when you do a mvn deploy to some-repo the basic auth headers are missing. This is probably causing github package problems: https://github.com/orgs/community/discussions/49001 - The issue appears to be that the native client respects Basic Auth Challenges and our server did not do that (it never sends the WWW-Authenticate) as the original Wagon HTTP transport did not need it. The wagon version will always send the credentials on PUT and POST but no credentials on GET of maven metadata. The wagon version basically is like a header API key when doing basic auth instead of the true basic auth workflow. For whatever reason I removed the WWW-Authenticate header probably for security reasons. Since the native client is doing technically the right thing this is not a bug however it would be nice if there was some option to revert to the old behavior as it does save a round trip on PUT (a 401 needs to happen with the header before native will send credentials). was: In 3.9.0 the default maven http transport switched from wagon to native. It appears that the native transport does not respect: {code:xml} some-repo some-username basic-auth-password {code} Now when you do a mvn deploy to some-repo the basic auth headers are missing. This is probably causing github package problems: https://github.com/orgs/community/discussions/49001 - The issue appears to > Maven 3.9.0 native http transport ignores username/password for basic auth > -- > > Key: MNG-7719 > URL: https://issues.apache.org/jira/browse/MNG-7719 > Project: Maven > Issue Type: Improvement > Components: Core, Deployment >Affects Versions: 3.9.0 >Reporter: Adam Gent >Priority: Major > Fix For: waiting-for-feedback > > > In 3.9.0 the default maven http transport switched from wagon to native. > It appears that the native transport does not respect: > {code:xml} > > some-repo > some-username > basic-auth-password > > {code} > Now when you do a mvn deploy to some-repo the basic auth headers are missing. > This is probably causing github package problems: > https://github.com/orgs/community/discussions/49001 > - > The issue appears to be that the native client respects Basic Auth Challenges > and our server did not do that (it never sends the WWW-Authenticate) as the > original Wagon HTTP transport did not need it. > The wagon version will always send the credentials on PUT and POST but no > credentials on GET of maven metadata. > The wagon version basically is like a header API key when doing basic auth > instead of the true basic auth workflow. > For whatever reason I removed the WWW-Authenticate header probably for > security reasons. > Since the native client is doing technically the right thing this is not a > bug however it would be nice if there was some option to revert to the old > behavior as it does save a round trip on PUT (a 401 needs to happen with the > header before native will send credentials). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7719) Maven 3.9.0 native http transport ignores username/password for basic auth
[ https://issues.apache.org/jira/browse/MNG-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Gent updated MNG-7719: --- Description: In 3.9.0 the default maven http transport switched from wagon to native. It appears that the native transport does not respect: {code:xml} some-repo some-username basic-auth-password {code} Now when you do a mvn deploy to some-repo the basic auth headers are missing. This is probably causing github package problems: https://github.com/orgs/community/discussions/49001 - The issue appears to was: In 3.9.0 the default maven http transport switched from wagon to native. It appears that the native transport does not respect: {code:xml} some-repo some-username basic-auth-password {code} Now when you do a mvn deploy to some-repo the basic auth headers are missing. This is probably causing github package problems: https://github.com/orgs/community/discussions/49001 > Maven 3.9.0 native http transport ignores username/password for basic auth > -- > > Key: MNG-7719 > URL: https://issues.apache.org/jira/browse/MNG-7719 > Project: Maven > Issue Type: Improvement > Components: Core, Deployment >Affects Versions: 3.9.0 >Reporter: Adam Gent >Priority: Major > Fix For: waiting-for-feedback > > > In 3.9.0 the default maven http transport switched from wagon to native. > It appears that the native transport does not respect: > {code:xml} > > some-repo > some-username > basic-auth-password > > {code} > Now when you do a mvn deploy to some-repo the basic auth headers are missing. > This is probably causing github package problems: > https://github.com/orgs/community/discussions/49001 > - > The issue appears to -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7719) Maven 3.9.0 native http transport ignores username/password for basic auth
[ https://issues.apache.org/jira/browse/MNG-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696352#comment-17696352 ] Adam Gent commented on MNG-7719: Per github it appears that the native client respects Basic Auth Challenges and our server did not do that (it never sends the WWW-Authenticate). The wagon version will always send the credentials on PUT an POST. The wagon version basically is like a header API key when doing basic auth instead of the true basic auth workflow. Consequently I suppose this is not a bug. > Maven 3.9.0 native http transport ignores username/password for basic auth > -- > > Key: MNG-7719 > URL: https://issues.apache.org/jira/browse/MNG-7719 > Project: Maven > Issue Type: Improvement > Components: Core, Deployment >Affects Versions: 3.9.0 >Reporter: Adam Gent >Priority: Major > Fix For: waiting-for-feedback > > > In 3.9.0 the default maven http transport switched from wagon to native. > It appears that the native transport does not respect: > {code:xml} > > some-repo > some-username > basic-auth-password > > {code} > Now when you do a mvn deploy to some-repo the basic auth headers are missing. > This is probably causing github package problems: > https://github.com/orgs/community/discussions/49001 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRRESOURCES-123) Maven Remote Resources Plugin cannot load resource bundle from remote repository
[ https://issues.apache.org/jira/browse/MRRESOURCES-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696345#comment-17696345 ] Tamas Cservenak commented on MRRESOURCES-123: - Confirmed, 3.0.0 seems broken, and moreover, it fails badly with Maven 3.9.1-SNAPSHOT (the IT run) > Maven Remote Resources Plugin cannot load resource bundle from remote > repository > > > Key: MRRESOURCES-123 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-123 > Project: Maven Remote Resources Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Andrei Mizurou >Priority: Major > > After upgrading from 1.7.0 to 3.0.0, the application is unable to download > the resourceBundle from a custom remote repository which is defined in > `pom.xml`. We got the following error: > > {code:java} > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-remote-resources-plugin:3.0.0:process' with > basic configurator --> > [DEBUG] (f) appendedResourcesDirectory = > /Users/myuser/workdir/projects/myservice/src/main/appended-resources > [DEBUG] (f) attachToMain = false > [DEBUG] (f) attachToTest = false > [DEBUG] (f) basedir = /Users/myuser/workdir/projects/myservice > [DEBUG] (f) encoding = UTF-8 > [DEBUG] (f) excludeTransitive = false > [DEBUG] (f) includeProjectProperties = false > [DEBUG] (f) includeScope = runtime > [DEBUG] (f) localRepository = id: local > url: file:///Users/myuser/.m2/repository/ > layout: default > snapshots: [enabled => true, update => always] > releases: [enabled => true, update => always] > blocked: false > [DEBUG] (f) mavenSession = org.apache.maven.execution.MavenSession@5f780a86 > [DEBUG] (f) outputDirectory = > /Users/myuser/workdir/projects/myservice/target/docker > [DEBUG] (f) project = MavenProject: > com.mycompany.services:myservice:0.0.1-SNAPSHOT @ > /Users/myuser/workdir/projects/myservice/pom.xml > [DEBUG] (f) remoteArtifactRepositories = [ id: artifactory > url: https://artifactory.mycompany.com/artifactory/maven-repo/ > layout: default > snapshots: [enabled => true, update => daily] > releases: [enabled => true, update => daily] > blocked: false > , id: central > url: https://repo.maven.apache.org/maven2 > layout: default > snapshots: [enabled => false, update => daily] > releases: [enabled => true, update => daily] > blocked: false > ] > [DEBUG] (f) resourceBundles = [com.mycompany.services:remote-template:1.0.6] > [DEBUG] (f) resources = [Resource {targetPath: null, filtering: false, > FileSet {directory: > /Users/myuser/workdir/projects/myservice/src/main/resources, PatternSet > [includes: {}, excludes: {}]}}] > [DEBUG] (f) runOnlyAtExecutionRoot = false > [DEBUG] (f) skip = false > [DEBUG] (f) useDefaultFilterDelimiters = true > [DEBUG] (f) velocityFilterInMemoryThreshold = 5242880 > [DEBUG] -- end configuration -- > {code} > > {code:java} > [INFO] Preparing remote bundle com.mycompany.services:remote-template:1.0.6 > [DEBUG] Verifying availability of > /Users/myuser/.m2/repository/com/mycompany/services/remote-template/1.0.6/remote-template-1.0.6.pom > from [central (https://repo.maven.apache.org/maven2, default, releases)] > [DEBUG] Resolving artifact com.mycompany.services:remote-template:1.0.62 from > [central (https://repo.maven.apache.org/maven2, default, releases)] > [DEBUG] Using transporter WagonTransporter with priority -1.0 for > https://repo.maven.apache.org/maven2 > [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for > https://repo.maven.apache.org/maven2 > Downloading from central: > https://repo.maven.apache.org/maven2/com/mycompany/services/remote-template/1.0.6/remote-template-1.0.6.pom > [DEBUG] Writing tracking file > /Users/myuser/.m2/repository/com/mycompany/services/remote-template/1.0.6/remote-template-1.0.6.pom.lastUpdated > [WARNING] The POM for com.mycompany.services:remote-template:jar:1.0.6 is > missing, no dependency information available > [DEBUG] Resolving artifact com.mycompany.services:remote-template:jar:1.0.6 > from [central (https://repo.maven.apache.org/maven2, default, releases)] > [DEBUG] Using transporter WagonTransporter with priority -1.0 for > https://repo.maven.apache.org/maven2 > [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for > https://repo.maven.apache.org/maven2 > Downloading from central: > https://repo.maven.apache.org/maven2/com/mycompany/services/remote-template/1.0.6/remote-template-1.0.6.jar > [DEBUG] Writing tracking file > /Users/myuser/.m2/repository/com/mycompany/services/remote-template/1.0.6/remote-template-1.0.6.jar.lastUpdated > [INFO] > > [INFO]
[jira] [Comment Edited] (MRRESOURCES-123) Maven Remote Resources Plugin cannot load resource bundle from remote repository
[ https://issues.apache.org/jira/browse/MRRESOURCES-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696328#comment-17696328 ] Jeff Thomas edited comment on MRRESOURCES-123 at 3/3/23 9:11 PM: - same problem here. only get the message not found on maven central but resource JAR is located on private nexus. I have the problem with parent. Parent POM defines repositories. No 401 Unauthorized or such are being reported. The target resource bundle was created with maven-remote-resources-plugin 1.7.0. was (Author: jwt007): same problem here. only get the message not found on maven central but resource JAR is located on private nexus. I have the problem with parent. Parent POM defines repositories. No 401 Unauthorized or such are being reported. > Maven Remote Resources Plugin cannot load resource bundle from remote > repository > > > Key: MRRESOURCES-123 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-123 > Project: Maven Remote Resources Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Andrei Mizurou >Priority: Major > > After upgrading from 1.7.0 to 3.0.0, the application is unable to download > the resourceBundle from a custom remote repository which is defined in > `pom.xml`. We got the following error: > > {code:java} > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-remote-resources-plugin:3.0.0:process' with > basic configurator --> > [DEBUG] (f) appendedResourcesDirectory = > /Users/myuser/workdir/projects/myservice/src/main/appended-resources > [DEBUG] (f) attachToMain = false > [DEBUG] (f) attachToTest = false > [DEBUG] (f) basedir = /Users/myuser/workdir/projects/myservice > [DEBUG] (f) encoding = UTF-8 > [DEBUG] (f) excludeTransitive = false > [DEBUG] (f) includeProjectProperties = false > [DEBUG] (f) includeScope = runtime > [DEBUG] (f) localRepository = id: local > url: file:///Users/myuser/.m2/repository/ > layout: default > snapshots: [enabled => true, update => always] > releases: [enabled => true, update => always] > blocked: false > [DEBUG] (f) mavenSession = org.apache.maven.execution.MavenSession@5f780a86 > [DEBUG] (f) outputDirectory = > /Users/myuser/workdir/projects/myservice/target/docker > [DEBUG] (f) project = MavenProject: > com.mycompany.services:myservice:0.0.1-SNAPSHOT @ > /Users/myuser/workdir/projects/myservice/pom.xml > [DEBUG] (f) remoteArtifactRepositories = [ id: artifactory > url: https://artifactory.mycompany.com/artifactory/maven-repo/ > layout: default > snapshots: [enabled => true, update => daily] > releases: [enabled => true, update => daily] > blocked: false > , id: central > url: https://repo.maven.apache.org/maven2 > layout: default > snapshots: [enabled => false, update => daily] > releases: [enabled => true, update => daily] > blocked: false > ] > [DEBUG] (f) resourceBundles = [com.mycompany.services:remote-template:1.0.6] > [DEBUG] (f) resources = [Resource {targetPath: null, filtering: false, > FileSet {directory: > /Users/myuser/workdir/projects/myservice/src/main/resources, PatternSet > [includes: {}, excludes: {}]}}] > [DEBUG] (f) runOnlyAtExecutionRoot = false > [DEBUG] (f) skip = false > [DEBUG] (f) useDefaultFilterDelimiters = true > [DEBUG] (f) velocityFilterInMemoryThreshold = 5242880 > [DEBUG] -- end configuration -- > {code} > > {code:java} > [INFO] Preparing remote bundle com.mycompany.services:remote-template:1.0.6 > [DEBUG] Verifying availability of > /Users/myuser/.m2/repository/com/mycompany/services/remote-template/1.0.6/remote-template-1.0.6.pom > from [central (https://repo.maven.apache.org/maven2, default, releases)] > [DEBUG] Resolving artifact com.mycompany.services:remote-template:1.0.62 from > [central (https://repo.maven.apache.org/maven2, default, releases)] > [DEBUG] Using transporter WagonTransporter with priority -1.0 for > https://repo.maven.apache.org/maven2 > [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for > https://repo.maven.apache.org/maven2 > Downloading from central: > https://repo.maven.apache.org/maven2/com/mycompany/services/remote-template/1.0.6/remote-template-1.0.6.pom > [DEBUG] Writing tracking file > /Users/myuser/.m2/repository/com/mycompany/services/remote-template/1.0.6/remote-template-1.0.6.pom.lastUpdated > [WARNING] The POM for com.mycompany.services:remote-template:jar:1.0.6 is > missing, no dependency information available > [DEBUG] Resolving artifact com.mycompany.services:remote-template:jar:1.0.6 > from [central (https://repo.maven.apache.org/maven2, default, releases)] > [DEBUG] Using transporter WagonTransporter with priority -1.0 for >
[jira] [Commented] (MRRESOURCES-123) Maven Remote Resources Plugin cannot load resource bundle from remote repository
[ https://issues.apache.org/jira/browse/MRRESOURCES-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696328#comment-17696328 ] Jeff Thomas commented on MRRESOURCES-123: - same problem here. only get the message not found on maven central but resource JAR is located on private nexus. I have the problem with parent. Parent POM defines repositories. No 401 Unauthorized or such are being reported. > Maven Remote Resources Plugin cannot load resource bundle from remote > repository > > > Key: MRRESOURCES-123 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-123 > Project: Maven Remote Resources Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Andrei Mizurou >Priority: Major > > After upgrading from 1.7.0 to 3.0.0, the application is unable to download > the resourceBundle from a custom remote repository which is defined in > `pom.xml`. We got the following error: > > {code:java} > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-remote-resources-plugin:3.0.0:process' with > basic configurator --> > [DEBUG] (f) appendedResourcesDirectory = > /Users/myuser/workdir/projects/myservice/src/main/appended-resources > [DEBUG] (f) attachToMain = false > [DEBUG] (f) attachToTest = false > [DEBUG] (f) basedir = /Users/myuser/workdir/projects/myservice > [DEBUG] (f) encoding = UTF-8 > [DEBUG] (f) excludeTransitive = false > [DEBUG] (f) includeProjectProperties = false > [DEBUG] (f) includeScope = runtime > [DEBUG] (f) localRepository = id: local > url: file:///Users/myuser/.m2/repository/ > layout: default > snapshots: [enabled => true, update => always] > releases: [enabled => true, update => always] > blocked: false > [DEBUG] (f) mavenSession = org.apache.maven.execution.MavenSession@5f780a86 > [DEBUG] (f) outputDirectory = > /Users/myuser/workdir/projects/myservice/target/docker > [DEBUG] (f) project = MavenProject: > com.mycompany.services:myservice:0.0.1-SNAPSHOT @ > /Users/myuser/workdir/projects/myservice/pom.xml > [DEBUG] (f) remoteArtifactRepositories = [ id: artifactory > url: https://artifactory.mycompany.com/artifactory/maven-repo/ > layout: default > snapshots: [enabled => true, update => daily] > releases: [enabled => true, update => daily] > blocked: false > , id: central > url: https://repo.maven.apache.org/maven2 > layout: default > snapshots: [enabled => false, update => daily] > releases: [enabled => true, update => daily] > blocked: false > ] > [DEBUG] (f) resourceBundles = [com.mycompany.services:remote-template:1.0.6] > [DEBUG] (f) resources = [Resource {targetPath: null, filtering: false, > FileSet {directory: > /Users/myuser/workdir/projects/myservice/src/main/resources, PatternSet > [includes: {}, excludes: {}]}}] > [DEBUG] (f) runOnlyAtExecutionRoot = false > [DEBUG] (f) skip = false > [DEBUG] (f) useDefaultFilterDelimiters = true > [DEBUG] (f) velocityFilterInMemoryThreshold = 5242880 > [DEBUG] -- end configuration -- > {code} > > {code:java} > [INFO] Preparing remote bundle com.mycompany.services:remote-template:1.0.6 > [DEBUG] Verifying availability of > /Users/myuser/.m2/repository/com/mycompany/services/remote-template/1.0.6/remote-template-1.0.6.pom > from [central (https://repo.maven.apache.org/maven2, default, releases)] > [DEBUG] Resolving artifact com.mycompany.services:remote-template:1.0.62 from > [central (https://repo.maven.apache.org/maven2, default, releases)] > [DEBUG] Using transporter WagonTransporter with priority -1.0 for > https://repo.maven.apache.org/maven2 > [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for > https://repo.maven.apache.org/maven2 > Downloading from central: > https://repo.maven.apache.org/maven2/com/mycompany/services/remote-template/1.0.6/remote-template-1.0.6.pom > [DEBUG] Writing tracking file > /Users/myuser/.m2/repository/com/mycompany/services/remote-template/1.0.6/remote-template-1.0.6.pom.lastUpdated > [WARNING] The POM for com.mycompany.services:remote-template:jar:1.0.6 is > missing, no dependency information available > [DEBUG] Resolving artifact com.mycompany.services:remote-template:jar:1.0.6 > from [central (https://repo.maven.apache.org/maven2, default, releases)] > [DEBUG] Using transporter WagonTransporter with priority -1.0 for > https://repo.maven.apache.org/maven2 > [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for > https://repo.maven.apache.org/maven2 > Downloading from central: > https://repo.maven.apache.org/maven2/com/mycompany/services/remote-template/1.0.6/remote-template-1.0.6.jar > [DEBUG] Writing tracking file >
[jira] [Commented] (MNG-7707) ${project.basedir} directory creation when running plugin
[ https://issues.apache.org/jira/browse/MNG-7707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696319#comment-17696319 ] Tamas Cservenak commented on MNG-7707: -- But yes, after 2nd reading... "should it not even inject the transformed artifacts as there is no project to build" bit is something the code is missing. > ${project.basedir} directory creation when running plugin > - > > Key: MNG-7707 > URL: https://issues.apache.org/jira/browse/MNG-7707 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-alpha-4, 4.0.0-alpha-5 >Reporter: Giovanni van der Schelde >Priority: Minor > > When running {{mvn archetype:generate}} in a directory without providing a > valid {{{}pom.xml{}}}, a directory named {{{}$\{project.basedir{ is > created in the directory where you execute the command from. > I could be wrong but the reason which leads me to believe it to be in > maven-core is that when I put a breakpoint at the start of the {{exectute()}} > method in the [generate > mojo|https://github.com/apache/maven-archetype/blob/master/maven-archetype-plugin/src/main/java/org/apache/maven/archetype/mojos/CreateProjectFromArchetypeMojo.java#L177] > the directory is already created. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[ https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696298#comment-17696298 ] Michael Osipov commented on MNG-7705: - Thanks for the data. Will take a look tomorrow. > Sporadic failures on multiple builds sharing the same local repo when writing > the .lastUpdated file > --- > > Key: MNG-7705 > URL: https://issues.apache.org/jira/browse/MNG-7705 > Project: Maven > Issue Type: Bug >Affects Versions: 3.9.0 > Environment: Apache Maven 3.9.0 > (9b58d2bad23a66be161c4664ef21ce219c2c8584) > Maven home: /data00/bamboo/maven/maven-next > Java version: 1.8.0_362, vendor: Red Hat, Inc., runtime: > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.362.b09-2.el8_7.x86_64/jre > Default locale: en_CA, platform encoding: ISO-8859-1 > OS name: "linux", version: "4.18.0-193.el8.x86_64", arch: "amd64", family: > "unix" >Reporter: Jim Sellers >Priority: Minor > Attachments: 2023-02-28_failure.zip, MNG-7705-2023-02-27.zip, > MNG-7705.zip, MNG-7705_strace_2023-02-27.zip, > apache-maven-3.9.1-SNAPSHOT-bin.tar.gz, maven-resolver-util-1.9.6-SNAPSHOT.jar > > > On a CI server, we have multiple builds running on the same host and sharing > the same repo. > While testing 3.9.0, I started to see a NIO exception for the > {{.lastUpdated}} file. This has worked fine for years, all the way up to > 3.8.7. > If you re-run the build, it will work. I think that it's just a collision > between the different processes. > {code:title=example command} > mvn --batch-mode dependency:sources dependency:resolve -Dclassifier=javadoc > # this uses dependency:3.5.0:sources > {code} > {code:title=stracktrace} > [WARNING] Failed to write tracking file > '/home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated' > java.nio.file.NoSuchFileException: > /home/bamboo/.m2/repository/io/smallrye/config/smallrye-config/2.3.0/smallrye-config-2.3.0-javadoc.jar.lastUpdated > at sun.nio.fs.UnixException.translateToIOException > (UnixException.java:86) > at sun.nio.fs.UnixException.rethrowAsIOException > (UnixException.java:102) > at sun.nio.fs.UnixException.rethrowAsIOException > (UnixException.java:107) > at sun.nio.fs.UnixFileSystemProvider.newByteChannel > (UnixFileSystemProvider.java:214) > at java.nio.file.Files.newByteChannel (Files.java:361) > at java.nio.file.Files.newByteChannel (Files.java:407) > at java.nio.file.spi.FileSystemProvider.newInputStream > (FileSystemProvider.java:384) > at java.nio.file.Files.newInputStream (Files.java:152) > at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update > (DefaultTrackingFileManager.java:90) > at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.write > (DefaultUpdateCheckManager.java:604) > at > org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.touchArtifact > (DefaultUpdateCheckManager.java:539) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads > (DefaultArtifactResolver.java:701) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads > (DefaultArtifactResolver.java:592) > at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve > (DefaultArtifactResolver.java:478) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts > (DefaultArtifactResolver.java:278) > at > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact > (DefaultArtifactResolver.java:255) > at > org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact > (DefaultRepositorySystem.java:296) > at > org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact > (Maven31ArtifactResolver.java:97) > at > org.apache.maven.shared.transfer.artifact.resolve.internal.Maven31ArtifactResolver.resolveArtifact > (Maven31ArtifactResolver.java:78) > at > org.apache.maven.shared.transfer.artifact.resolve.internal.DefaultArtifactResolver.resolveArtifact > (DefaultArtifactResolver.java:70) > at > org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.resolve > (AbstractDependencyFilterMojo.java:464) > at > org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getClassifierTranslatedDependencies > (AbstractDependencyFilterMojo.java:408) > at > org.apache.maven.plugins.dependency.fromDependencies.AbstractDependencyFilterMojo.getDependencySets > (AbstractDependencyFilterMojo.java:340) > at >
[jira] [Updated] (MNG-7719) Maven 3.9.0 native http transport ignores username/password for basic auth
[ https://issues.apache.org/jira/browse/MNG-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7719: - Fix Version/s: waiting-for-feedback > Maven 3.9.0 native http transport ignores username/password for basic auth > -- > > Key: MNG-7719 > URL: https://issues.apache.org/jira/browse/MNG-7719 > Project: Maven > Issue Type: Improvement > Components: Core, Deployment >Affects Versions: 3.9.0 >Reporter: Adam Gent >Priority: Major > Fix For: waiting-for-feedback > > > In 3.9.0 the default maven http transport switched from wagon to native. > It appears that the native transport does not respect: > {code:xml} > > some-repo > some-username > basic-auth-password > > {code} > Now when you do a mvn deploy to some-repo the basic auth headers are missing. > This is probably causing github package problems: > https://github.com/orgs/community/discussions/49001 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7705) Sporadic failures on multiple builds sharing the same local repo when writing the .lastUpdated file
[ https://issues.apache.org/jira/browse/MNG-7705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696277#comment-17696277 ] Jim Sellers commented on MNG-7705: -- I've not yet fully setup redisson yet. It's new to me and I have to figure out a config file to get it running. I've got the builds just using the latest maven snapshots. I re-ran the test (delete m2 repo to force lots of writes, kick off 3 parallel builds). I noticed that all 3 builds unlink the lock file before it's logged that it's acquiring a lock. Then they grab a lock at different times. Is this the expected behavour? {code:title=command to filter the build log files} grep "2.2.10-b140802.1033" *.log | grep jaxb-core | grep -e lock -e write {code} {code:title=failed around 11:48:57} error 03-Mar-2023 11:48:57[pid 4126891] 11:48:57.123969 openat(AT_FDCWD, "/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0666) = 65 error 03-Mar-2023 11:48:57[pid 4126891] 11:48:57.124055 unlink("/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock") = 0 build 03-Mar-2023 11:48:5719222 [main] [TRACE] Need 1 write lock(s) for [/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock] build 03-Mar-2023 11:48:5719223 [main] [TRACE] Acquiring write lock for '/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock' build 03-Mar-2023 11:48:5719350 [main] [WARNING] Failed to write tracking file '/home/bamboo/.m2/repository/org/glassfish/jaxb/jaxb-core/2.2.10-b140802.1033/jaxb-core-2.2.10-b140802.1033.pom.lastUpdated' build 03-Mar-2023 11:48:5719375 [main] [TRACE] Releasing write lock for '/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock' {code} {code:title=failed around 11:50:12} error 03-Mar-2023 11:48:57[pid 4126950] 11:48:57.099587 openat(AT_FDCWD, "/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0666) = 65 error 03-Mar-2023 11:48:57[pid 4126950] 11:48:57.099707 unlink("/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock") = 0 build 03-Mar-2023 11:50:1218999 [main] [TRACE] Need 1 write lock(s) for [/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock] build 03-Mar-2023 11:50:1218999 [main] [TRACE] Acquiring write lock for '/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock' build 03-Mar-2023 11:50:1219066 [main] [TRACE] Releasing write lock for '/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock' {code} {code:title=successful build} error 03-Mar-2023 11:48:57[pid 4126962] 11:48:57.118526 openat(AT_FDCWD, "/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0666) = 65 error 03-Mar-2023 11:48:57[pid 4126962] 11:48:57.118618 unlink("/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock") = 0 build 03-Mar-2023 11:52:0918917 [main] [TRACE] Need 1 write lock(s) for [/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock] build 03-Mar-2023 11:52:0918917 [main] [TRACE] Acquiring write lock for '/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock' build 03-Mar-2023 11:52:0919050 [main] [TRACE] Releasing write lock for '/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock' build 03-Mar-2023 11:53:004091 [main] [TRACE] Need 1 write lock(s) for [/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock] error 03-Mar-2023 11:53:00[pid 4130224] 11:53:00.635067 openat(AT_FDCWD, "/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock", O_RDWR|O_CREAT|O_NOFOLLOW, 0666) = 65 error 03-Mar-2023 11:53:00[pid 4130224] 11:53:00.635171 unlink("/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock") = 0 build 03-Mar-2023 11:53:004092 [main] [TRACE] Acquiring write lock for '/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock' build 03-Mar-2023 11:53:004093 [main] [TRACE] Releasing write lock for '/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock' build 03-Mar-2023 11:53:113924 [main] [TRACE] Need 1 write lock(s) for [/home/bamboo/.m2/repository/.locks/org.glassfish.jaxb~jaxb-core~2.2.10-b140802.1033.lock] error 03-Mar-2023 11:53:11[pid 4130272] 11:53:11.154681 openat(AT_FDCWD,
[jira] [Commented] (MNG-7719) Maven 3.9.0 native http transport ignores username/password for basic auth
[ https://issues.apache.org/jira/browse/MNG-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696270#comment-17696270 ] Tamas Cservenak commented on MNG-7719: -- My counter example: [https://gist.github.com/cstamas/2cbd651498c707f1863c717469520424] My guess for GH issues is that folks who used Plexus XML to configure Wagon are suddenly loosing their config, for them fallback {{-Dmaven.resolver.transport=wagon}} is way to go, and once they fix/update their config, then they can join the party. > Maven 3.9.0 native http transport ignores username/password for basic auth > -- > > Key: MNG-7719 > URL: https://issues.apache.org/jira/browse/MNG-7719 > Project: Maven > Issue Type: Improvement > Components: Core, Deployment >Affects Versions: 3.9.0 >Reporter: Adam Gent >Priority: Major > > In 3.9.0 the default maven http transport switched from wagon to native. > It appears that the native transport does not respect: > {code:xml} > > some-repo > some-username > basic-auth-password > > {code} > Now when you do a mvn deploy to some-repo the basic auth headers are missing. > This is probably causing github package problems: > https://github.com/orgs/community/discussions/49001 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7719) Maven 3.9.0 native http transport ignores username/password for basic auth
[ https://issues.apache.org/jira/browse/MNG-7719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696262#comment-17696262 ] Tamas Cservenak commented on MNG-7719: -- Can you provide a reproducer? > Maven 3.9.0 native http transport ignores username/password for basic auth > -- > > Key: MNG-7719 > URL: https://issues.apache.org/jira/browse/MNG-7719 > Project: Maven > Issue Type: Improvement > Components: Core, Deployment >Affects Versions: 3.9.0 >Reporter: Adam Gent >Priority: Major > > In 3.9.0 the default maven http transport switched from wagon to native. > It appears that the native transport does not respect: > {code:xml} > > some-repo > some-username > basic-auth-password > > {code} > Now when you do a mvn deploy to some-repo the basic auth headers are missing. > This is probably causing github package problems: > https://github.com/orgs/community/discussions/49001 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7719) Maven 3.9.0 native http transport ignores username/password for basic auth
Adam Gent created MNG-7719: -- Summary: Maven 3.9.0 native http transport ignores username/password for basic auth Key: MNG-7719 URL: https://issues.apache.org/jira/browse/MNG-7719 Project: Maven Issue Type: Improvement Components: Core, Deployment Affects Versions: 3.9.0 Reporter: Adam Gent In 3.9.0 the default maven http transport switched from wagon to native. It appears that the native transport does not respect: {code:xml} some-repo some-username basic-auth-password {code} Now when you do a mvn deploy to some-repo the basic auth headers are missing. This is probably causing github package problems: https://github.com/orgs/community/discussions/49001 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-pmd-plugin] adangel merged pull request #114: Bump release-drafter/release-drafter from 5.21.1 to 5.23.0
adangel merged PR #114: URL: https://github.com/apache/maven-pmd-plugin/pull/114 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MNG-7716) ConcurrencyDependencyGraph deadlock if no root can be selected
[ https://issues.apache.org/jira/browse/MNG-7716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-7716. --- Resolution: Fixed Fixed with [f41d533e7133968f23664cf8cdde832dd305e16e|https://gitbox.apache.org/repos/asf?p=maven.git=commit=f41d533e7133968f23664cf8cdde832dd305e16e], with [837db7a756164cadd978e53f8c566f0f14b79b6c|https://gitbox.apache.org/repos/asf?p=maven.git=commit=837db7a756164cadd978e53f8c566f0f14b79b6c] for maven-3.9.x, with [a0f460ca5807bb98561e1ed123fd28302c4fa0f3|https://gitbox.apache.org/repos/asf?p=maven.git=commit=a0f460ca5807bb98561e1ed123fd28302c4fa0f3] for maven-3.8.x and ITs with [671cbfd274fa9516efb5a02b5cdd704e833f3d56|https://gitbox.apache.org/repos/asf?p=maven-integration-testing.git=commit=671cbfd274fa9516efb5a02b5cdd704e833f3d56]. > ConcurrencyDependencyGraph deadlock if no root can be selected > -- > > Key: MNG-7716 > URL: https://issues.apache.org/jira/browse/MNG-7716 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.7, 3.9.0, 4.0.0-alpha-4 >Reporter: Christoph Läubrich >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-5, 3.8.8, 3.9.1 > > > At Tycho we got a bug-report that results in a deadlock when calling the > tycho-version-plugin: > https://github.com/eclipse-tycho/tycho/issues/2169 > I debugged the problem and it seems that ConcurrencyDependencyGraph is > actually the culprit here because it can return an empty list of projects to > initially build. As no builds are scheduled then the code in the > MultiThreadedBuilder waits forever for the result, this is what happening > here: > * There is one segment {code}org.faktorips:base:pom:23.6.0-SNAPSHOT -> > [org.eclipse.tycho:tycho-versions-plugin:3.0.4-SNAPSHOT:set-version]{code} > * This segment has a transitive reactor dependency to {code}MavenProject: > org.faktorips:codequality-config:23.6.0-SNAPSHOT @ > faktorips.base/codequality-config/pom.xml{code} (this is not a problem > because we only execute a reactor=true mojo!) > * So now the loop finds that there is no "independent" project and returns an > empty list -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MASSEMBLY-845) MASSEMBLY-817 makes some usecases very inconvenient
[ https://issues.apache.org/jira/browse/MASSEMBLY-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17685939#comment-17685939 ] Marat Abrarov edited comment on MASSEMBLY-845 at 3/3/23 5:08 PM: - Hi [~khmarbaise], [~rfscholte-getthere] and [~afloom], Here is my use-case of Maven Assembly Plugin, which relies on {{finalName}} parameter: [https://github.com/mabrarov/docker-compose-init-container/blob/master/app-image/pom.xml]. I use Maven Assembly Plugin to create multiple archives (with required structure, directory and file permissions, directory and file timestamps, line endings), which are later (within the same maven module) used in Dockerfile [{{ADD}}|https://docs.docker.com/engine/reference/builder/#add] or [{{COPY}}|https://docs.docker.com/engine/reference/builder/#copy] instructions to place directories / files into the built (using [docker-maven-plugin|https://github.com/fabric8io/docker-maven-plugin] and generated Dockerfile) container image. I also use Maven Assembly Plugin with {{finalName}} parameter to place all packaged archives and Dockerfile (where I fill placeholders using filtering) in a single directory which is used as Docker build context. This way my builds on Windows host (using remote Docker engine which can be running in a local VM with Linux) and on Linux hosts (using remote or local Docker engine) are identical, OS independent (comparing to {{docker build}} command) and reproducible. Taking into account that Maven Assembly Plugin still supports [{{outputDirectory}}|https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#outputDirectory] parameter (which can replace {{finalName}} parameter for my use case, but it will complicate maven project and Dockerfile), I find deprecation of {{finalName}} parameter (MASSEMBLY-817) meaningless. Even integration tests of Maven Assembly Plugin (e.g. [https://github.com/apache/maven-assembly-plugin/blob/master/src/it/projects/mojo-tests/single-twice-in-one-project-hierarchy/pom.xml]) still use {{finalName}} parameter. I vote to make {{finalName}} back editable, or at least consider it editable if {{attach}} is {{{}false{}}}. FYI [~ctubbsii] (from [comment|https://issues.apache.org/jira/browse/MASSEMBLY-843?focusedCommentId=17696156=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17696156] in MASSEMBLY-843). Thank you. was (Author: abrarovm): Hi [~khmarbaise], [~rfscholte-getthere] and [~afloom], Here is my use-case of Maven Assembly Plugin, which relies on {{finalName}} parameter: [https://github.com/mabrarov/docker-compose-init-container/blob/master/app-image/pom.xml]. I use Maven Assembly Plugin to create multiple archives (with required structure, directory and file permissions, directory and file timestamps, line endings), which are later (within the same maven module) used in Dockerfile [{{ADD}}|https://docs.docker.com/engine/reference/builder/#add] or [{{COPY}}|https://docs.docker.com/engine/reference/builder/#copy] instructions to place directories / files into the built (using [docker-maven-plugin|https://github.com/fabric8io/docker-maven-plugin] and generated Dockerfile) container image. I also use Maven Assembly Plugin with {{finalName}} parameter to place all packaged archives and Dockerfile (where I fill placeholders using filtering) in a single directory which is used as Docker build context. This way my builds on Windows host (using remote Docker engine which can be running in a local VM with Linux) and on Linux hosts (using remote or local Docker engine) are identical, OS independent (comparing to {{docker build}} command) and reproducible. Taking into account that Maven Assembly Plugin still supports [{{outputDirectory}}|https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#outputDirectory] parameter (which can replace {{finalName}} parameter for my use case, but it will complicate maven project and Dockerfile), I find deprecation of {{finalName}} parameter (MASSEMBLY-817) meaningless. Even integration tests of Maven Assembly Plugin (e.g. [https://github.com/apache/maven-assembly-plugin/blob/master/src/it/projects/mojo-tests/single-twice-in-one-project-hierarchy/pom.xml]) still use {{finalName}} parameter. I vote to make {{finalName}} back editable, or at least consider it editable if {{attach}} is {{{}false{}}}. FYI [~ctubbsii] (from comment in MASSEMBLY-843). Thank you. > MASSEMBLY-817 makes some usecases very inconvenient > --- > > Key: MASSEMBLY-845 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-845 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Ulf Dreyer >Priority: Major > > The "improvement" done in MASSEMBLY-817 makes some
[jira] [Commented] (MNG-7716) ConcurrencyDependencyGraph deadlock if no root can be selected
[ https://issues.apache.org/jira/browse/MNG-7716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696228#comment-17696228 ] ASF GitHub Bot commented on MNG-7716: - asfgit merged PR #1027: URL: https://github.com/apache/maven/pull/1027 > ConcurrencyDependencyGraph deadlock if no root can be selected > -- > > Key: MNG-7716 > URL: https://issues.apache.org/jira/browse/MNG-7716 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.7, 3.9.0, 4.0.0-alpha-4 >Reporter: Christoph Läubrich >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-5, 3.8.8, 3.9.1 > > > At Tycho we got a bug-report that results in a deadlock when calling the > tycho-version-plugin: > https://github.com/eclipse-tycho/tycho/issues/2169 > I debugged the problem and it seems that ConcurrencyDependencyGraph is > actually the culprit here because it can return an empty list of projects to > initially build. As no builds are scheduled then the code in the > MultiThreadedBuilder waits forever for the result, this is what happening > here: > * There is one segment {code}org.faktorips:base:pom:23.6.0-SNAPSHOT -> > [org.eclipse.tycho:tycho-versions-plugin:3.0.4-SNAPSHOT:set-version]{code} > * This segment has a transitive reactor dependency to {code}MavenProject: > org.faktorips:codequality-config:23.6.0-SNAPSHOT @ > faktorips.base/codequality-config/pom.xml{code} (this is not a problem > because we only execute a reactor=true mojo!) > * So now the loop finds that there is no "independent" project and returns an > empty list -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-integration-testing] asfgit closed pull request #250: Add integrationtest for MNG-7716
asfgit closed pull request #250: Add integrationtest for MNG-7716 URL: https://github.com/apache/maven-integration-testing/pull/250 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] asfgit merged pull request #1027: [3.8.x][MNG-7716] ConcurrencyDependencyGraph deadlock if no root is selected
asfgit merged PR #1027: URL: https://github.com/apache/maven/pull/1027 -- 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-7716) ConcurrencyDependencyGraph deadlock if no root can be selected
[ https://issues.apache.org/jira/browse/MNG-7716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696227#comment-17696227 ] ASF GitHub Bot commented on MNG-7716: - asfgit merged PR #1028: URL: https://github.com/apache/maven/pull/1028 > ConcurrencyDependencyGraph deadlock if no root can be selected > -- > > Key: MNG-7716 > URL: https://issues.apache.org/jira/browse/MNG-7716 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.7, 3.9.0, 4.0.0-alpha-4 >Reporter: Christoph Läubrich >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-5, 3.8.8, 3.9.1 > > > At Tycho we got a bug-report that results in a deadlock when calling the > tycho-version-plugin: > https://github.com/eclipse-tycho/tycho/issues/2169 > I debugged the problem and it seems that ConcurrencyDependencyGraph is > actually the culprit here because it can return an empty list of projects to > initially build. As no builds are scheduled then the code in the > MultiThreadedBuilder waits forever for the result, this is what happening > here: > * There is one segment {code}org.faktorips:base:pom:23.6.0-SNAPSHOT -> > [org.eclipse.tycho:tycho-versions-plugin:3.0.4-SNAPSHOT:set-version]{code} > * This segment has a transitive reactor dependency to {code}MavenProject: > org.faktorips:codequality-config:23.6.0-SNAPSHOT @ > faktorips.base/codequality-config/pom.xml{code} (this is not a problem > because we only execute a reactor=true mojo!) > * So now the loop finds that there is no "independent" project and returns an > empty list -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] asfgit merged pull request #1028: [3.9.x][MNG-7716] ConcurrencyDependencyGraph deadlock if no root is selected
asfgit merged PR #1028: URL: https://github.com/apache/maven/pull/1028 -- 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] (MINVOKER-328) Plugin tries to install dependency to same path when localRepositoryPath not set
[ https://issues.apache.org/jira/browse/MINVOKER-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MINVOKER-328. Fix Version/s: 3.5.1 Resolution: Fixed > Plugin tries to install dependency to same path when localRepositoryPath not > set > > > Key: MINVOKER-328 > URL: https://issues.apache.org/jira/browse/MINVOKER-328 > Project: Maven Invoker Plugin > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Delany >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.5.1 > > > The plugin tries to install a dependency from local Maven repository to the > same location: > > {code:java} > Installing > /home/sol/.m2/repository/org/apache/maven/maven-core/3.9.0/maven-core-3.9.0.jar > to > /home/sol/.m2/repository/org/apache/maven/maven-core/3.9.0/maven-core-3.9.0.jar > {code} > > Reproduce with > [https://github.com/delanym/MINVOKER-283.git] > No > {{[|https://maven.apache.org/plugins/maven-invoker-plugin/install-mojo.html#localRepositoryPath]}} > was set. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7716) ConcurrencyDependencyGraph deadlock if no root can be selected
[ https://issues.apache.org/jira/browse/MNG-7716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696226#comment-17696226 ] ASF GitHub Bot commented on MNG-7716: - asfgit closed pull request #1029: [MNG-7716] ConcurrencyDependencyGraph deadlock if no root is selected URL: https://github.com/apache/maven/pull/1029 > ConcurrencyDependencyGraph deadlock if no root can be selected > -- > > Key: MNG-7716 > URL: https://issues.apache.org/jira/browse/MNG-7716 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.7, 3.9.0, 4.0.0-alpha-4 >Reporter: Christoph Läubrich >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-5, 3.8.8, 3.9.1 > > > At Tycho we got a bug-report that results in a deadlock when calling the > tycho-version-plugin: > https://github.com/eclipse-tycho/tycho/issues/2169 > I debugged the problem and it seems that ConcurrencyDependencyGraph is > actually the culprit here because it can return an empty list of projects to > initially build. As no builds are scheduled then the code in the > MultiThreadedBuilder waits forever for the result, this is what happening > here: > * There is one segment {code}org.faktorips:base:pom:23.6.0-SNAPSHOT -> > [org.eclipse.tycho:tycho-versions-plugin:3.0.4-SNAPSHOT:set-version]{code} > * This segment has a transitive reactor dependency to {code}MavenProject: > org.faktorips:codequality-config:23.6.0-SNAPSHOT @ > faktorips.base/codequality-config/pom.xml{code} (this is not a problem > because we only execute a reactor=true mojo!) > * So now the loop finds that there is no "independent" project and returns an > empty list -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] asfgit closed pull request #1029: [MNG-7716] ConcurrencyDependencyGraph deadlock if no root is selected
asfgit closed pull request #1029: [MNG-7716] ConcurrencyDependencyGraph deadlock if no root is selected URL: https://github.com/apache/maven/pull/1029 -- 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] (MASSEMBLY-845) MASSEMBLY-817 makes some usecases very inconvenient
[ https://issues.apache.org/jira/browse/MASSEMBLY-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696225#comment-17696225 ] Christopher Tubbs commented on MASSEMBLY-845: - This issue seems to be a duplicate of MASSEMBLY-843. It even has identical descriptions, but only slightly different subject lines. One should be closed (typically for duplicates, the earliest one should be kept, but both have a fair number of comments in this case). > MASSEMBLY-817 makes some usecases very inconvenient > --- > > Key: MASSEMBLY-845 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-845 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Ulf Dreyer >Priority: Major > > The "improvement" done in MASSEMBLY-817 makes some usecases very inconvenient: > We need to create an archive with one stable name (independent of e.g. > version) so we don't have to propagate these information to a bunch of > scripts. > The general solution (i.e. Stack-overflow) refers exactly to the finalName: > [http://stackoverflow.com/questions/20697144/can-not-set-the-final-jar-name-with-maven-assembly-plugin] > *Please change finalName back to a settable property.* > It being settable does not hurt anyone satisfied with the default naming > convention but makes some usecases vastly simpler (otherwise you have to > rename the artifact using yet another plugin or propagate version info > possibly through a chain of scripts) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-invoker-plugin] slawekjaranowski merged pull request #177: [MINVOKER-328] Skip install artifacts with the same source and target path
slawekjaranowski merged PR #177: URL: https://github.com/apache/maven-invoker-plugin/pull/177 -- 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-7707) ${project.basedir} directory creation when running plugin
[ https://issues.apache.org/jira/browse/MNG-7707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7707: Summary: ${project.basedir} directory creation when running plugin (was: ${project.basedir} folder creation when running plugin) > ${project.basedir} directory creation when running plugin > - > > Key: MNG-7707 > URL: https://issues.apache.org/jira/browse/MNG-7707 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-alpha-4, 4.0.0-alpha-5 >Reporter: Giovanni van der Schelde >Priority: Minor > > When running {{mvn archetype:generate}} in a directory without providing a > valid {{{}pom.xml{}}}, a directory named {{{}$\{project.basedir{ is > created in the directory where you execute the command from. > I could be wrong but the reason which leads me to believe it to be in > maven-core is that when I put a breakpoint at the start of the {{exectute()}} > method in the [generate > mojo|https://github.com/apache/maven-archetype/blob/master/maven-archetype-plugin/src/main/java/org/apache/maven/archetype/mojos/CreateProjectFromArchetypeMojo.java#L177] > the directory is already created. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MASSEMBLY-845) MASSEMBLY-817 makes some usecases very inconvenient
[ https://issues.apache.org/jira/browse/MASSEMBLY-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17685939#comment-17685939 ] Marat Abrarov edited comment on MASSEMBLY-845 at 3/3/23 4:38 PM: - Hi [~khmarbaise], [~rfscholte-getthere] and [~afloom], Here is my use-case of Maven Assembly Plugin, which relies on {{finalName}} parameter: [https://github.com/mabrarov/docker-compose-init-container/blob/master/app-image/pom.xml]. I use Maven Assembly Plugin to create multiple archives (with required structure, directory and file permissions, directory and file timestamps, line endings), which are later (within the same maven module) used in Dockerfile [{{ADD}}|https://docs.docker.com/engine/reference/builder/#add] or [{{COPY}}|https://docs.docker.com/engine/reference/builder/#copy] instructions to place directories / files into the built (using [docker-maven-plugin|https://github.com/fabric8io/docker-maven-plugin] and generated Dockerfile) container image. I also use Maven Assembly Plugin with {{finalName}} parameter to place all packaged archives and Dockerfile (where I fill placeholders using filtering) in a single directory which is used as Docker build context. This way my builds on Windows host (using remote Docker engine which can be running in a local VM with Linux) and on Linux hosts (using remote or local Docker engine) are identical, OS independent (comparing to {{docker build}} command) and reproducible. Taking into account that Maven Assembly Plugin still supports [{{outputDirectory}}|https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#outputDirectory] parameter (which can replace {{finalName}} parameter for my use case, but it will complicate maven project and Dockerfile), I find deprecation of {{finalName}} parameter (MASSEMBLY-817) meaningless. Even integration tests of Maven Assembly Plugin (e.g. [https://github.com/apache/maven-assembly-plugin/blob/master/src/it/projects/mojo-tests/single-twice-in-one-project-hierarchy/pom.xml]) still use {{finalName}} parameter. I vote to make {{finalName}} back editable, or at least consider it editable if {{attach}} is {{{}false{}}}. FYI [~ctubbsii] (from comment in MASSEMBLY-843). Thank you. was (Author: abrarovm): Hi [~khmarbaise], [~rfscholte-getthere] and [~afloom], Here is my use-case of Maven Assembly Plugin, which relies on {{finalName}} parameter: [https://github.com/mabrarov/docker-compose-init-container/blob/master/app-image/pom.xml]. I use Maven Assembly Plugin to create multiple archives (with required structure, directory and file permissions, directory and file timestamps, line endings), which are later (within the same maven module) used in Dockerfile [{{ADD}}|https://docs.docker.com/engine/reference/builder/#add] or [{{COPY}}|https://docs.docker.com/engine/reference/builder/#copy] instructions to place directories / files in the built (using [docker-maven-plugin|https://github.com/fabric8io/docker-maven-plugin] and generated Dockerfile) container image. I also use Maven Assembly Plugin with {{finalName}} parameter to place all packaged archives and Dockerfile (where I fill placeholders using filtering) in a single directory which is used as Docker build context. This way my builds on Windows host (using remote Docker engine which can be running in a local VM with Linux) and on Linux hosts (using remote or local Docker engine) are identical, OS independent (comparing to {{docker build}} command) and reproducible. Taking into account that Maven Assembly Plugin still supports [{{outputDirectory}}|https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#outputDirectory] parameter (which can replace {{finalName}} parameter for my use case, but it will complicate maven project and Dockerfile), I find deprecation of {{finalName}} parameter (MASSEMBLY-817) meaningless. Even integration tests of Maven Assembly Plugin (e.g. [https://github.com/apache/maven-assembly-plugin/blob/master/src/it/projects/mojo-tests/single-twice-in-one-project-hierarchy/pom.xml]) still use {{finalName}} parameter. I vote to make {{finalName}} back editable, or at least consider it editable if {{attach}} is {{{}false{}}}. FYI [~ctubbsii] (from [comment|https://issues.apache.org/jira/browse/MASSEMBLY-843?focusedCommentId=17696156=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17696156] in MASSEMBLY-843). Thank you. > MASSEMBLY-817 makes some usecases very inconvenient > --- > > Key: MASSEMBLY-845 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-845 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Ulf Dreyer >Priority: Major > > The "improvement" done in MASSEMBLY-817 makes some usecases
[jira] [Updated] (MNG-7707) ${project.basedir} folder creation when running plugin
[ https://issues.apache.org/jira/browse/MNG-7707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7707: Description: When running {{mvn archetype:generate}} in a directory without providing a valid {{{}pom.xml{}}}, a directory named {{{}$\{project.basedir{ is created in the directory where you execute the command from. I could be wrong but the reason which leads me to believe it to be in maven-core is that when I put a breakpoint at the start of the {{exectute()}} method in the [generate mojo|https://github.com/apache/maven-archetype/blob/master/maven-archetype-plugin/src/main/java/org/apache/maven/archetype/mojos/CreateProjectFromArchetypeMojo.java#L177] the folder is already created. was: When running {{mvn archetype:generate}} in a directory without providing a valid {{{}pom.xml{}}}, a directory named {{{}$\{project.basedir{ is created in the folder you execute the command from. I could be wrong but the reason which leads me to believe it to be in maven-core is that when I put a breakpoint at the start of the {{exectute()}} method in the [generate mojo|https://github.com/apache/maven-archetype/blob/master/maven-archetype-plugin/src/main/java/org/apache/maven/archetype/mojos/CreateProjectFromArchetypeMojo.java#L177] the folder is already created. > ${project.basedir} folder creation when running plugin > -- > > Key: MNG-7707 > URL: https://issues.apache.org/jira/browse/MNG-7707 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-alpha-4, 4.0.0-alpha-5 >Reporter: Giovanni van der Schelde >Priority: Minor > > When running {{mvn archetype:generate}} in a directory without providing a > valid {{{}pom.xml{}}}, a directory named {{{}$\{project.basedir{ is > created in the directory where you execute the command from. > I could be wrong but the reason which leads me to believe it to be in > maven-core is that when I put a breakpoint at the start of the {{exectute()}} > method in the [generate > mojo|https://github.com/apache/maven-archetype/blob/master/maven-archetype-plugin/src/main/java/org/apache/maven/archetype/mojos/CreateProjectFromArchetypeMojo.java#L177] > the folder is already created. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MASSEMBLY-845) MASSEMBLY-817 makes some usecases very inconvenient
[ https://issues.apache.org/jira/browse/MASSEMBLY-845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17685939#comment-17685939 ] Marat Abrarov edited comment on MASSEMBLY-845 at 3/3/23 4:37 PM: - Hi [~khmarbaise], [~rfscholte-getthere] and [~afloom], Here is my use-case of Maven Assembly Plugin, which relies on {{finalName}} parameter: [https://github.com/mabrarov/docker-compose-init-container/blob/master/app-image/pom.xml]. I use Maven Assembly Plugin to create multiple archives (with required structure, directory and file permissions, directory and file timestamps, line endings), which are later (within the same maven module) used in Dockerfile [{{ADD}}|https://docs.docker.com/engine/reference/builder/#add] or [{{COPY}}|https://docs.docker.com/engine/reference/builder/#copy] instructions to place directories / files in the built (using [docker-maven-plugin|https://github.com/fabric8io/docker-maven-plugin] and generated Dockerfile) container image. I also use Maven Assembly Plugin with {{finalName}} parameter to place all packaged archives and Dockerfile (where I fill placeholders using filtering) in a single directory which is used as Docker build context. This way my builds on Windows host (using remote Docker engine which can be running in a local VM with Linux) and on Linux hosts (using remote or local Docker engine) are identical, OS independent (comparing to {{docker build}} command) and reproducible. Taking into account that Maven Assembly Plugin still supports [{{outputDirectory}}|https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#outputDirectory] parameter (which can replace {{finalName}} parameter for my use case, but it will complicate maven project and Dockerfile), I find deprecation of {{finalName}} parameter (MASSEMBLY-817) meaningless. Even integration tests of Maven Assembly Plugin (e.g. [https://github.com/apache/maven-assembly-plugin/blob/master/src/it/projects/mojo-tests/single-twice-in-one-project-hierarchy/pom.xml]) still use {{finalName}} parameter. I vote to make {{finalName}} back editable, or at least consider it editable if {{attach}} is {{{}false{}}}. FYI [~ctubbsii] (from [comment|https://issues.apache.org/jira/browse/MASSEMBLY-843?focusedCommentId=17696156=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17696156] in MASSEMBLY-843). Thank you. was (Author: abrarovm): Hi [~khmarbaise], [~rfscholte-getthere] and [~afloom], Here is my use-case of Maven Assembly Plugin, which relies on {{finalName}} parameter: [https://github.com/mabrarov/docker-compose-init-container/blob/master/app-image/pom.xml]. I use Maven Assembly Plugin to create multiple archives (with required structure, directory and file permissions, directory and file timestamps, line endings), which are later (within the same maven module) used in Dockerfile [{{ADD}}|https://docs.docker.com/engine/reference/builder/#add] or [{{COPY}}|https://docs.docker.com/engine/reference/builder/#copy] instructions to place directories / files in the built (using [docker-maven-plugin|https://github.com/fabric8io/docker-maven-plugin] and generated Dockerfile) container image. I also use Maven Assembly Plugin with {{finalName}} parameter to place all packaged archives and Dockerfile (where I fill placeholders using filtering) in a single directory which is used as Docker build context. This way my builds on Windows host (using remote Docker engine which can be running in a local VM with Linux) and on Linux hosts (using remote or local Docker engine) are identical, OS independent (comparing to {{docker build}} command) and reproducible. Taking into account that Maven Assembly Plugin still supports [{{outputDirectory}}|https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#outputDirectory] parameter (which can replace {{finalName}} parameter for my use case, but it will complicate maven project and Dockerfile), I find deprecation of {{finalName}} parameter (MASSEMBLY-817) meaningless. Even integration tests of Maven Assembly Plugin (e.g. [https://github.com/apache/maven-assembly-plugin/blob/master/src/it/projects/mojo-tests/single-twice-in-one-project-hierarchy/pom.xml]) still use {{finalName}} parameter. I vote to make {{finalName}} back editable, or at least consider it editable if {{attach}} is {{{}false{}}}. Thank you. > MASSEMBLY-817 makes some usecases very inconvenient > --- > > Key: MASSEMBLY-845 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-845 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Ulf Dreyer >Priority: Major > > The "improvement" done in MASSEMBLY-817 makes some usecases very inconvenient: > We need to create an archive
[jira] [Updated] (MNG-7707) ${project.basedir} folder creation when running plugin
[ https://issues.apache.org/jira/browse/MNG-7707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7707: Description: When running {{mvn archetype:generate}} in a directory without providing a valid {{{}pom.xml{}}}, a directory named {{{}$\{project.basedir{ is created in the directory where you execute the command from. I could be wrong but the reason which leads me to believe it to be in maven-core is that when I put a breakpoint at the start of the {{exectute()}} method in the [generate mojo|https://github.com/apache/maven-archetype/blob/master/maven-archetype-plugin/src/main/java/org/apache/maven/archetype/mojos/CreateProjectFromArchetypeMojo.java#L177] the directory is already created. was: When running {{mvn archetype:generate}} in a directory without providing a valid {{{}pom.xml{}}}, a directory named {{{}$\{project.basedir{ is created in the directory where you execute the command from. I could be wrong but the reason which leads me to believe it to be in maven-core is that when I put a breakpoint at the start of the {{exectute()}} method in the [generate mojo|https://github.com/apache/maven-archetype/blob/master/maven-archetype-plugin/src/main/java/org/apache/maven/archetype/mojos/CreateProjectFromArchetypeMojo.java#L177] the folder is already created. > ${project.basedir} folder creation when running plugin > -- > > Key: MNG-7707 > URL: https://issues.apache.org/jira/browse/MNG-7707 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-alpha-4, 4.0.0-alpha-5 >Reporter: Giovanni van der Schelde >Priority: Minor > > When running {{mvn archetype:generate}} in a directory without providing a > valid {{{}pom.xml{}}}, a directory named {{{}$\{project.basedir{ is > created in the directory where you execute the command from. > I could be wrong but the reason which leads me to believe it to be in > maven-core is that when I put a breakpoint at the start of the {{exectute()}} > method in the [generate > mojo|https://github.com/apache/maven-archetype/blob/master/maven-archetype-plugin/src/main/java/org/apache/maven/archetype/mojos/CreateProjectFromArchetypeMojo.java#L177] > the directory is already created. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-pmd-plugin] adangel merged pull request #113: Bump apache/maven-gh-actions-shared from 2 to 3
adangel merged PR #113: URL: https://github.com/apache/maven-pmd-plugin/pull/113 -- 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-integration-testing] laeubi commented on pull request #250: Add integrationtest for MNG-7716
laeubi commented on PR #250: URL: https://github.com/apache/maven-integration-testing/pull/250#issuecomment-1453781446 It looks fine :+1: -- 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-integration-testing] michael-o commented on pull request #250: Add integrationtest for MNG-7716
michael-o commented on PR #250: URL: https://github.com/apache/maven-integration-testing/pull/250#issuecomment-1453778065 @laeubi Please double check whether the test is what you expect after my modifications. -- 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-integration-testing] michael-o commented on pull request #250: Add integrationtest for MNG-7716
michael-o commented on PR #250: URL: https://github.com/apache/maven-integration-testing/pull/250#issuecomment-1453759306 > As there was no prefix resolving happening. If plugin addressed by GAV, then it does not happen, only if you use prefix This totally makes and works now, continuing... -- 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-integration-testing] cstamas commented on pull request #250: Add integrationtest for MNG-7716
cstamas commented on PR #250: URL: https://github.com/apache/maven-integration-testing/pull/250#issuecomment-1453746888 As there was no prefix resolving happening. If plugin addressed by GAV, then it does not happen, only if you use prefix -- 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-integration-testing] michael-o commented on pull request #250: Add integrationtest for MNG-7716
michael-o commented on PR #250: URL: https://github.com/apache/maven-integration-testing/pull/250#issuecomment-1453741841 I get this: ``` [INFO] Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] [INFO] Reactor Build Order: [INFO] [INFO] settings [jar] [INFO] base [pom] [INFO] Downloading from central: file:target/null/org/codehaus/mojo/maven-metadata.xml [INFO] Downloading from central: file:target/null/org/apache/maven/plugins/maven-metadata.xml [INFO] [INFO] Reactor Summary: [INFO] [INFO] settings 0.0.1-SNAPSHOT SKIPPED [INFO] base 1.2.3 . SKIPPED [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 0.131 s (Wall Clock) [INFO] Finished at: 2023-03-03T16:22:05+01:00 [INFO] [ERROR] No plugin found for prefix 'versions' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from the repositories [local (/net/home/osipovmi/var/Projekte org.apache.maven.plugin.prefix.NoPluginFoundForPrefixException: No plugin found for prefix 'versions' in the current project and in the plugin groups [org.apache.maven.plugins, org.codehaus.mojo] available from at org.apache.maven.plugin.prefix.internal.DefaultPluginPrefixResolver.resolve (DefaultPluginPrefixResolver.java:94) at org.apache.maven.lifecycle.internal.MojoDescriptorCreator.findPluginForPrefix (MojoDescriptorCreator.java:243) at org.apache.maven.lifecycle.internal.MojoDescriptorCreator.getMojoDescriptor (MojoDescriptorCreator.java:205) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments (DefaultLifecycleTaskSegmentCalculator.java:100) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments (DefaultLifecycleTaskSegmentCalculator.java:82) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:98) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:313) at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:228) ``` because: ``` osipovmi@deblndw011x:~/var/Projekte/mit (MNG-7716 *=) $ find repo/ -name maven-metadata\*.xml | grep versions osipovmi@deblndw011x:~/var/Projekte/mit (MNG-7716 *=) $ find . -name versions-maven-plugin -type d ./repo/org/codehaus/mojo/versions-maven-plugin ``` @gnodet Any idea why the metadata isn't present? It contains the plugin, but the metadata for groupIds aren't registered. -- 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] cstamas closed pull request #1003: [EXPERIMENT] Halve logging
cstamas closed pull request #1003: [EXPERIMENT] Halve logging URL: https://github.com/apache/maven/pull/1003 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-pmd-plugin] adangel merged pull request #111: Bump doxia-sink-api from 1.11.1 to 1.12.0
adangel merged PR #111: URL: https://github.com/apache/maven-pmd-plugin/pull/111 -- 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-420) Reproducible Builds timestamp issue in some cases
[ https://issues.apache.org/jira/browse/MSHADE-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696196#comment-17696196 ] Niels Basjes commented on MSHADE-420: - As a test: I added .mvn/jvm.config to the source tree of tika {code} $ cat content/org/apache/tika/buildcache/tika/.mvn/jvm.config -Duser.timezone=America/New_York {code} I then did a rebuild on that and the full list of changes: - 2 files showed a umask difference: {code} -rw-rw-r-- -rw-r--r-- {code} - ~ 20 files there was an ordering difference in the Export-Package: in their META-INF/MANIFEST.MF - buildcache/tika/tika-batch/target/tika-batch-2.4.0-tests.jar showed a difference about a "Filename:·test-output/" All timestamp related differences were gone. > Reproducible Builds timestamp issue in some cases > - > > Key: MSHADE-420 > URL: https://issues.apache.org/jira/browse/MSHADE-420 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 3.2.4 >Reporter: Herve Boutemy >Priority: Major > > seen in Tika > https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/org/apache/tika/tika-2.4.0.diffoscope > maven-shade-plugin 3.2.4 has an issue with timestamps in unexplained > circumstances: > why does 21-Nov-20 20:25 from reference become 21-Nov-21 01:25 in rebuild? > why does 20-May-14 07:15 from reference become 20-May-14 11:15 in rebuild? > could be related to the timezone of the rebuilder? > {noformat} > 21 / 44 target/reference/tika-parser-nlp-package-2.4.0.jar > tika-parsers/tika-parsers-ml/tika-parser-nlp-package/target/tika-parser-nlp-package-2.4.0.jar > --- target/reference/tika-parser-nlp-package-2.4.0.jar > +++ > tika-parsers/tika-parsers-ml/tika-parser-nlp-package/target/tika-parser-nlp-package-2.4.0.jar > ├── zipinfo {} > │ @@ -9868,1231 +9868,1231 @@ > │ -rw 2.0 fat 2653 bl defN 22-Apr-08 17:41 > schemas/wsdl/ws-addr-wsdl.xsd > │ -rw 2.0 fat 5591 bl defN 22-Apr-08 17:41 > schemas/wsdl/ws-addr.xsd > │ -rw 2.0 fat 1606 bl defN 22-Apr-08 17:41 schemas/wsdl/wsdl.xjb > │ -rw 2.0 fat12126 bl defN 22-Apr-08 17:41 schemas/wsdl/wsdl.xsd > │ -rw 2.0 fat 8198 bl defN 22-Apr-08 17:41 schemas/wsdl/wsrm.xsd > │ -rw 2.0 fat 932 bl defN 22-Apr-08 17:41 schemas/wsdl/xmime.xsd > │ -rw 2.0 fat 5840 bl defN 22-Apr-08 17:41 schemas/wsdl/xml.xsd > │ --rw 2.0 fat0 bl defN 21-Nov-20 20:25 > META-INF/maven/com.fasterxml.woodstox/ > │ --rw 2.0 fat0 bl defN 21-Nov-20 20:25 > META-INF/maven/com.fasterxml.woodstox/woodstox-core/ > │ --rw 2.0 fat 70 bl defN 21-Nov-20 20:25 > META-INF/maven/com.fasterxml.woodstox/woodstox-core/pom.properties > │ --rw 2.0 fat15917 bl defN 21-Nov-20 20:25 > META-INF/maven/com.fasterxml.woodstox/woodstox-core/pom.xml > │ --rw 2.0 fat0 bl defN 21-Nov-20 20:25 com/ctc/ > │ --rw 2.0 fat0 bl defN 21-Nov-20 20:25 com/ctc/wstx/ > │ --rw 2.0 fat0 bl defN 21-Nov-20 20:25 com/ctc/wstx/api/ > ... > │ --rw 2.0 fat 722 bl defN 20-May-14 07:15 > org/codehaus/stax2/validation/XMLValidationSchema.class > │ --rw 2.0 fat 7795 bl defN 20-May-14 07:15 > org/codehaus/stax2/validation/XMLValidationSchemaFactory.class > │ --rw 2.0 fat 1801 bl defN 20-May-14 07:15 > org/codehaus/stax2/validation/XMLValidator.class > │ +-rw 2.0 fat0 bl defN 21-Nov-21 01:25 > META-INF/maven/com.fasterxml.woodstox/ > │ +-rw 2.0 fat0 bl defN 21-Nov-21 01:25 > META-INF/maven/com.fasterxml.woodstox/woodstox-core/ > │ +-rw 2.0 fat 70 bl defN 21-Nov-21 01:25 > META-INF/maven/com.fasterxml.woodstox/woodstox-core/pom.properties > │ +-rw 2.0 fat15917 bl defN 21-Nov-21 01:25 > META-INF/maven/com.fasterxml.woodstox/woodstox-core/pom.xml > │ +-rw 2.0 fat0 bl defN 21-Nov-21 01:25 com/ctc/ > │ +-rw 2.0 fat0 bl defN 21-Nov-21 01:25 com/ctc/wstx/ > │ +-rw 2.0 fat0 bl defN 21-Nov-21 01:25 com/ctc/wstx/api/ > ... > │ +-rw 2.0 fat 722 bl defN 20-May-14 11:15 > org/codehaus/stax2/validation/XMLValidationSchema.class > │ +-rw 2.0 fat 7795 bl defN 20-May-14 11:15 > org/codehaus/stax2/validation/XMLValidationSchemaFactory.class > │ +-rw 2.0 fat 1801 bl defN 20-May-14 11:15 > org/codehaus/stax2/validation/XMLValidator.class > │ -rw 2.0 fat0 bl defN 21-Sep-14 14:41 > META-INF/maven/org.apache.ws.xmlschema/ > │ -rw 2.0 fat0 bl defN 21-Sep-14 14:41 > META-INF/maven/org.apache.ws.xmlschema/xmlschema-core/ > │ -rw 2.0 fat 146 bl defN 21-Sep-14 14:41 > META-INF/maven/org.apache.ws.xmlschema/xmlschema-core/pom.properties > │
[GitHub] [maven-pmd-plugin] adangel merged pull request #108: Bump wagon-http-lightweight from 3.5.2 to 3.5.3
adangel merged PR #108: URL: https://github.com/apache/maven-pmd-plugin/pull/108 -- 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-integration-testing] michael-o commented on pull request #250: Add integrationtest for MNG-7716
michael-o commented on PR #250: URL: https://github.com/apache/maven-integration-testing/pull/250#issuecomment-1453556067 Let me test... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (MASSEMBLY-843) finalName as readonly parameter makes common usecases very complicated
[ https://issues.apache.org/jira/browse/MASSEMBLY-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696156#comment-17696156 ] Christopher Tubbs edited comment on MASSEMBLY-843 at 3/3/23 1:44 PM: - Using Maven 3.9.0 and maven-assembly-plugin 3.5.0, I see that using {{finalName}} is generating a warning: "Parameter 'finalName' is read-only, must not be used in configuration". However, using {{finalName}} appears to be the only way you can change the name of the base directory inside the assembly tarball, as per this StackOverflow answer: [https://stackoverflow.com/a/12182912] This needs to be settable, preferably without a warning, so we can override the base directory name inside the assembly. I looked for other options that might be able to do that, and I could not find any. To be clear, {{}} ($\{project.build.finalName\}) does appear to be read-only, but I'm talking about {{}} in the assembly, which is generating the warning, even though setting it still works, so it appears to now be a hidden undocumented feature, that generates the warning. The use case here is not to override the name of the artifact, whose name still follows conventions... the use case is to override the directory name inside the artifact. was (Author: ctubbsii): Using Maven 3.9.0 and maven-assembly-plugin 3.5.0, I see that using {{finalName}} is generating a warning: "Parameter 'finalName' is read-only, must not be used in configuration". However, using {{finalName}} appears to be the only way you can change the name of the base directory inside the assembly tarball, as per this StackOverflow answer: [https://stackoverflow.com/a/12182912] This needs to be settable, preferably without a warning, so we can override the base directory name inside the assembly. I looked for other options that might be able to do that, and I could not find any. To be clear, {{}} ($\{project.build.finalName\}) does appear to be read-only, but I'm talking about {{}} in the assembly, which is generating the warning, even though setting it still works, so it appears to now be a hidden undocumented feature, that generates the warning. > finalName as readonly parameter makes common usecases very complicated > -- > > Key: MASSEMBLY-843 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-843 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Ulf Dreyer >Priority: Major > > The "improvement" done in MASSEMBLY-817 makes some usecases very inconvenient: > We need to create an archive with one stable name (independent of e.g. > version) so we don't have to propagate these information to a bunch of > scripts. > The general solution (i.e. Stack-overflow) refers exactly to the finalName: > [http://stackoverflow.com/questions/20697144/can-not-set-the-final-jar-name-with-maven-assembly-plugin] > *Please change finalName back to a settable property.* > It being settable does not hurt anyone satisfied with the default naming > convention but makes some usecases vastly simpler (otherwise you have to > rename the artifact using yet another plugin or propagate version info > possibly through a chain of scripts) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MASSEMBLY-843) finalName as readonly parameter makes common usecases very complicated
[ https://issues.apache.org/jira/browse/MASSEMBLY-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696156#comment-17696156 ] Christopher Tubbs edited comment on MASSEMBLY-843 at 3/3/23 1:42 PM: - Using Maven 3.9.0 and maven-assembly-plugin 3.5.0, I see that using {{finalName}} is generating a warning: "Parameter 'finalName' is read-only, must not be used in configuration". However, using {{finalName}} appears to be the only way you can change the name of the base directory inside the assembly tarball, as per this StackOverflow answer: [https://stackoverflow.com/a/12182912] This needs to be settable, preferably without a warning, so we can override the base directory name inside the assembly. I looked for other options that might be able to do that, and I could not find any. To be clear, {{}} ($\{project.build.finalName\}) does appear to be read-only, but I'm talking about {{}} in the assembly, which is generating the warning, even though setting it still works, so it appears to now be a hidden undocumented feature, that generates the warning. was (Author: ctubbsii): Using Maven 3.9.0 and maven-assembly-plugin 3.5.0, I see that using {{finalName}} is generating a warning: "Parameter 'finalName' is read-only, must not be used in configuration". However, using {{finalName}} appears to be the only way you can change the name of the base directory inside the assembly tarball, as per this StackOverflow answer: [https://stackoverflow.com/a/12182912] This needs to be settable, preferably without a warning, so we can override the base directory name inside the assembly. I looked for other options that might be able to do that, and I could not find any. To be clear, {{}} ({{ $\{project.build.finalName\} }}) does appear to be read-only, but I'm talking about {{}} in the assembly, which is generating the warning, even though setting it still works, so it appears to now be a hidden undocumented feature, that generates the warning. > finalName as readonly parameter makes common usecases very complicated > -- > > Key: MASSEMBLY-843 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-843 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Ulf Dreyer >Priority: Major > > The "improvement" done in MASSEMBLY-817 makes some usecases very inconvenient: > We need to create an archive with one stable name (independent of e.g. > version) so we don't have to propagate these information to a bunch of > scripts. > The general solution (i.e. Stack-overflow) refers exactly to the finalName: > [http://stackoverflow.com/questions/20697144/can-not-set-the-final-jar-name-with-maven-assembly-plugin] > *Please change finalName back to a settable property.* > It being settable does not hurt anyone satisfied with the default naming > convention but makes some usecases vastly simpler (otherwise you have to > rename the artifact using yet another plugin or propagate version info > possibly through a chain of scripts) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MASSEMBLY-843) finalName as readonly parameter makes common usecases very complicated
[ https://issues.apache.org/jira/browse/MASSEMBLY-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696156#comment-17696156 ] Christopher Tubbs edited comment on MASSEMBLY-843 at 3/3/23 1:42 PM: - Using Maven 3.9.0 and maven-assembly-plugin 3.5.0, I see that using {{finalName}} is generating a warning: "Parameter 'finalName' is read-only, must not be used in configuration". However, using {{finalName}} appears to be the only way you can change the name of the base directory inside the assembly tarball, as per this StackOverflow answer: [https://stackoverflow.com/a/12182912] This needs to be settable, preferably without a warning, so we can override the base directory name inside the assembly. I looked for other options that might be able to do that, and I could not find any. To be clear, {{}} ({{ $\{project.build.finalName\} }}) does appear to be read-only, but I'm talking about {{}} in the assembly, which is generating the warning, even though setting it still works, so it appears to now be a hidden undocumented feature, that generates the warning. was (Author: ctubbsii): Using Maven 3.9.0 and maven-assembly-plugin 3.5.0, I see that using {{finalName}} is generating a warning: "Parameter 'finalName' is read-only, must not be used in configuration". However, using {{finalName}} appears to be the only way you can change the name of the base directory inside the assembly tarball, as per this StackOverflow answer: [https://stackoverflow.com/a/12182912] This needs to be settable, preferably without a warning, so we can override the base directory name inside the assembly. I looked for other options that might be able to do that, and I could not find any. To be clear, {{}} ({{ ${project.build.finalName} }}) does appear to be read-only, but I'm talking about {{}} in the assembly, which is generating the warning, even though setting it still works, so it appears to now be a hidden undocumented feature, that generates the warning. > finalName as readonly parameter makes common usecases very complicated > -- > > Key: MASSEMBLY-843 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-843 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Ulf Dreyer >Priority: Major > > The "improvement" done in MASSEMBLY-817 makes some usecases very inconvenient: > We need to create an archive with one stable name (independent of e.g. > version) so we don't have to propagate these information to a bunch of > scripts. > The general solution (i.e. Stack-overflow) refers exactly to the finalName: > [http://stackoverflow.com/questions/20697144/can-not-set-the-final-jar-name-with-maven-assembly-plugin] > *Please change finalName back to a settable property.* > It being settable does not hurt anyone satisfied with the default naming > convention but makes some usecases vastly simpler (otherwise you have to > rename the artifact using yet another plugin or propagate version info > possibly through a chain of scripts) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MASSEMBLY-843) finalName as readonly parameter makes common usecases very complicated
[ https://issues.apache.org/jira/browse/MASSEMBLY-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696156#comment-17696156 ] Christopher Tubbs edited comment on MASSEMBLY-843 at 3/3/23 1:42 PM: - Using Maven 3.9.0 and maven-assembly-plugin 3.5.0, I see that using {{finalName}} is generating a warning: "Parameter 'finalName' is read-only, must not be used in configuration". However, using {{finalName}} appears to be the only way you can change the name of the base directory inside the assembly tarball, as per this StackOverflow answer: [https://stackoverflow.com/a/12182912] This needs to be settable, preferably without a warning, so we can override the base directory name inside the assembly. I looked for other options that might be able to do that, and I could not find any. To be clear, {{}} ({{ ${project.build.finalName} }}) does appear to be read-only, but I'm talking about {{}} in the assembly, which is generating the warning, even though setting it still works, so it appears to now be a hidden undocumented feature, that generates the warning. was (Author: ctubbsii): Using Maven 3.9.0 and maven-assembly-plugin 3.5.0, I see that using {{finalName}} is generating a warning: "Parameter 'finalName' is read-only, must not be used in configuration". However, using {{finalName}} appears to be the only way you can change the name of the base directory inside the assembly tarball, as per this StackOverflow answer: [https://stackoverflow.com/a/12182912] This needs to be settable, preferably without a warning, so we can override the base directory name inside the assembly. I looked for other options that might be able to do that, and I could not find any. To be clear, \{{}} (\{{ ${project.build.finalName} }}) does appear to be read-only, but I'm talking about {{}} in the assembly, which is generating the warning, even though setting it still works, so it appears to now be a hidden undocumented feature, that generates the warning. > finalName as readonly parameter makes common usecases very complicated > -- > > Key: MASSEMBLY-843 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-843 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Ulf Dreyer >Priority: Major > > The "improvement" done in MASSEMBLY-817 makes some usecases very inconvenient: > We need to create an archive with one stable name (independent of e.g. > version) so we don't have to propagate these information to a bunch of > scripts. > The general solution (i.e. Stack-overflow) refers exactly to the finalName: > [http://stackoverflow.com/questions/20697144/can-not-set-the-final-jar-name-with-maven-assembly-plugin] > *Please change finalName back to a settable property.* > It being settable does not hurt anyone satisfied with the default naming > convention but makes some usecases vastly simpler (otherwise you have to > rename the artifact using yet another plugin or propagate version info > possibly through a chain of scripts) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MASSEMBLY-843) finalName as readonly parameter makes common usecases very complicated
[ https://issues.apache.org/jira/browse/MASSEMBLY-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696156#comment-17696156 ] Christopher Tubbs commented on MASSEMBLY-843: - Using Maven 3.9.0 and maven-assembly-plugin 3.5.0, I see that using {{finalName}} is generating a warning: "Parameter 'finalName' is read-only, must not be used in configuration". However, using {{finalName}} appears to be the only way you can change the name of the base directory inside the assembly tarball, as per this StackOverflow answer: [https://stackoverflow.com/a/12182912] This needs to be settable, preferably without a warning, so we can override the base directory name inside the assembly. I looked for other options that might be able to do that, and I could not find any. To be clear, \{{}} (\{{ ${project.build.finalName} }}) does appear to be read-only, but I'm talking about {{}} in the assembly, which is generating the warning, even though setting it still works, so it appears to now be a hidden undocumented feature, that generates the warning. > finalName as readonly parameter makes common usecases very complicated > -- > > Key: MASSEMBLY-843 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-843 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Ulf Dreyer >Priority: Major > > The "improvement" done in MASSEMBLY-817 makes some usecases very inconvenient: > We need to create an archive with one stable name (independent of e.g. > version) so we don't have to propagate these information to a bunch of > scripts. > The general solution (i.e. Stack-overflow) refers exactly to the finalName: > [http://stackoverflow.com/questions/20697144/can-not-set-the-final-jar-name-with-maven-assembly-plugin] > *Please change finalName back to a settable property.* > It being settable does not hurt anyone satisfied with the default naming > convention but makes some usecases vastly simpler (otherwise you have to > rename the artifact using yet another plugin or propagate version info > possibly through a chain of scripts) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7718) Maven 3.9.0 auto detect test and download surefire-plugin
[ https://issues.apache.org/jira/browse/MNG-7718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7718: Fix Version/s: waiting-for-feedback wontfix-candidate > Maven 3.9.0 auto detect test and download surefire-plugin > - > > Key: MNG-7718 > URL: https://issues.apache.org/jira/browse/MNG-7718 > Project: Maven > Issue Type: Dependency upgrade >Affects Versions: 3.9.0 >Reporter: Durgesh Mishra >Priority: Minor > Labels: test-stability > Fix For: waiting-for-feedback, wontfix-candidate > > > After the maven version upgrade to 3.9.0, Automatically surefire plugin > download and run the test case during build process. > For this version we don't need to pass explicitly maven surefire plugin. > Please let me know if this is expected or bug ? > Because i can't see any release notes regarding this feature. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MPMD-365) Support Java 20
[ https://issues.apache.org/jira/browse/MPMD-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Dangel closed MPMD-365. --- Resolution: Fixed > Support Java 20 > --- > > Key: MPMD-365 > URL: https://issues.apache.org/jira/browse/MPMD-365 > Project: Maven PMD Plugin > Issue Type: New Feature > Components: PMD >Reporter: Andreas Dangel >Assignee: Andreas Dangel >Priority: Major > Fix For: 3.21.0 > > > With the PMD version 6.55.0, Java 20 is supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPMD-365) Support Java 20
[ https://issues.apache.org/jira/browse/MPMD-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696145#comment-17696145 ] Andreas Dangel commented on MPMD-365: - Fixed: [https://gitbox.apache.org/repos/asf?p=maven-pmd-plugin.git;a=commit;h=c8782ca85d9c12dc1138292d091cf3dda53461ac] > Support Java 20 > --- > > Key: MPMD-365 > URL: https://issues.apache.org/jira/browse/MPMD-365 > Project: Maven PMD Plugin > Issue Type: New Feature > Components: PMD >Reporter: Andreas Dangel >Assignee: Andreas Dangel >Priority: Major > Fix For: 3.21.0 > > > With the PMD version 6.55.0, Java 20 is supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-pmd-plugin] adangel merged pull request #116: [MPMD-365] - Support Java 20
adangel merged PR #116: URL: https://github.com/apache/maven-pmd-plugin/pull/116 -- 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] (MPMD-365) Support Java 20
[ https://issues.apache.org/jira/browse/MPMD-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Dangel updated MPMD-365: Fix Version/s: 3.21.0 (was: 3.18.0) > Support Java 20 > --- > > Key: MPMD-365 > URL: https://issues.apache.org/jira/browse/MPMD-365 > Project: Maven PMD Plugin > Issue Type: New Feature > Components: PMD >Reporter: Andreas Dangel >Assignee: Andreas Dangel >Priority: Major > Fix For: 3.21.0 > > > With the PMD version 6.55.0, Java 20 is supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-pmd-plugin] adangel opened a new pull request, #116: [MPMD-365] - Support Java 20
adangel opened a new pull request, #116: URL: https://github.com/apache/maven-pmd-plugin/pull/116 https://issues.apache.org/jira/browse/MPMD-365 Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MPMD) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MPMD-XXX] - Subject of the JIRA Ticket`, where you replace `MPMD-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-pmd-plugin] adangel merged pull request #115: [MPMD-364] - Upgrade to PMD 6.55.0
adangel merged PR #115: URL: https://github.com/apache/maven-pmd-plugin/pull/115 -- 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] (MPMD-364) Upgrade to PMD 6.55.0
[ https://issues.apache.org/jira/browse/MPMD-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Dangel updated MPMD-364: Summary: Upgrade to PMD 6.55.0 (was: Upgrade to PMD 6.54.0) > Upgrade to PMD 6.55.0 > - > > Key: MPMD-364 > URL: https://issues.apache.org/jira/browse/MPMD-364 > Project: Maven PMD Plugin > Issue Type: Dependency upgrade > Components: CPD, PMD >Reporter: Andreas Dangel >Assignee: Andreas Dangel >Priority: Major > Fix For: 3.21.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHADE-420) Reproducible Builds timestamp issue in some cases
[ https://issues.apache.org/jira/browse/MSHADE-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696128#comment-17696128 ] Niels Basjes commented on MSHADE-420: - For reference: I added {{-Duser.timezone=UTC}} to the {{.mvn/jvm.config}} of my own project to ensure this point to be reproducible. https://github.com/nielsbasjes/yauaa/blob/main/.mvn/jvm.config > Reproducible Builds timestamp issue in some cases > - > > Key: MSHADE-420 > URL: https://issues.apache.org/jira/browse/MSHADE-420 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 3.2.4 >Reporter: Herve Boutemy >Priority: Major > > seen in Tika > https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/org/apache/tika/tika-2.4.0.diffoscope > maven-shade-plugin 3.2.4 has an issue with timestamps in unexplained > circumstances: > why does 21-Nov-20 20:25 from reference become 21-Nov-21 01:25 in rebuild? > why does 20-May-14 07:15 from reference become 20-May-14 11:15 in rebuild? > could be related to the timezone of the rebuilder? > {noformat} > 21 / 44 target/reference/tika-parser-nlp-package-2.4.0.jar > tika-parsers/tika-parsers-ml/tika-parser-nlp-package/target/tika-parser-nlp-package-2.4.0.jar > --- target/reference/tika-parser-nlp-package-2.4.0.jar > +++ > tika-parsers/tika-parsers-ml/tika-parser-nlp-package/target/tika-parser-nlp-package-2.4.0.jar > ├── zipinfo {} > │ @@ -9868,1231 +9868,1231 @@ > │ -rw 2.0 fat 2653 bl defN 22-Apr-08 17:41 > schemas/wsdl/ws-addr-wsdl.xsd > │ -rw 2.0 fat 5591 bl defN 22-Apr-08 17:41 > schemas/wsdl/ws-addr.xsd > │ -rw 2.0 fat 1606 bl defN 22-Apr-08 17:41 schemas/wsdl/wsdl.xjb > │ -rw 2.0 fat12126 bl defN 22-Apr-08 17:41 schemas/wsdl/wsdl.xsd > │ -rw 2.0 fat 8198 bl defN 22-Apr-08 17:41 schemas/wsdl/wsrm.xsd > │ -rw 2.0 fat 932 bl defN 22-Apr-08 17:41 schemas/wsdl/xmime.xsd > │ -rw 2.0 fat 5840 bl defN 22-Apr-08 17:41 schemas/wsdl/xml.xsd > │ --rw 2.0 fat0 bl defN 21-Nov-20 20:25 > META-INF/maven/com.fasterxml.woodstox/ > │ --rw 2.0 fat0 bl defN 21-Nov-20 20:25 > META-INF/maven/com.fasterxml.woodstox/woodstox-core/ > │ --rw 2.0 fat 70 bl defN 21-Nov-20 20:25 > META-INF/maven/com.fasterxml.woodstox/woodstox-core/pom.properties > │ --rw 2.0 fat15917 bl defN 21-Nov-20 20:25 > META-INF/maven/com.fasterxml.woodstox/woodstox-core/pom.xml > │ --rw 2.0 fat0 bl defN 21-Nov-20 20:25 com/ctc/ > │ --rw 2.0 fat0 bl defN 21-Nov-20 20:25 com/ctc/wstx/ > │ --rw 2.0 fat0 bl defN 21-Nov-20 20:25 com/ctc/wstx/api/ > ... > │ --rw 2.0 fat 722 bl defN 20-May-14 07:15 > org/codehaus/stax2/validation/XMLValidationSchema.class > │ --rw 2.0 fat 7795 bl defN 20-May-14 07:15 > org/codehaus/stax2/validation/XMLValidationSchemaFactory.class > │ --rw 2.0 fat 1801 bl defN 20-May-14 07:15 > org/codehaus/stax2/validation/XMLValidator.class > │ +-rw 2.0 fat0 bl defN 21-Nov-21 01:25 > META-INF/maven/com.fasterxml.woodstox/ > │ +-rw 2.0 fat0 bl defN 21-Nov-21 01:25 > META-INF/maven/com.fasterxml.woodstox/woodstox-core/ > │ +-rw 2.0 fat 70 bl defN 21-Nov-21 01:25 > META-INF/maven/com.fasterxml.woodstox/woodstox-core/pom.properties > │ +-rw 2.0 fat15917 bl defN 21-Nov-21 01:25 > META-INF/maven/com.fasterxml.woodstox/woodstox-core/pom.xml > │ +-rw 2.0 fat0 bl defN 21-Nov-21 01:25 com/ctc/ > │ +-rw 2.0 fat0 bl defN 21-Nov-21 01:25 com/ctc/wstx/ > │ +-rw 2.0 fat0 bl defN 21-Nov-21 01:25 com/ctc/wstx/api/ > ... > │ +-rw 2.0 fat 722 bl defN 20-May-14 11:15 > org/codehaus/stax2/validation/XMLValidationSchema.class > │ +-rw 2.0 fat 7795 bl defN 20-May-14 11:15 > org/codehaus/stax2/validation/XMLValidationSchemaFactory.class > │ +-rw 2.0 fat 1801 bl defN 20-May-14 11:15 > org/codehaus/stax2/validation/XMLValidator.class > │ -rw 2.0 fat0 bl defN 21-Sep-14 14:41 > META-INF/maven/org.apache.ws.xmlschema/ > │ -rw 2.0 fat0 bl defN 21-Sep-14 14:41 > META-INF/maven/org.apache.ws.xmlschema/xmlschema-core/ > │ -rw 2.0 fat 146 bl defN 21-Sep-14 14:41 > META-INF/maven/org.apache.ws.xmlschema/xmlschema-core/pom.properties > │ -rw 2.0 fat 6857 bl defN 21-Sep-14 14:41 > META-INF/maven/org.apache.ws.xmlschema/xmlschema-core/pom.xml > │ -rw 2.0 fat0 bl defN 21-Sep-14 14:41 org/apache/ws/ > │ -rw 2.0 fat0 bl defN 21-Sep-14 14:41 org/apache/ws/commons/ > │ -rw 2.0 fat0 bl defN 21-Sep-14 14:41 > org/apache/ws/commons/schema/ > {noformat}
[jira] [Commented] (MNG-7718) Maven 3.9.0 auto detect test and download surefire-plugin
[ https://issues.apache.org/jira/browse/MNG-7718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696127#comment-17696127 ] Tamas Cservenak commented on MNG-7718: -- Can you provide a reproducer project? > Maven 3.9.0 auto detect test and download surefire-plugin > - > > Key: MNG-7718 > URL: https://issues.apache.org/jira/browse/MNG-7718 > Project: Maven > Issue Type: Dependency upgrade >Affects Versions: 3.9.0 >Reporter: Durgesh Mishra >Priority: Minor > Labels: test-stability > > After the maven version upgrade to 3.9.0, Automatically surefire plugin > download and run the test case during build process. > For this version we don't need to pass explicitly maven surefire plugin. > Please let me know if this is expected or bug ? > Because i can't see any release notes regarding this feature. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHADE-420) Reproducible Builds timestamp issue in some cases
[ https://issues.apache.org/jira/browse/MSHADE-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696126#comment-17696126 ] Niels Basjes commented on MSHADE-420: - Some basic investigation {code:bash} $ unzip -l m2/repository/com/fasterxml/woodstox/woodstox-core/6.2.7/woodstox-core-6.2.7.jar | fgrep com/ctc/wstx/api/WriterConfig.class 16366 2021-11-21 02:25 com/ctc/wstx/api/WriterConfig.class {code} {code:bash} $ unzip -l content/org/apache/tika/buildcache/tika/target/reference/tika-parser-nlp-package-2.4.0.jar | fgrep com/ctc/wstx/api/WriterConfig.class 16366 2021-11-20 20:25 com/ctc/wstx/api/WriterConfig.class {code} {code:bash} $ unzip -l content/org/apache/tika/buildcache/tika/tika-parsers/tika-parsers-ml/tika-parser-nlp-package/target/tika-parser-nlp-package-2.4.0.jar | fgrep com/ctc/wstx/api/WriterConfig.class 16366 2021-11-21 01:25 com/ctc/wstx/api/WriterConfig.class {code} I then used a shell in the rebuild docker image and only rebuilt this specific jar file. {code:bash} $ mvn -Papache-release clean package -DskipTests -Dmaven.javadoc.skip -Dgpg.skip -Dossindex.skip -Duser.home=/var/maven/ {code} Check: {code:bash} $ unzip -l content/org/apache/tika/buildcache/tika/tika-parsers/tika-parsers-ml/tika-parser-nlp-package/target/tika-parser-nlp-package-2.4.0.jar | fgrep com/ctc/wstx/api/WriterConfig.class 16366 2021-11-21 01:25 com/ctc/wstx/api/WriterConfig.class {code} Ok, still the same. {code:bash} $ export TZ=America/New_York $ mvn -Papache-release clean package -DskipTests -Dmaven.javadoc.skip -Dgpg.skip -Dossindex.skip -Duser.home=/var/maven/ {code} Check again: {code:bash} $ unzip -l content/org/apache/tika/buildcache/tika/tika-parsers/tika-parsers-ml/tika-parser-nlp-package/target/tika-parser-nlp-package-2.4.0.jar | fgrep com/ctc/wstx/api/WriterConfig.class 16366 2021-11-20 20:25 com/ctc/wstx/api/WriterConfig.class {code} Ok, looks good. {code:bash} $ diffoscope content/org/apache/tika/buildcache/tika/target/reference/tika-parser-nlp-package-2.4.0.jar content/org/apache/tika/buildcache/tika/tika-parsers/tika-parsers-ml/tika-parser-nlp-package/target/tika-parser-nlp-package-2.4.0.jar {code} and no output ! {code:bash} $ md5sum content/org/apache/tika/buildcache/tika/target/reference/tika-parser-nlp-package-2.4.0.jar content/org/apache/tika/buildcache/tika/tika-parsers/tika-parsers-ml/tika-parser-nlp-package/target/tika-parser-nlp-package-2.4.0.jar 5840fe7dbbbfb1b2ebb5973733621955 content/org/apache/tika/buildcache/tika/target/reference/tika-parser-nlp-package-2.4.0.jar 5840fe7dbbbfb1b2ebb5973733621955 content/org/apache/tika/buildcache/tika/tika-parsers/tika-parsers-ml/tika-parser-nlp-package/target/tika-parser-nlp-package-2.4.0.jar {code} So using {{export TZ=America/New_York}} this specific file is fully reproducible. The docker image at hand is configured to having UTC as the timezone. My current assessment is tika has 2 problems I see right now: # It must explicitly be reproduced under {{export TZ=America/New_York}} # The used bundle plugin does not guarantee ordering of the Exports Most importantly: I say this is not a maven-shade-plugin problem ! > Reproducible Builds timestamp issue in some cases > - > > Key: MSHADE-420 > URL: https://issues.apache.org/jira/browse/MSHADE-420 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 3.2.4 >Reporter: Herve Boutemy >Priority: Major > > seen in Tika > https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/org/apache/tika/tika-2.4.0.diffoscope > maven-shade-plugin 3.2.4 has an issue with timestamps in unexplained > circumstances: > why does 21-Nov-20 20:25 from reference become 21-Nov-21 01:25 in rebuild? > why does 20-May-14 07:15 from reference become 20-May-14 11:15 in rebuild? > could be related to the timezone of the rebuilder? > {noformat} > 21 / 44 target/reference/tika-parser-nlp-package-2.4.0.jar > tika-parsers/tika-parsers-ml/tika-parser-nlp-package/target/tika-parser-nlp-package-2.4.0.jar > --- target/reference/tika-parser-nlp-package-2.4.0.jar > +++ > tika-parsers/tika-parsers-ml/tika-parser-nlp-package/target/tika-parser-nlp-package-2.4.0.jar > ├── zipinfo {} > │ @@ -9868,1231 +9868,1231 @@ > │ -rw 2.0 fat 2653 bl defN 22-Apr-08 17:41 > schemas/wsdl/ws-addr-wsdl.xsd > │ -rw 2.0 fat 5591 bl defN 22-Apr-08 17:41 > schemas/wsdl/ws-addr.xsd > │ -rw 2.0 fat 1606 bl defN 22-Apr-08 17:41 schemas/wsdl/wsdl.xjb > │ -rw 2.0 fat12126 bl defN 22-Apr-08 17:41 schemas/wsdl/wsdl.xsd > │ -rw 2.0 fat 8198 bl defN 22-Apr-08 17:41 schemas/wsdl/wsrm.xsd > │ -rw 2.0 fat 932 bl defN 22-Apr-08 17:41 schemas/wsdl/xmime.xsd > │ -rw 2.0 fat
[jira] [Created] (MNG-7718) Maven 3.9.0 auto detect test and download surefire-plugin
Durgesh Mishra created MNG-7718: --- Summary: Maven 3.9.0 auto detect test and download surefire-plugin Key: MNG-7718 URL: https://issues.apache.org/jira/browse/MNG-7718 Project: Maven Issue Type: Dependency upgrade Affects Versions: 3.9.0 Reporter: Durgesh Mishra After the maven version upgrade to 3.9.0, Automatically surefire plugin download and run the test case during build process. For this version we don't need to pass explicitly maven surefire plugin. Please let me know if this is expected or bug ? Because i can't see any release notes regarding this feature. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPMD-365) Support Java 20
Andreas Dangel created MPMD-365: --- Summary: Support Java 20 Key: MPMD-365 URL: https://issues.apache.org/jira/browse/MPMD-365 Project: Maven PMD Plugin Issue Type: New Feature Components: PMD Reporter: Andreas Dangel Assignee: Andreas Dangel Fix For: 3.18.0 With the next PMD version 6.48.0, Java 19 is supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPMD-365) Support Java 20
[ https://issues.apache.org/jira/browse/MPMD-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Dangel updated MPMD-365: Description: With the PMD version 6.55.0, Java 20 is supported. (was: With the next PMD version 6.48.0, Java 19 is supported.) > Support Java 20 > --- > > Key: MPMD-365 > URL: https://issues.apache.org/jira/browse/MPMD-365 > Project: Maven PMD Plugin > Issue Type: New Feature > Components: PMD >Reporter: Andreas Dangel >Assignee: Andreas Dangel >Priority: Major > Fix For: 3.18.0 > > > With the PMD version 6.55.0, Java 20 is supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-integration-testing] laeubi commented on pull request #250: Add integrationtest for MNG-7716
laeubi commented on PR #250: URL: https://github.com/apache/maven-integration-testing/pull/250#issuecomment-1453351858 @michael-o @cstamas the test suite now runs fine (even though its not clear for me what it runs on, latest release?) so please review again. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-integration-testing] laeubi commented on a diff in pull request #250: Add integrationtest for MNG-7716
laeubi commented on code in PR #250: URL: https://github.com/apache/maven-integration-testing/pull/250#discussion_r1124305535 ## core-it-suite/src/test/java/org/apache/maven/it/MavenITmng7716BuildDeadlock.java: ## @@ -0,0 +1,68 @@ +package org.apache.maven.it; + +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +import java.io.File; + +import org.apache.maven.shared.verifier.Verifier; +import org.apache.maven.shared.verifier.util.ResourceExtractor; +import org.junit.jupiter.api.Test; + +/** + * This is a test set for + * https://issues.apache.org/jira/browse/MNG-7716;>MNG-7716. + * Executing the project should not deadlock + * + */ +class MavenITmng7716BuildDeadlock +extends AbstractMavenIntegrationTestCase +{ + +public MavenITmng7716BuildDeadlock() +{ +super( "[3.8.0,)" ); +} + +/** + * Verify that maven invocation works (no NPE/error happens). + * + * @throws Exception in case of failure + */ +@Test +void testSingleMojoNoPom() +throws Exception +{ +File testDir = ResourceExtractor.simpleExtractResources( getClass(), "/mng-7716" ); + +Verifier verifier = newVerifier( testDir.getAbsolutePath() ); +verifier.addCliArgument( "install" ); +verifier.addCliArgument( "-f" ); +verifier.addCliArgument( "settings" ); +verifier.execute(); +verifier.verifyErrorFreeLog(); +Verifier verifier2 = newVerifier( testDir.getAbsolutePath() ); +verifier2.addCliArgument( "-T1C" ); +verifier2.addCliArgument( "versions:set" ); Review Comment: Fixed -- 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-integration-testing] laeubi commented on a diff in pull request #250: Add integrationtest for MNG-7716
laeubi commented on code in PR #250: URL: https://github.com/apache/maven-integration-testing/pull/250#discussion_r1124290633 ## core-it-suite/src/test/java/org/apache/maven/it/MavenITmng7716BuildDeadlock.java: ## @@ -0,0 +1,68 @@ +package org.apache.maven.it; + +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +import java.io.File; + +import org.apache.maven.shared.verifier.Verifier; +import org.apache.maven.shared.verifier.util.ResourceExtractor; +import org.junit.jupiter.api.Test; + +/** + * This is a test set for + * https://issues.apache.org/jira/browse/MNG-7716;>MNG-7716. + * Executing the project should not deadlock + * + */ +class MavenITmng7716BuildDeadlock +extends AbstractMavenIntegrationTestCase +{ + +public MavenITmng7716BuildDeadlock() +{ +super( "[3.8.8,)[3.9.1,)[4.0.0-alpha-5,)" ); Review Comment: Adjusted! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MRESOLVER-315) Implement preemptive authentication feature for transport-http
[ https://issues.apache.org/jira/browse/MRESOLVER-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-315: -- Issue Type: Improvement (was: New Feature) > Implement preemptive authentication feature for transport-http > -- > > Key: MRESOLVER-315 > URL: https://issues.apache.org/jira/browse/MRESOLVER-315 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Slawomir Jaranowski >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.6 > > > We can set {{Preemptive Authentication}} for wagon transports, like: > https://maven.apache.org/guides/mini/guide-http-settings.html#Example:_Using_Preemptive_Authentication > Such feature will be also valuable for native transport. > When I use repository manager which require authorization for all request > also for all GET, we have first request as anonymous and second as authorized > user. > With it we can avoid not needed anonymous request. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-7716) ConcurrencyDependencyGraph deadlock if no root can be selected
[ https://issues.apache.org/jira/browse/MNG-7716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MNG-7716: --- Assignee: Michael Osipov > ConcurrencyDependencyGraph deadlock if no root can be selected > -- > > Key: MNG-7716 > URL: https://issues.apache.org/jira/browse/MNG-7716 > Project: Maven > Issue Type: Bug >Reporter: Christoph Läubrich >Assignee: Michael Osipov >Priority: Major > > At Tycho we got a bug-report that results in a deadlock when calling the > tycho-version-plugin: > https://github.com/eclipse-tycho/tycho/issues/2169 > I debugged the problem and it seems that ConcurrencyDependencyGraph is > actually the culprit here because it can return an empty list of projects to > initially build. As no builds are scheduled then the code in the > MultiThreadedBuilder waits forever for the result, this is what happening > here: > * There is one segment {code}org.faktorips:base:pom:23.6.0-SNAPSHOT -> > [org.eclipse.tycho:tycho-versions-plugin:3.0.4-SNAPSHOT:set-version]{code} > * This segment has a transitive reactor dependency to {code}MavenProject: > org.faktorips:codequality-config:23.6.0-SNAPSHOT @ > faktorips.base/codequality-config/pom.xml{code} (this is not a problem > because we only execute a reactor=true mojo!) > * So now the loop finds that there is no "independent" project and returns an > empty list -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7716) ConcurrencyDependencyGraph deadlock if no root can be selected
[ https://issues.apache.org/jira/browse/MNG-7716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7716: Fix Version/s: 3.9.1 > ConcurrencyDependencyGraph deadlock if no root can be selected > -- > > Key: MNG-7716 > URL: https://issues.apache.org/jira/browse/MNG-7716 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.7, 3.9.0, 4.0.0-alpha-4 >Reporter: Christoph Läubrich >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-5, 3.8.8, 3.9.1 > > > At Tycho we got a bug-report that results in a deadlock when calling the > tycho-version-plugin: > https://github.com/eclipse-tycho/tycho/issues/2169 > I debugged the problem and it seems that ConcurrencyDependencyGraph is > actually the culprit here because it can return an empty list of projects to > initially build. As no builds are scheduled then the code in the > MultiThreadedBuilder waits forever for the result, this is what happening > here: > * There is one segment {code}org.faktorips:base:pom:23.6.0-SNAPSHOT -> > [org.eclipse.tycho:tycho-versions-plugin:3.0.4-SNAPSHOT:set-version]{code} > * This segment has a transitive reactor dependency to {code}MavenProject: > org.faktorips:codequality-config:23.6.0-SNAPSHOT @ > faktorips.base/codequality-config/pom.xml{code} (this is not a problem > because we only execute a reactor=true mojo!) > * So now the loop finds that there is no "independent" project and returns an > empty list -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7716) ConcurrencyDependencyGraph deadlock if no root can be selected
[ https://issues.apache.org/jira/browse/MNG-7716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7716: Fix Version/s: 4.0.0 4.0.0-alpha-5 3.8.8 > ConcurrencyDependencyGraph deadlock if no root can be selected > -- > > Key: MNG-7716 > URL: https://issues.apache.org/jira/browse/MNG-7716 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.7, 3.9.0, 4.0.0-alpha-4 >Reporter: Christoph Läubrich >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-5, 3.8.8 > > > At Tycho we got a bug-report that results in a deadlock when calling the > tycho-version-plugin: > https://github.com/eclipse-tycho/tycho/issues/2169 > I debugged the problem and it seems that ConcurrencyDependencyGraph is > actually the culprit here because it can return an empty list of projects to > initially build. As no builds are scheduled then the code in the > MultiThreadedBuilder waits forever for the result, this is what happening > here: > * There is one segment {code}org.faktorips:base:pom:23.6.0-SNAPSHOT -> > [org.eclipse.tycho:tycho-versions-plugin:3.0.4-SNAPSHOT:set-version]{code} > * This segment has a transitive reactor dependency to {code}MavenProject: > org.faktorips:codequality-config:23.6.0-SNAPSHOT @ > faktorips.base/codequality-config/pom.xml{code} (this is not a problem > because we only execute a reactor=true mojo!) > * So now the loop finds that there is no "independent" project and returns an > empty list -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7716) ConcurrencyDependencyGraph deadlock if no root can be selected
[ https://issues.apache.org/jira/browse/MNG-7716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7716: Affects Version/s: 3.8.7 > ConcurrencyDependencyGraph deadlock if no root can be selected > -- > > Key: MNG-7716 > URL: https://issues.apache.org/jira/browse/MNG-7716 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.7 >Reporter: Christoph Läubrich >Assignee: Michael Osipov >Priority: Major > > At Tycho we got a bug-report that results in a deadlock when calling the > tycho-version-plugin: > https://github.com/eclipse-tycho/tycho/issues/2169 > I debugged the problem and it seems that ConcurrencyDependencyGraph is > actually the culprit here because it can return an empty list of projects to > initially build. As no builds are scheduled then the code in the > MultiThreadedBuilder waits forever for the result, this is what happening > here: > * There is one segment {code}org.faktorips:base:pom:23.6.0-SNAPSHOT -> > [org.eclipse.tycho:tycho-versions-plugin:3.0.4-SNAPSHOT:set-version]{code} > * This segment has a transitive reactor dependency to {code}MavenProject: > org.faktorips:codequality-config:23.6.0-SNAPSHOT @ > faktorips.base/codequality-config/pom.xml{code} (this is not a problem > because we only execute a reactor=true mojo!) > * So now the loop finds that there is no "independent" project and returns an > empty list -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7716) ConcurrencyDependencyGraph deadlock if no root can be selected
[ https://issues.apache.org/jira/browse/MNG-7716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7716: Affects Version/s: 4.0.0-alpha-4 3.9.0 > ConcurrencyDependencyGraph deadlock if no root can be selected > -- > > Key: MNG-7716 > URL: https://issues.apache.org/jira/browse/MNG-7716 > Project: Maven > Issue Type: Bug >Affects Versions: 3.8.7, 3.9.0, 4.0.0-alpha-4 >Reporter: Christoph Läubrich >Assignee: Michael Osipov >Priority: Major > > At Tycho we got a bug-report that results in a deadlock when calling the > tycho-version-plugin: > https://github.com/eclipse-tycho/tycho/issues/2169 > I debugged the problem and it seems that ConcurrencyDependencyGraph is > actually the culprit here because it can return an empty list of projects to > initially build. As no builds are scheduled then the code in the > MultiThreadedBuilder waits forever for the result, this is what happening > here: > * There is one segment {code}org.faktorips:base:pom:23.6.0-SNAPSHOT -> > [org.eclipse.tycho:tycho-versions-plugin:3.0.4-SNAPSHOT:set-version]{code} > * This segment has a transitive reactor dependency to {code}MavenProject: > org.faktorips:codequality-config:23.6.0-SNAPSHOT @ > faktorips.base/codequality-config/pom.xml{code} (this is not a problem > because we only execute a reactor=true mojo!) > * So now the loop finds that there is no "independent" project and returns an > empty list -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNGSITE-512) POM Reference: Repositories section confusing
[ https://issues.apache.org/jira/browse/MNGSITE-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17696073#comment-17696073 ] Michael Osipov commented on MNGSITE-512: What source code repositories? I am confused. > POM Reference: Repositories section confusing > - > > Key: MNGSITE-512 > URL: https://issues.apache.org/jira/browse/MNGSITE-512 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Philippe Cloutier >Priority: Minor > > [The Repositories section of the POM Reference > page|https://maven.apache.org/pom.html#Repositories] is confusing. It covers > one type of repositories (repositories of Maven artifacts), but not a much > more common type of repositories (repositories of source code). > It would be less confusing to either: > * rename the section with a more specific title (such as "Artifact > repositories") > * or also cover source code repositories, if that is supported > > By the way, reviewing the section's current contents (e.g. discussing purpose > before implementation) could also help. -- This message was sent by Atlassian Jira (v8.20.10#820010)