[jira] [Commented] (MPOM-344) Update maven-remote-resources-plugin to 3.1.0

2023-03-03 Thread Herve Boutemy (Jira)


[ 
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

2023-03-03 Thread Herve Boutemy (Jira)


 [ 
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

2023-03-03 Thread Herve Boutemy (Jira)


 [ 
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."

2023-03-03 Thread Herve Boutemy (Jira)


 [ 
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."

2023-03-03 Thread Herve Boutemy (Jira)


[ 
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

2023-03-03 Thread Adam Gent (Jira)


 [ 
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

2023-03-03 Thread Adam Gent (Jira)


 [ 
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

2023-03-03 Thread Adam Gent (Jira)


[ 
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

2023-03-03 Thread Tamas Cservenak (Jira)


[ 
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

2023-03-03 Thread Jeff Thomas (Jira)


[ 
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

2023-03-03 Thread Jeff Thomas (Jira)


[ 
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

2023-03-03 Thread Tamas Cservenak (Jira)


[ 
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

2023-03-03 Thread Michael Osipov (Jira)


[ 
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

2023-03-03 Thread Tamas Cservenak (Jira)


 [ 
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

2023-03-03 Thread Jim Sellers (Jira)


[ 
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

2023-03-03 Thread Tamas Cservenak (Jira)


[ 
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

2023-03-03 Thread Tamas Cservenak (Jira)


[ 
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

2023-03-03 Thread Adam Gent (Jira)
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

2023-03-03 Thread via GitHub


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

2023-03-03 Thread Michael Osipov (Jira)


 [ 
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

2023-03-03 Thread Marat Abrarov (Jira)


[ 
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

2023-03-03 Thread ASF GitHub Bot (Jira)


[ 
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

2023-03-03 Thread via GitHub


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

2023-03-03 Thread via GitHub


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

2023-03-03 Thread ASF GitHub Bot (Jira)


[ 
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

2023-03-03 Thread via GitHub


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

2023-03-03 Thread Slawomir Jaranowski (Jira)


 [ 
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

2023-03-03 Thread ASF GitHub Bot (Jira)


[ 
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

2023-03-03 Thread via GitHub


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

2023-03-03 Thread Christopher Tubbs (Jira)


[ 
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

2023-03-03 Thread via GitHub


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

2023-03-03 Thread Michael Osipov (Jira)


 [ 
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

2023-03-03 Thread Marat Abrarov (Jira)


[ 
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

2023-03-03 Thread Michael Osipov (Jira)


 [ 
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

2023-03-03 Thread Marat Abrarov (Jira)


[ 
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

2023-03-03 Thread Michael Osipov (Jira)


 [ 
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

2023-03-03 Thread via GitHub


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

2023-03-03 Thread via GitHub


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

2023-03-03 Thread via GitHub


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

2023-03-03 Thread via GitHub


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

2023-03-03 Thread via GitHub


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

2023-03-03 Thread via GitHub


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

2023-03-03 Thread via GitHub


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

2023-03-03 Thread via GitHub


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

2023-03-03 Thread Niels Basjes (Jira)


[ 
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

2023-03-03 Thread via GitHub


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

2023-03-03 Thread via GitHub


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

2023-03-03 Thread Christopher Tubbs (Jira)


[ 
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

2023-03-03 Thread Christopher Tubbs (Jira)


[ 
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

2023-03-03 Thread Christopher Tubbs (Jira)


[ 
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

2023-03-03 Thread Christopher Tubbs (Jira)


[ 
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

2023-03-03 Thread Christopher Tubbs (Jira)


[ 
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

2023-03-03 Thread Michael Osipov (Jira)


 [ 
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

2023-03-03 Thread Andreas Dangel (Jira)


 [ 
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

2023-03-03 Thread Andreas Dangel (Jira)


[ 
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

2023-03-03 Thread via GitHub


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

2023-03-03 Thread Andreas Dangel (Jira)


 [ 
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

2023-03-03 Thread via GitHub


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

2023-03-03 Thread via GitHub


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

2023-03-03 Thread Andreas Dangel (Jira)


 [ 
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

2023-03-03 Thread Niels Basjes (Jira)


[ 
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

2023-03-03 Thread Tamas Cservenak (Jira)


[ 
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

2023-03-03 Thread Niels Basjes (Jira)


[ 
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

2023-03-03 Thread Durgesh Mishra (Jira)
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

2023-03-03 Thread Andreas Dangel (Jira)
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

2023-03-03 Thread Andreas Dangel (Jira)


 [ 
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

2023-03-03 Thread via GitHub


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

2023-03-03 Thread via GitHub


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

2023-03-03 Thread via GitHub


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

2023-03-03 Thread Tamas Cservenak (Jira)


 [ 
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

2023-03-03 Thread Michael Osipov (Jira)


 [ 
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

2023-03-03 Thread Michael Osipov (Jira)


 [ 
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

2023-03-03 Thread Michael Osipov (Jira)


 [ 
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

2023-03-03 Thread Michael Osipov (Jira)


 [ 
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

2023-03-03 Thread Michael Osipov (Jira)


 [ 
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

2023-03-03 Thread Michael Osipov (Jira)


[ 
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)