[jira] [Updated] (MASFRES-39) maven executes mvn help:system error when downloading

[zhoupb (Jira)]

 [ 
https://issues.apache.org/jira/browse/MASFRES-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

zhoupb updated MASFRES-39:
--
Environment: 
windows 10 1903

maven 3.6.1

jdk 1.8

  was:
windows 10 1903

maven 3.6.1


> maven executes mvn help:system error when downloading
> -
>
> Key: MASFRES-39
> URL: https://issues.apache.org/jira/browse/MASFRES-39
> Project: Apache Maven Resource Bundles
>  Issue Type: Bug
> Environment: windows 10 1903
> maven 3.6.1
> jdk 1.8
>Reporter: zhoupb
>Priority: Blocker
> Attachments: QQ图片20200816120642.png, QQ截图20200816121421.png
>
>
> maven executes `mvn help:system` error when downloading



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MASFRES-39) maven executes mvn help:system error when downloading

[zhoupb (Jira)]

zhoupb created MASFRES-39:
-

 Summary: maven executes mvn help:system error when downloading
 Key: MASFRES-39
 URL: https://issues.apache.org/jira/browse/MASFRES-39
 Project: Apache Maven Resource Bundles
  Issue Type: Bug
 Environment: windows 10 1903

maven 3.6.1
Reporter: zhoupb
 Attachments: QQ图片20200816120642.png, QQ截图20200816121421.png

maven executes `mvn help:system` error when downloading



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (MEAR-280) Reproducible Builds: make entries in output ear files reproducible (order + timestamp)

[Marat Abrarov (Jira)]

[ 
https://issues.apache.org/jira/browse/MEAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179014#comment-17179014
 ] 

Marat Abrarov edited comment on MEAR-280 at 8/17/20, 11:56 PM:
---

This issue looks being still actual because Maven EAR Plugin generates not 
reproducible EARs when skinnyWars option is used 
({{true}} in {{configuration}} of Maven EAR Plugin).

[MEAR-280|https://github.com/mabrarov/dockerfile-test/compare/develop...MEAR-280]
 branch of mabrarov/dockerfile-test repository can be used for reproducing this 
issue (requires Maven EAR Plugin and [Maven Artifact 
Plugin|https://github.com/apache/maven-artifact-plugin] to be built and 
installed into local maven repository).

With skinnyWars option:
{code:bash}
$ git clone https://github.com/mabrarov/dockerfile-test.git && \
cd dockerfile-test && \
git checkout 0220cef03f2029aa10222d9af776ee1f79a4ae9a && \
./mvnw clean install -e -DskipTests -Ddocker.skip=true && \
./mvnw clean verify -e -DskipTests artifact:buildinfo -Dreference.repo=central 
-Ddocker.skip=true
...
[WARNING] size mismatch ear-1.1.7-SNAPSHOT.ear: investigate with diffoscope 
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
[WARNING] Reproducible Build output summary: 1 files ok, 1 different
[WARNING] see diff target/reference/app-image-1.1.7-SNAPSHOT.buildinfo 
app-image/target/app-image-1.1.7-SNAPSHOT.buildinfo
[INFO] 
[INFO] Reactor Summary for dockerfile-test 1.1.7-SNAPSHOT:
[INFO]
[INFO] dockerfile-test  SUCCESS [  1.381 s]
[INFO] war  SUCCESS [  1.190 s]
[INFO] ear  SUCCESS [  0.484 s]
[INFO] base-image . SUCCESS [  1.275 s]
[INFO] hollow-image ... SUCCESS [  0.163 s]
[INFO] app-image .. SUCCESS [  0.242 s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time:  5.373 s
[INFO] Finished at: 2020-08-17T17:30:00+03:00
[INFO] 

$ docker run --rm -t -w $(pwd) -v $(pwd):$(pwd):ro 
registry.salsa.debian.org/reproducible-builds/diffoscope 
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
+++ ear/target/ear-1.1.7-SNAPSHOT.ear
├── zipinfo -v {}
│ @@ -283,15 +283,15 @@
│minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│minimum software version required to extract:   2.0
│compression method: deflated
│compression sub-type (deflation):   normal
│file security status:   not encrypted
│extended local header:  no
│file last modified on (DOS date/time):  2020 Aug 17 14:23:02
│ -  32-bit CRC value (hex): f3f3d0e7
│ +  32-bit CRC value (hex): 2af2d57d
│compressed size:2523 bytes
│uncompressed size:  3687 bytes
│length of filename: 51 characters
│length of extra field:  0 bytes
│length of file comment: 0 characters
│disk number on which file begins:   disk 1
│apparent file type: binary
├── org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war
│ ├── zipinfo -v {}
│ │ @@ -26,15 +26,15 @@
│ │version of encoding software:   2.0
│ │minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│ │minimum software version required to extract:   2.0
│ │compression method: deflated
│ │compression sub-type (deflation):   normal
│ │file security status:   not encrypted
│ │extended local header:  no
│ │ -  file last modified on (DOS date/time):  2020 Aug 17 17:36:34
│ │ +  file last modified on (DOS date/time):  2020 Aug 17 17:36:40
│ │32-bit CRC value (hex): 64f3c575
│ │compressed size:179 bytes
│ │uncompressed size:  241 bytes
│ │length of filename: 20 characters
│ │length of extra field:  0 bytes
│ │length of file comment: 0 characters
│ │disk number on which file begins:   disk 1
│ │ @@

[GitHub] [maven-ear-plugin] mabrarov opened a new pull request #10: [MEAR-280] Reproducible builds with sinnyWar option

[GitBox]

mabrarov opened a new pull request #10:
URL: https://github.com/apache/maven-ear-plugin/pull/10


   MEAR-280: timestamp of repackaged EAR modules following same rules / value 
as timestamp of packaged modules to support reproducible builds when skinnyWar 
option is turned on
   



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.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Comment Edited] (MEAR-280) Reproducible Builds: make entries in output ear files reproducible (order + timestamp)

[Marat Abrarov (Jira)]

[ 
https://issues.apache.org/jira/browse/MEAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179014#comment-17179014
 ] 

Marat Abrarov edited comment on MEAR-280 at 8/17/20, 11:45 PM:
---

This issue looks being still actual because Maven EAR Plugin generates not 
reproducible EARs when skinnyWars option is used 
({{true}} in {{configuration}} of Maven EAR Plugin).

[MEAR-280|https://github.com/mabrarov/dockerfile-test/compare/develop...MEAR-280]
 branch of mabrarov/dockerfile-test repository can be used for reproducing this 
issue (requires Maven EAR Plugin and [Maven Artifact 
Plugin|https://github.com/apache/maven-artifact-plugin] to be built and 
installed into local maven repository).

With skinnyWars option:
{code:bash}
$ git clone https://github.com/mabrarov/dockerfile-test.git && \
cd dockerfile-test && \
git checkout 0220cef03f2029aa10222d9af776ee1f79a4ae9a && \
./mvnw clean install -e -DskipTests -Ddocker.skip=true && \
./mvnw clean verify -e -DskipTests artifact:buildinfo -Dreference.repo=central 
-Ddocker.skip=true
...
[WARNING] size mismatch ear-1.1.7-SNAPSHOT.ear: investigate with diffoscope 
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
[WARNING] Reproducible Build output summary: 1 files ok, 1 different
[WARNING] see diff target/reference/app-image-1.1.7-SNAPSHOT.buildinfo 
app-image/target/app-image-1.1.7-SNAPSHOT.buildinfo
[INFO] 
[INFO] Reactor Summary for dockerfile-test 1.1.7-SNAPSHOT:
[INFO]
[INFO] dockerfile-test  SUCCESS [  1.381 s]
[INFO] war  SUCCESS [  1.190 s]
[INFO] ear  SUCCESS [  0.484 s]
[INFO] base-image . SUCCESS [  1.275 s]
[INFO] hollow-image ... SUCCESS [  0.163 s]
[INFO] app-image .. SUCCESS [  0.242 s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time:  5.373 s
[INFO] Finished at: 2020-08-17T17:30:00+03:00
[INFO] 

$ docker run --rm -t -w $(pwd) -v $(pwd):$(pwd):ro 
registry.salsa.debian.org/reproducible-builds/diffoscope 
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
+++ ear/target/ear-1.1.7-SNAPSHOT.ear
├── zipinfo -v {}
│ @@ -283,15 +283,15 @@
│minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│minimum software version required to extract:   2.0
│compression method: deflated
│compression sub-type (deflation):   normal
│file security status:   not encrypted
│extended local header:  no
│file last modified on (DOS date/time):  2020 Aug 17 14:23:02
│ -  32-bit CRC value (hex): f3f3d0e7
│ +  32-bit CRC value (hex): 2af2d57d
│compressed size:2523 bytes
│uncompressed size:  3687 bytes
│length of filename: 51 characters
│length of extra field:  0 bytes
│length of file comment: 0 characters
│disk number on which file begins:   disk 1
│apparent file type: binary
├── org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war
│ ├── zipinfo -v {}
│ │ @@ -26,15 +26,15 @@
│ │version of encoding software:   2.0
│ │minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│ │minimum software version required to extract:   2.0
│ │compression method: deflated
│ │compression sub-type (deflation):   normal
│ │file security status:   not encrypted
│ │extended local header:  no
│ │ -  file last modified on (DOS date/time):  2020 Aug 17 17:36:34
│ │ +  file last modified on (DOS date/time):  2020 Aug 17 17:36:40
│ │32-bit CRC value (hex): 64f3c575
│ │compressed size:179 bytes
│ │uncompressed size:  241 bytes
│ │length of filename: 20 characters
│ │length of extra field:  0 bytes
│ │length of file comment: 0 characters
│ │disk number on which file begins:   disk 1
│ │ @@

[jira] [Commented] (MRESOLVER-130) Move GlobalSyncContextFactory to a separate module

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179193#comment-17179193
 ] 

Hudson commented on MRESOLVER-130:
--

Build succeeded in Jenkins: Maven » Maven TLP » maven-resolver » master #12

See 
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-resolver/job/master/12/

> Move GlobalSyncContextFactory to a separate module
> --
>
> Key: MRESOLVER-130
> URL: https://issues.apache.org/jira/browse/MRESOLVER-130
> Project: Maven Resolver
>  Issue Type: Task
>  Components: resolver
>Affects Versions: 1.5.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.5.1
>
>
> In order to retain maximum performance for the sake of instability, the 
> globally synchronized context factory shall be moved to 
> {{maven-resolver-synccontext-global}} and has to be dropped to 
> {{${maven.home}/lib/ext}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (MRESOLVER-130) Move GlobalSyncContextFactory to a separate module

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/MRESOLVER-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed MRESOLVER-130.

Resolution: Fixed

Fixed with 
[9670c1474e7591521eb40ed511ebbeddad6b5cc3|https://gitbox.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=9670c1474e7591521eb40ed511ebbeddad6b5cc3].

> Move GlobalSyncContextFactory to a separate module
> --
>
> Key: MRESOLVER-130
> URL: https://issues.apache.org/jira/browse/MRESOLVER-130
> Project: Maven Resolver
>  Issue Type: Task
>  Components: resolver
>Affects Versions: 1.5.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.5.1
>
>
> In order to retain maximum performance for the sake of instability, the 
> globally synchronized context factory shall be moved to 
> {{maven-resolver-synccontext-global}} and has to be dropped to 
> {{${maven.home}/lib/ext}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-resolver] asfgit closed pull request #66: [MRESOLVER-130] Move GlobalSyncContextFactory to a separate module

[GitBox]

asfgit closed pull request #66:
URL: https://github.com/apache/maven-resolver/pull/66


   



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.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MNG-6673) Deprecate HTTP Download & Upload

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179181#comment-17179181
 ] 

Michael Osipov commented on MNG-6673:
-

As with most improvement requests. Most people request, but no one contributes. 
Nothing implied or officially communicated. No committer had the interest to 
work on this. In fact, we deliver with Maven Central via HTTPS only. The rest 
is up to the user. From your point of view, the C programming language should 
be forbidden. If someone wants to work on it, fine. I'd be happy to reopen, but 
don't expect us to do anything.

> Deprecate HTTP Download & Upload
> 
>
> Key: MNG-6673
> URL: https://issues.apache.org/jira/browse/MNG-6673
> Project: Maven
>  Issue Type: Improvement
>  Components: Deployment
>Reporter: Jonathan Leitschuh
>Priority: Major
>  Labels: SECURITY, security
> Attachments: mitm_build.jpeg
>
>
> Some of the most popular Java projects in the JVM ecosystem are vulnerable to 
> a MITM of their dependencies. This is something that build tools can help 
> prevent.
> Starting in the next release of Maven, Maven should begin warning users about 
> the use of HTTP to download/upload artifacts to/from artifact servers.
> I believe that Maven/Gradle/SBT should require users to opt-out of the 
> security offered by using HTTPS to download/upload artifacts.
> Here's a list of projects that were found to be vulnerable to this:
> [https://docs.google.com/spreadsheets/d/1zemxj8QdIp0saqvwJx6Po1KnyEmJXl2KC_0j0SLd_2E/edit?usp=sharing]
>  
> 
> The full description of this industry-wide vulnerability can be found here:
> [Want to take over the Java ecosystem? All you need is a 
> MITM!|https://medium.com/@jonathan.leitschuh/want-to-take-over-the-java-ecosystem-all-you-need-is-a-mitm-1fc329d898fb?source=friends_link&sk=3c99970c55a899ad9ef41f126efcde0e]
>  !mitm_build.jpeg! 
>   



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Reopened] (MNG-6673) Deprecate HTTP Download & Upload

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov reopened MNG-6673:
-

> Deprecate HTTP Download & Upload
> 
>
> Key: MNG-6673
> URL: https://issues.apache.org/jira/browse/MNG-6673
> Project: Maven
>  Issue Type: Improvement
>  Components: Deployment
>Reporter: Jonathan Leitschuh
>Priority: Major
>  Labels: SECURITY, security
> Attachments: mitm_build.jpeg
>
>
> Some of the most popular Java projects in the JVM ecosystem are vulnerable to 
> a MITM of their dependencies. This is something that build tools can help 
> prevent.
> Starting in the next release of Maven, Maven should begin warning users about 
> the use of HTTP to download/upload artifacts to/from artifact servers.
> I believe that Maven/Gradle/SBT should require users to opt-out of the 
> security offered by using HTTPS to download/upload artifacts.
> Here's a list of projects that were found to be vulnerable to this:
> [https://docs.google.com/spreadsheets/d/1zemxj8QdIp0saqvwJx6Po1KnyEmJXl2KC_0j0SLd_2E/edit?usp=sharing]
>  
> 
> The full description of this industry-wide vulnerability can be found here:
> [Want to take over the Java ecosystem? All you need is a 
> MITM!|https://medium.com/@jonathan.leitschuh/want-to-take-over-the-java-ecosystem-all-you-need-is-a-mitm-1fc329d898fb?source=friends_link&sk=3c99970c55a899ad9ef41f126efcde0e]
>  !mitm_build.jpeg! 
>   



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (MNG-6673) Deprecate HTTP Download & Upload

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov resolved MNG-6673.
-
Resolution: Won't Fix

> Deprecate HTTP Download & Upload
> 
>
> Key: MNG-6673
> URL: https://issues.apache.org/jira/browse/MNG-6673
> Project: Maven
>  Issue Type: Improvement
>  Components: Deployment
>Reporter: Jonathan Leitschuh
>Priority: Major
>  Labels: SECURITY, security
> Attachments: mitm_build.jpeg
>
>
> Some of the most popular Java projects in the JVM ecosystem are vulnerable to 
> a MITM of their dependencies. This is something that build tools can help 
> prevent.
> Starting in the next release of Maven, Maven should begin warning users about 
> the use of HTTP to download/upload artifacts to/from artifact servers.
> I believe that Maven/Gradle/SBT should require users to opt-out of the 
> security offered by using HTTPS to download/upload artifacts.
> Here's a list of projects that were found to be vulnerable to this:
> [https://docs.google.com/spreadsheets/d/1zemxj8QdIp0saqvwJx6Po1KnyEmJXl2KC_0j0SLd_2E/edit?usp=sharing]
>  
> 
> The full description of this industry-wide vulnerability can be found here:
> [Want to take over the Java ecosystem? All you need is a 
> MITM!|https://medium.com/@jonathan.leitschuh/want-to-take-over-the-java-ecosystem-all-you-need-is-a-mitm-1fc329d898fb?source=friends_link&sk=3c99970c55a899ad9ef41f126efcde0e]
>  !mitm_build.jpeg! 
>   



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-dependency-plugin] ian-lavallee commented on pull request #96: [MDEP-644] Add reactor logic

[GitBox]

ian-lavallee commented on pull request #96:
URL: 
https://github.com/apache/maven-dependency-plugin/pull/96#issuecomment-675056178


   Tested manually and seems to be working, still need to add integration test 
over from dependency-tree project, having a few issues with it



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.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-dependency-plugin] ian-lavallee opened a new pull request #96: [MDEP-644] Add reactor logic

[GitBox]

ian-lavallee opened a new pull request #96:
URL: https://github.com/apache/maven-dependency-plugin/pull/96


   
   
   



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.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MNG-6673) Deprecate HTTP Download & Upload

[Jonathan Leitschuh (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179176#comment-17179176
 ] 

Jonathan Leitschuh commented on MNG-6673:
-

I'm confused, is it now the official stance that security issue that impacted a 
huge swath of the JVM ecosystem is 'not a problem'? I just want to understand 
and make sure that I'm understanding what's implied by this status change.

> Deprecate HTTP Download & Upload
> 
>
> Key: MNG-6673
> URL: https://issues.apache.org/jira/browse/MNG-6673
> Project: Maven
>  Issue Type: Improvement
>  Components: Deployment
>Reporter: Jonathan Leitschuh
>Priority: Major
>  Labels: SECURITY, security
> Attachments: mitm_build.jpeg
>
>
> Some of the most popular Java projects in the JVM ecosystem are vulnerable to 
> a MITM of their dependencies. This is something that build tools can help 
> prevent.
> Starting in the next release of Maven, Maven should begin warning users about 
> the use of HTTP to download/upload artifacts to/from artifact servers.
> I believe that Maven/Gradle/SBT should require users to opt-out of the 
> security offered by using HTTPS to download/upload artifacts.
> Here's a list of projects that were found to be vulnerable to this:
> [https://docs.google.com/spreadsheets/d/1zemxj8QdIp0saqvwJx6Po1KnyEmJXl2KC_0j0SLd_2E/edit?usp=sharing]
>  
> 
> The full description of this industry-wide vulnerability can be found here:
> [Want to take over the Java ecosystem? All you need is a 
> MITM!|https://medium.com/@jonathan.leitschuh/want-to-take-over-the-java-ecosystem-all-you-need-is-a-mitm-1fc329d898fb?source=friends_link&sk=3c99970c55a899ad9ef41f126efcde0e]
>  !mitm_build.jpeg! 
>   



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MPH-169) effective-pom should show imported dependencies

[Konrad Windszus (Jira)]

Konrad Windszus created MPH-169:
---

 Summary: effective-pom should show imported dependencies
 Key: MPH-169
 URL: https://issues.apache.org/jira/browse/MPH-169
 Project: Maven Help Plugin
  Issue Type: Bug
  Components: effective-pom
Affects Versions: 3.2.0
Reporter: Konrad Windszus


All dependencies imported like outlined 
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies
 do not appear in the effective pom.xml currently. They should be resolved and 
listed individually in the effective {{dependencyManagement}} instead.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-wagon] michael-o closed pull request #49: [MNG-2802] Concurrent-safe access to local Maven repository

[GitBox]

michael-o closed pull request #49:
URL: https://github.com/apache/maven-wagon/pull/49


   



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.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-wagon] michael-o commented on pull request #49: [MNG-2802] Concurrent-safe access to local Maven repository

[GitBox]

michael-o commented on pull request #49:
URL: https://github.com/apache/maven-wagon/pull/49#issuecomment-674947469


   Superceded by MRESOLVER-131.



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Comment Edited] (MEAR-280) Reproducible Builds: make entries in output ear files reproducible (order + timestamp)

[Marat Abrarov (Jira)]

[ 
https://issues.apache.org/jira/browse/MEAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179014#comment-17179014
 ] 

Marat Abrarov edited comment on MEAR-280 at 8/17/20, 2:47 PM:
--

This issue looks being still actual because Maven EAR Plugin generates not 
reproducible EARs when skinnyWars option is used 
({{true}} in {{configuration}} of Maven EAR Plugin).

[MEAR-280|https://github.com/mabrarov/dockerfile-test/compare/develop...MEAR-280]
 branch of mabrarov/dockerfile-test repository can be used for reproducing this 
issue (requires Maven EAR Plugin to be built and installed into local maven 
repository).

With skinnyWars option:
{code:bash}
$ git clone https://github.com/mabrarov/dockerfile-test.git && \
cd dockerfile-test && \
git checkout 0220cef03f2029aa10222d9af776ee1f79a4ae9a && \
./mvnw clean install -e -DskipTests -Ddocker.skip=true && \
./mvnw clean verify -e -DskipTests artifact:buildinfo -Dreference.repo=central 
-Ddocker.skip=true
...
[WARNING] size mismatch ear-1.1.7-SNAPSHOT.ear: investigate with diffoscope 
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
[WARNING] Reproducible Build output summary: 1 files ok, 1 different
[WARNING] see diff target/reference/app-image-1.1.7-SNAPSHOT.buildinfo 
app-image/target/app-image-1.1.7-SNAPSHOT.buildinfo
[INFO] 
[INFO] Reactor Summary for dockerfile-test 1.1.7-SNAPSHOT:
[INFO]
[INFO] dockerfile-test  SUCCESS [  1.381 s]
[INFO] war  SUCCESS [  1.190 s]
[INFO] ear  SUCCESS [  0.484 s]
[INFO] base-image . SUCCESS [  1.275 s]
[INFO] hollow-image ... SUCCESS [  0.163 s]
[INFO] app-image .. SUCCESS [  0.242 s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time:  5.373 s
[INFO] Finished at: 2020-08-17T17:30:00+03:00
[INFO] 

$ docker run --rm -t -w $(pwd) -v $(pwd):$(pwd):ro 
registry.salsa.debian.org/reproducible-builds/diffoscope 
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
+++ ear/target/ear-1.1.7-SNAPSHOT.ear
├── zipinfo -v {}
│ @@ -283,15 +283,15 @@
│minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│minimum software version required to extract:   2.0
│compression method: deflated
│compression sub-type (deflation):   normal
│file security status:   not encrypted
│extended local header:  no
│file last modified on (DOS date/time):  2020 Aug 17 14:23:02
│ -  32-bit CRC value (hex): f3f3d0e7
│ +  32-bit CRC value (hex): 2af2d57d
│compressed size:2523 bytes
│uncompressed size:  3687 bytes
│length of filename: 51 characters
│length of extra field:  0 bytes
│length of file comment: 0 characters
│disk number on which file begins:   disk 1
│apparent file type: binary
├── org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war
│ ├── zipinfo -v {}
│ │ @@ -26,15 +26,15 @@
│ │version of encoding software:   2.0
│ │minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│ │minimum software version required to extract:   2.0
│ │compression method: deflated
│ │compression sub-type (deflation):   normal
│ │file security status:   not encrypted
│ │extended local header:  no
│ │ -  file last modified on (DOS date/time):  2020 Aug 17 17:36:34
│ │ +  file last modified on (DOS date/time):  2020 Aug 17 17:36:40
│ │32-bit CRC value (hex): 64f3c575
│ │compressed size:179 bytes
│ │uncompressed size:  241 bytes
│ │length of filename: 20 characters
│ │length of extra field:  0 bytes
│ │length of file comment: 0 characters
│ │disk number on which file begins:   disk 1
│ │ @@ -54,15 +54,15 @@
│ │file system or operating system of origin:  Unix
│

[jira] [Comment Edited] (MEAR-280) Reproducible Builds: make entries in output ear files reproducible (order + timestamp)

[Marat Abrarov (Jira)]

[ 
https://issues.apache.org/jira/browse/MEAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179014#comment-17179014
 ] 

Marat Abrarov edited comment on MEAR-280 at 8/17/20, 2:46 PM:
--

This issue looks being still actual because Maven EAR Plugin generates not 
reproducible EARs when skinnyWars option is used 
({{true}} in {{configuration}} of Maven EAR Plugin).

[MEAR-280|https://github.com/mabrarov/dockerfile-test/compare/develop...MEAR-280]
 branch of mabrarov/dockerfile-test repository can be used for reproducing this 
issue (requires Maven EAR Plugin to be built and installed into local maven 
repository).

With skinnyWars option:
{code:bash}
$ git clone https://github.com/mabrarov/dockerfile-test.git && \
cd dockerfile-test && \
git checkout 0220cef03f2029aa10222d9af776ee1f79a4ae9a && \
./mvnw clean install -e -DskipTests -Ddocker.skip=true && \
./mvnw clean verify -e -DskipTests artifact:buildinfo -Dreference.repo=central 
-Ddocker.skip=true
...
[WARNING] size mismatch ear-1.1.7-SNAPSHOT.ear: investigate with diffoscope 
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
[WARNING] Reproducible Build output summary: 1 files ok, 1 different
[WARNING] see diff target/reference/app-image-1.1.7-SNAPSHOT.buildinfo 
app-image/target/app-image-1.1.7-SNAPSHOT.buildinfo
[INFO] 
[INFO] Reactor Summary for dockerfile-test 1.1.7-SNAPSHOT:
[INFO]
[INFO] dockerfile-test  SUCCESS [  1.381 s]
[INFO] war  SUCCESS [  1.190 s]
[INFO] ear  SUCCESS [  0.484 s]
[INFO] base-image . SUCCESS [  1.275 s]
[INFO] hollow-image ... SUCCESS [  0.163 s]
[INFO] app-image .. SUCCESS [  0.242 s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time:  5.373 s
[INFO] Finished at: 2020-08-17T17:30:00+03:00
[INFO] 

$ docker run --rm -t -w $(pwd) -v $(pwd):$(pwd):ro 
registry.salsa.debian.org/reproducible-builds/diffoscope 
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
+++ ear/target/ear-1.1.7-SNAPSHOT.ear
├── zipinfo -v {}
│ @@ -283,15 +283,15 @@
│minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│minimum software version required to extract:   2.0
│compression method: deflated
│compression sub-type (deflation):   normal
│file security status:   not encrypted
│extended local header:  no
│file last modified on (DOS date/time):  2020 Aug 17 14:23:02
│ -  32-bit CRC value (hex): f3f3d0e7
│ +  32-bit CRC value (hex): 2af2d57d
│compressed size:2523 bytes
│uncompressed size:  3687 bytes
│length of filename: 51 characters
│length of extra field:  0 bytes
│length of file comment: 0 characters
│disk number on which file begins:   disk 1
│apparent file type: binary
├── org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war
│ ├── zipinfo -v {}
│ │ @@ -26,15 +26,15 @@
│ │version of encoding software:   2.0
│ │minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│ │minimum software version required to extract:   2.0
│ │compression method: deflated
│ │compression sub-type (deflation):   normal
│ │file security status:   not encrypted
│ │extended local header:  no
│ │ -  file last modified on (DOS date/time):  2020 Aug 17 17:36:34
│ │ +  file last modified on (DOS date/time):  2020 Aug 17 17:36:40
│ │32-bit CRC value (hex): 64f3c575
│ │compressed size:179 bytes
│ │uncompressed size:  241 bytes
│ │length of filename: 20 characters
│ │length of extra field:  0 bytes
│ │length of file comment: 0 characters
│ │disk number on which file begins:   disk 1
│ │ @@ -54,15 +54,15 @@
│ │file system or operating system of origin:  Unix
│

[jira] [Comment Edited] (MEAR-280) Reproducible Builds: make entries in output ear files reproducible (order + timestamp)

[Marat Abrarov (Jira)]

[ 
https://issues.apache.org/jira/browse/MEAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179014#comment-17179014
 ] 

Marat Abrarov edited comment on MEAR-280 at 8/17/20, 2:46 PM:
--

This issue looks being still actual because Maven EAR Plugin generates not 
reproducible EARs when skinnyWars option is used 
({{true}} in {{configuration}} of Maven EAR Plugin).

[MEAR-280|https://github.com/mabrarov/dockerfile-test/compare/develop...MEAR-280]
 branch of mabrarov/dockerfile-test repository can be used for reproducing this 
issue (requires Maven EAR Plugin to be built and installed into local maven 
repository).

With skinnyWars option:
{code:bash}
$ git clone https://github.com/mabrarov/dockerfile-test.git && \
cd dockerfile-test && \
git checkout 0220cef03f2029aa10222d9af776ee1f79a4ae9a && \
./mvnw clean install -e -DskipTests -Ddocker.skip=true && \
./mvnw clean verify -e -DskipTests artifact:buildinfo -Dreference.repo=central 
-Ddocker.skip=true
...
[WARNING] size mismatch ear-1.1.7-SNAPSHOT.ear: investigate with diffoscope 
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
[WARNING] Reproducible Build output summary: 1 files ok, 1 different
[WARNING] see diff target/reference/app-image-1.1.7-SNAPSHOT.buildinfo 
app-image/target/app-image-1.1.7-SNAPSHOT.buildinfo
[INFO] 
[INFO] Reactor Summary for dockerfile-test 1.1.7-SNAPSHOT:
[INFO]
[INFO] dockerfile-test  SUCCESS [  1.381 s]
[INFO] war  SUCCESS [  1.190 s]
[INFO] ear  SUCCESS [  0.484 s]
[INFO] base-image . SUCCESS [  1.275 s]
[INFO] hollow-image ... SUCCESS [  0.163 s]
[INFO] app-image .. SUCCESS [  0.242 s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time:  5.373 s
[INFO] Finished at: 2020-08-17T17:30:00+03:00
[INFO] 

$ docker run --rm -t -w $(pwd) -v $(pwd):$(pwd):ro 
registry.salsa.debian.org/reproducible-builds/diffoscope 
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
+++ ear/target/ear-1.1.7-SNAPSHOT.ear
├── zipinfo -v {}
│ @@ -283,15 +283,15 @@
│minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│minimum software version required to extract:   2.0
│compression method: deflated
│compression sub-type (deflation):   normal
│file security status:   not encrypted
│extended local header:  no
│file last modified on (DOS date/time):  2020 Aug 17 14:23:02
│ -  32-bit CRC value (hex): f3f3d0e7
│ +  32-bit CRC value (hex): 2af2d57d
│compressed size:2523 bytes
│uncompressed size:  3687 bytes
│length of filename: 51 characters
│length of extra field:  0 bytes
│length of file comment: 0 characters
│disk number on which file begins:   disk 1
│apparent file type: binary
├── org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war
│ ├── zipinfo -v {}
│ │ @@ -26,15 +26,15 @@
│ │version of encoding software:   2.0
│ │minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│ │minimum software version required to extract:   2.0
│ │compression method: deflated
│ │compression sub-type (deflation):   normal
│ │file security status:   not encrypted
│ │extended local header:  no
│ │ -  file last modified on (DOS date/time):  2020 Aug 17 17:36:34
│ │ +  file last modified on (DOS date/time):  2020 Aug 17 17:36:40
│ │32-bit CRC value (hex): 64f3c575
│ │compressed size:179 bytes
│ │uncompressed size:  241 bytes
│ │length of filename: 20 characters
│ │length of extra field:  0 bytes
│ │length of file comment: 0 characters
│ │disk number on which file begins:   disk 1
│ │ @@ -54,15 +54,15 @@
│ │file system or operating system of origin:  Unix
│

[jira] [Commented] (MDEP-644) Reintroduce the verbose option for dependency:tree

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MDEP-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179037#comment-17179037
 ] 

Hudson commented on MDEP-644:
-

Build succeeded in Jenkins: Maven » Maven TLP » maven-dependency-plugin » 
master #18

See 
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-dependency-plugin/job/master/18/

> Reintroduce the verbose option for dependency:tree
> --
>
> Key: MDEP-644
> URL: https://issues.apache.org/jira/browse/MDEP-644
> Project: Maven Dependency Plugin
>  Issue Type: New Feature
>  Components: tree
>Reporter: John Lin
>Assignee: Elliotte Rusty Harold
>Priority: Major
>  Labels: intern
>
> The verbose option for dependency:tree is removed in maven-dependency-plugin 
> 3.0. This issue is to reintroduce the option.
> In verbose mode the dependency tree shows dependencies that were omitted for: 
> being a duplicate of another; conflicting with another's version and/or 
> scope; and introducing a cycle into the dependency tree.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (MEAR-280) Reproducible Builds: make entries in output ear files reproducible (order + timestamp)

[Marat Abrarov (Jira)]

[ 
https://issues.apache.org/jira/browse/MEAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179014#comment-17179014
 ] 

Marat Abrarov edited comment on MEAR-280 at 8/17/20, 2:43 PM:
--

This issue looks being still actual because Maven EAR Plugin generates not 
reproducible EARs when skinnyWars option is used 
({{true}} in {{configuration}} of Maven EAR Plugin).

[MEAR-280|https://github.com/mabrarov/dockerfile-test/tree/MEAR-280] branch of 
mabrarov/dockerfile-test repository can be used for reproducing this issue 
(requires Maven EAR Plugin to be built and installed into local maven 
repository).

With skinnyWars option:
{code:bash}
$ git clone https://github.com/mabrarov/dockerfile-test.git && \
cd dockerfile-test && \
git checkout 0220cef03f2029aa10222d9af776ee1f79a4ae9a && \
./mvnw clean install -e -DskipTests -Ddocker.skip=true && \
./mvnw clean verify -e -DskipTests artifact:buildinfo -Dreference.repo=central 
-Ddocker.skip=true
...
[WARNING] size mismatch ear-1.1.7-SNAPSHOT.ear: investigate with diffoscope 
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
[WARNING] Reproducible Build output summary: 1 files ok, 1 different
[WARNING] see diff target/reference/app-image-1.1.7-SNAPSHOT.buildinfo 
app-image/target/app-image-1.1.7-SNAPSHOT.buildinfo
[INFO] 
[INFO] Reactor Summary for dockerfile-test 1.1.7-SNAPSHOT:
[INFO]
[INFO] dockerfile-test  SUCCESS [  1.381 s]
[INFO] war  SUCCESS [  1.190 s]
[INFO] ear  SUCCESS [  0.484 s]
[INFO] base-image . SUCCESS [  1.275 s]
[INFO] hollow-image ... SUCCESS [  0.163 s]
[INFO] app-image .. SUCCESS [  0.242 s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time:  5.373 s
[INFO] Finished at: 2020-08-17T17:30:00+03:00
[INFO] 

$ docker run --rm -t -w $(pwd) -v $(pwd):$(pwd):ro 
registry.salsa.debian.org/reproducible-builds/diffoscope 
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
+++ ear/target/ear-1.1.7-SNAPSHOT.ear
├── zipinfo -v {}
│ @@ -283,15 +283,15 @@
│minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│minimum software version required to extract:   2.0
│compression method: deflated
│compression sub-type (deflation):   normal
│file security status:   not encrypted
│extended local header:  no
│file last modified on (DOS date/time):  2020 Aug 17 14:23:02
│ -  32-bit CRC value (hex): f3f3d0e7
│ +  32-bit CRC value (hex): 2af2d57d
│compressed size:2523 bytes
│uncompressed size:  3687 bytes
│length of filename: 51 characters
│length of extra field:  0 bytes
│length of file comment: 0 characters
│disk number on which file begins:   disk 1
│apparent file type: binary
├── org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war
│ ├── zipinfo -v {}
│ │ @@ -26,15 +26,15 @@
│ │version of encoding software:   2.0
│ │minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│ │minimum software version required to extract:   2.0
│ │compression method: deflated
│ │compression sub-type (deflation):   normal
│ │file security status:   not encrypted
│ │extended local header:  no
│ │ -  file last modified on (DOS date/time):  2020 Aug 17 17:36:34
│ │ +  file last modified on (DOS date/time):  2020 Aug 17 17:36:40
│ │32-bit CRC value (hex): 64f3c575
│ │compressed size:179 bytes
│ │uncompressed size:  241 bytes
│ │length of filename: 20 characters
│ │length of extra field:  0 bytes
│ │length of file comment: 0 characters
│ │disk number on which file begins:   disk 1
│ │ @@ -54,15 +54,15 @@
│ │file system or operating system of origin:  Unix
│ │version

[jira] [Comment Edited] (MEAR-280) Reproducible Builds: make entries in output ear files reproducible (order + timestamp)

[Marat Abrarov (Jira)]

[ 
https://issues.apache.org/jira/browse/MEAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179014#comment-17179014
 ] 

Marat Abrarov edited comment on MEAR-280 at 8/17/20, 2:40 PM:
--

This issue looks being still actual because Maven EAR Plugin generates not 
reproducible EARs when skinnyWars option is used 
({{true}} in {{configuration}} of Maven EAR Plugin).

[MEAR-280|https://github.com/mabrarov/dockerfile-test/tree/MEAR-280] branch of 
mabrarov/dockerfile-test repository can be used for reproducing this issue 
(requires Maven EAR Plugin to be built and installed into local maven 
repository).
With skinnyWars option:
{code:bash}
$ git clone https://github.com/mabrarov/dockerfile-test.git && \
cd dockerfile-test && \
git checkout 0220cef03f2029aa10222d9af776ee1f79a4ae9a && \
./mvnw clean install -e -DskipTests -Ddocker.skip=true && \
./mvnw clean verify -e -DskipTests artifact:buildinfo -Dreference.repo=central 
-Ddocker.skip=true
...
[WARNING] size mismatch ear-1.1.7-SNAPSHOT.ear: investigate with diffoscope 
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
[WARNING] Reproducible Build output summary: 1 files ok, 1 different
[WARNING] see diff target/reference/app-image-1.1.7-SNAPSHOT.buildinfo 
app-image/target/app-image-1.1.7-SNAPSHOT.buildinfo
[INFO] 
[INFO] Reactor Summary for dockerfile-test 1.1.7-SNAPSHOT:
[INFO]
[INFO] dockerfile-test  SUCCESS [  1.381 s]
[INFO] war  SUCCESS [  1.190 s]
[INFO] ear  SUCCESS [  0.484 s]
[INFO] base-image . SUCCESS [  1.275 s]
[INFO] hollow-image ... SUCCESS [  0.163 s]
[INFO] app-image .. SUCCESS [  0.242 s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time:  5.373 s
[INFO] Finished at: 2020-08-17T17:30:00+03:00
[INFO] 

$ docker run --rm -t -w $(pwd) -v $(pwd):$(pwd):ro 
registry.salsa.debian.org/reproducible-builds/diffoscope 
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
--- target/reference/ear-1.1.7-SNAPSHOT.ear
+++ ear/target/ear-1.1.7-SNAPSHOT.ear
├── zipinfo -v {}
│ @@ -283,15 +283,15 @@
│minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│minimum software version required to extract:   2.0
│compression method: deflated
│compression sub-type (deflation):   normal
│file security status:   not encrypted
│extended local header:  no
│file last modified on (DOS date/time):  2020 Aug 17 14:23:02
│ -  32-bit CRC value (hex): f3f3d0e7
│ +  32-bit CRC value (hex): 2af2d57d
│compressed size:2523 bytes
│uncompressed size:  3687 bytes
│length of filename: 51 characters
│length of extra field:  0 bytes
│length of file comment: 0 characters
│disk number on which file begins:   disk 1
│apparent file type: binary
├── org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war
│ ├── zipinfo -v {}
│ │ @@ -26,15 +26,15 @@
│ │version of encoding software:   2.0
│ │minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
│ │minimum software version required to extract:   2.0
│ │compression method: deflated
│ │compression sub-type (deflation):   normal
│ │file security status:   not encrypted
│ │extended local header:  no
│ │ -  file last modified on (DOS date/time):  2020 Aug 17 17:36:34
│ │ +  file last modified on (DOS date/time):  2020 Aug 17 17:36:40
│ │32-bit CRC value (hex): 64f3c575
│ │compressed size:179 bytes
│ │uncompressed size:  241 bytes
│ │length of filename: 20 characters
│ │length of extra field:  0 bytes
│ │length of file comment: 0 characters
│ │disk number on which file begins:   disk 1
│ │ @@ -54,15 +54,15 @@
│ │file system or operating system of origin:  Unix
│ │version 

[jira] [Comment Edited] (MEAR-280) Reproducible Builds: make entries in output ear files reproducible (order + timestamp)

[Marat Abrarov (Jira)]

[ 
https://issues.apache.org/jira/browse/MEAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179014#comment-17179014
 ] 

Marat Abrarov edited comment on MEAR-280 at 8/17/20, 2:35 PM:
--

This issue looks being still actual because Maven EAR Plugin generates not 
reproducible EARs when skinnyWars option is used 
({{true}} in {{configuration}} of Maven EAR Plugin).

[MEAR-280|https://github.com/mabrarov/dockerfile-test/tree/MEAR-280] branch of 
mabrarov/dockerfile-test repository can be used for reproducing this issue 
(requires Maven EAR Plugin to be built and installed into local maven 
repository).
With skinnyWars option:
{code:bash}
git clone https://github.com/mabrarov/dockerfile-test.git && \
cd dockerfile-test && \
git checkout 0220cef03f2029aa10222d9af776ee1f79a4ae9a && \
./mvnw clean install -e -DskipTests -Ddocker.skip=true && \
./mvnw clean verify -e -DskipTests artifact:buildinfo -Dreference.repo=central 
-Ddocker.skip=true
...
[WARNING] size mismatch ear-1.1.7-SNAPSHOT.ear: investigate with diffoscope 
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
[WARNING] Reproducible Build output summary: 1 files ok, 1 different
[WARNING] see diff target/reference/app-image-1.1.7-SNAPSHOT.buildinfo 
app-image/target/app-image-1.1.7-SNAPSHOT.buildinfo
[INFO] 
[INFO] Reactor Summary for dockerfile-test 1.1.7-SNAPSHOT:
[INFO]
[INFO] dockerfile-test  SUCCESS [  1.381 s]
[INFO] war  SUCCESS [  1.190 s]
[INFO] ear  SUCCESS [  0.484 s]
[INFO] base-image . SUCCESS [  1.275 s]
[INFO] hollow-image ... SUCCESS [  0.163 s]
[INFO] app-image .. SUCCESS [  0.242 s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time:  5.373 s
[INFO] Finished at: 2020-08-17T17:30:00+03:00
[INFO] 
{code}
Without `skinnyWars` option:
{code:bash}
git checkout MEAR-280 && \
./mvnw clean install -e -DskipTests -Ddocker.skip=true && \
./mvnw clean verify -e -DskipTests artifact:buildinfo -Dreference.repo=central 
-Ddocker.skip=true
...
[INFO] Reference build java.version: 1.8 (from MANIFEST.MF Build-Jdk-Spec)
[INFO] Reference build os.name: Unix (from pom.properties newline)
[INFO] Minimal buildinfo generated from downloaded artifacts: 
/home/user/dockerfile-test/target/reference/app-image-1.1.7-SNAPSHOT.buildinfo
[INFO] Reproducible Build output summary: 2 files ok
[INFO] 
[INFO] Reactor Summary for dockerfile-test 1.1.7-SNAPSHOT:
[INFO]
[INFO] dockerfile-test  SUCCESS [  1.382 s]
[INFO] war  SUCCESS [  1.320 s]
[INFO] ear  SUCCESS [  0.422 s]
[INFO] base-image . SUCCESS [  0.993 s]
[INFO] hollow-image ... SUCCESS [  0.120 s]
[INFO] app-image .. SUCCESS [  0.227 s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time:  5.272 s
[INFO] Finished at: 2020-08-17T17:31:15+03:00
[INFO] 
{code}


was (Author: abrarovm):
This issue looks being still actual because Maven EAR Plugin generates not 
reproducible EARs when skinnyWars option is used 
({{true}} in {{configuration}} of Maven EAR Plugin).

[MEAR-280|https://github.com/mabrarov/dockerfile-test/tree/MEAR-280] branch of 
mabrarov/dockerfile-test repository can be used for reproducing this issue 
(requires Maven EAR Plugin to be built and installed into local maven 
repository).
With skinnyWars option:
{code:bash}
git checkout 0220cef03f2029aa10222d9af776ee1f79a4ae9a && \
./mvnw clean install -e -DskipTests -Ddocker.skip=true && \
./mvnw clean verify -e -DskipTests artifact:buildinfo -Dreference.repo=central 
-Ddocker.skip=true
...
[WARNING] size mismatch ear-1.1.7-SNAPSHOT.ear: investigate with diffoscope 
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
[WARNING] Reproducible Build output summary: 1 files ok, 1 different
[WARNING] see diff target/reference/app-image-1.1.7-SNAPSHOT.buildinfo 
app-image/target/app-image-1.1.7-SNAPSHOT.buildinfo
[INFO] ---

[jira] [Comment Edited] (MEAR-280) Reproducible Builds: make entries in output ear files reproducible (order + timestamp)

[Marat Abrarov (Jira)]

[ 
https://issues.apache.org/jira/browse/MEAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179014#comment-17179014
 ] 

Marat Abrarov edited comment on MEAR-280 at 8/17/20, 2:31 PM:
--

This issue looks being still actual because Maven EAR Plugin generates not 
reproducible EARs when skinnyWars option is used 
({{true}} in {{configuration}} of Maven EAR Plugin).

[MEAR-280|https://github.com/mabrarov/dockerfile-test/tree/MEAR-280] branch of 
mabrarov/dockerfile-test repository can be used for reproducing this issue 
(requires Maven EAR Plugin to be built and installed into local maven 
repository).
With skinnyWars option:
{code:bash}
git checkout 0220cef03f2029aa10222d9af776ee1f79a4ae9a && \
./mvnw clean install -e -DskipTests -Ddocker.skip=true && \
./mvnw clean verify -e -DskipTests artifact:buildinfo -Dreference.repo=central 
-Ddocker.skip=true
...
[WARNING] size mismatch ear-1.1.7-SNAPSHOT.ear: investigate with diffoscope 
target/reference/ear-1.1.7-SNAPSHOT.ear ear/target/ear-1.1.7-SNAPSHOT.ear
[WARNING] Reproducible Build output summary: 1 files ok, 1 different
[WARNING] see diff target/reference/app-image-1.1.7-SNAPSHOT.buildinfo 
app-image/target/app-image-1.1.7-SNAPSHOT.buildinfo
[INFO] 
[INFO] Reactor Summary for dockerfile-test 1.1.7-SNAPSHOT:
[INFO]
[INFO] dockerfile-test  SUCCESS [  1.381 s]
[INFO] war  SUCCESS [  1.190 s]
[INFO] ear  SUCCESS [  0.484 s]
[INFO] base-image . SUCCESS [  1.275 s]
[INFO] hollow-image ... SUCCESS [  0.163 s]
[INFO] app-image .. SUCCESS [  0.242 s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time:  5.373 s
[INFO] Finished at: 2020-08-17T17:30:00+03:00
[INFO] 
{code}
Without `skinnyWars` option:
{code:bash}
git checkout MEAR-280 && \
./mvnw clean install -e -DskipTests -Ddocker.skip=true && \
./mvnw clean verify -e -DskipTests artifact:buildinfo -Dreference.repo=central 
-Ddocker.skip=true
...
[INFO] Reference build java.version: 1.8 (from MANIFEST.MF Build-Jdk-Spec)
[INFO] Reference build os.name: Unix (from pom.properties newline)
[INFO] Minimal buildinfo generated from downloaded artifacts: 
/home/user/dockerfile-test/target/reference/app-image-1.1.7-SNAPSHOT.buildinfo
[INFO] Reproducible Build output summary: 2 files ok
[INFO] 
[INFO] Reactor Summary for dockerfile-test 1.1.7-SNAPSHOT:
[INFO]
[INFO] dockerfile-test  SUCCESS [  1.382 s]
[INFO] war  SUCCESS [  1.320 s]
[INFO] ear  SUCCESS [  0.422 s]
[INFO] base-image . SUCCESS [  0.993 s]
[INFO] hollow-image ... SUCCESS [  0.120 s]
[INFO] app-image .. SUCCESS [  0.227 s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time:  5.272 s
[INFO] Finished at: 2020-08-17T17:31:15+03:00
[INFO] 
{code}


was (Author: abrarovm):
This issue looks being still actual because Maven EAR Plugin generates not 
reproducible EARs when skinny WARs option is used 
({{true}} in {{configuration}} of Maven EAR Plugin).

> Reproducible Builds: make entries in output ear files reproducible (order + 
> timestamp)
> --
>
> Key: MEAR-280
> URL: https://issues.apache.org/jira/browse/MEAR-280
> Project: Maven Ear Plugin
>  Issue Type: New Feature
>Affects Versions: 3.0.2
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.1.0
>
>
> since an ear file is a zip file, entries order and timestamp are a natural 
> source of non Reproducible Builds: 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-dependency-plugin] elharo merged pull request #95: [MDEP-644] Add tgf, dot, graphml support for verboseGraphSerializer

[GitBox]

elharo merged pull request #95:
URL: https://github.com/apache/maven-dependency-plugin/pull/95


   



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.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (MEAR-280) Reproducible Builds: make entries in output ear files reproducible (order + timestamp)

[Marat Abrarov (Jira)]

[ 
https://issues.apache.org/jira/browse/MEAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179014#comment-17179014
 ] 

Marat Abrarov commented on MEAR-280:


This issue looks being still actual because Maven EAR Plugin generates not 
reproducible EARs when skinny WARs option is used 
({{true}} in {{configuration}} of Maven EAR Plugin).

> Reproducible Builds: make entries in output ear files reproducible (order + 
> timestamp)
> --
>
> Key: MEAR-280
> URL: https://issues.apache.org/jira/browse/MEAR-280
> Project: Maven Ear Plugin
>  Issue Type: New Feature
>Affects Versions: 3.0.2
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.1.0
>
>
> since an ear file is a zip file, entries order and timestamp are a natural 
> source of non Reproducible Builds: 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-javadoc-plugin] elharo commented on pull request #48: [MJAVADOC-653] fix javadoc; fix code smells

[GitBox]

elharo commented on pull request #48:
URL: 
https://github.com/apache/maven-javadoc-plugin/pull/48#issuecomment-674892736


   Running it through Jenkins now: 
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-javadoc-plugin/job/MJAVADOC-653/



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.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-javadoc-plugin] XenoAmess commented on pull request #48: [MJAVADOC-653] fix javadoc; fix code smells

[GitBox]

XenoAmess commented on pull request #48:
URL: 
https://github.com/apache/maven-javadoc-plugin/pull/48#issuecomment-674888272


   > Yes, if you could rebase and squash your commits that would be wonderful. 
Thanks.
   
   @elharo 
   rebase done.



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.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-dependency-plugin] elharo closed pull request #54: [MDEP-644] [DRAFT] Reintroduce the verbose option for dependency:tree

[GitBox]

elharo closed pull request #54:
URL: https://github.com/apache/maven-dependency-plugin/pull/54


   



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.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-common-artifact-filters] elharo merged pull request #11: fix compile break

[GitBox]

elharo merged pull request #11:
URL: https://github.com/apache/maven-common-artifact-filters/pull/11


   



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.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-common-artifact-filters] elharo opened a new pull request #11: fix compile break

[GitBox]

elharo opened a new pull request #11:
URL: https://github.com/apache/maven-common-artifact-filters/pull/11


   



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.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Assigned] (MDEPLOY-262) Fail on HTTP-Statuscode 409 on Upload instead of warn

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/MDEPLOY-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov reassigned MDEPLOY-262:
--

Assignee: Michael Osipov

> Fail on HTTP-Statuscode 409 on Upload instead of warn
> -
>
> Key: MDEPLOY-262
> URL: https://issues.apache.org/jira/browse/MDEPLOY-262
> Project: Maven Deploy Plugin
>  Issue Type: Bug
>  Components: deploy:deploy
>Affects Versions: 3.0.0-M1
> Environment: Debian 10
> Maven 3.6.1
> Artifactory 6.13.1
>Reporter: Andreas Wirooks
>Assignee: Michael Osipov
>Priority: Major
>
> We have the situation that an upload fails with HTTP-Statuscode 409. Here the 
> maven-deploy-plugin should stop with an error. But it only warns and 
> continues. This results in missing files or in case of overwriting different 
> contents when overwriting did not succeed.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-5838) Maven on No-File-Lock Systems

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-5838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178956#comment-17178956
 ] 

Michael Osipov commented on MNG-5838:
-

This can/will be solved with MRESOLVER-132. In short, I see that locking as 
wrong.

> Maven on No-File-Lock Systems
> -
>
> Key: MNG-5838
> URL: https://issues.apache.org/jira/browse/MNG-5838
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.3.3, 3.3.9
>Reporter: Shana Hutchison
>Priority: Major
>
> I work on a Lustre file system that does not support file locking.  Maven 
> emits tons of warnings when it cannot lock a file due to IOExceptions.  In my 
> case this is not a problem because I only run one maven process at a time and 
> the .m2 directory inside my home directory is not shared, so there is no need 
> to lock files.
> Maven built correctly despite the warnings when using Maven 3.2.3. Then, when 
> I upgraded to Maven 3.3.3, Maven failed on most goals, even clean.  I'd like 
> to at least compile my code with mvn on this system with no file locking, 
> even if it can't run project tests.
> I uploaded log files for running with 3.2.3 and 3.3.3 here:
> 
> Scroll down halfway for the second file.
> Is there an option to disable file locking?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (MNG-5838) Maven on No-File-Lock Systems

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-5838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16741670#comment-16741670
 ] 

Michael Osipov edited comment on MNG-5838 at 8/17/20, 12:38 PM:


We have calls to {{lock()}} also in {{maven-resolver-impl}} in 
{{org.eclipse.aether.internal.impl.TrackingFileManager#lock()}}.


was (Author: slachiewicz):
We have calls to lock() also in maven_-resolver-_impl in 
_org.eclipse.aether.internal.impl.TrackingFileManager#lock_

> Maven on No-File-Lock Systems
> -
>
> Key: MNG-5838
> URL: https://issues.apache.org/jira/browse/MNG-5838
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.3.3, 3.3.9
>Reporter: Shana Hutchison
>Priority: Major
>
> I work on a Lustre file system that does not support file locking.  Maven 
> emits tons of warnings when it cannot lock a file due to IOExceptions.  In my 
> case this is not a problem because I only run one maven process at a time and 
> the .m2 directory inside my home directory is not shared, so there is no need 
> to lock files.
> Maven built correctly despite the warnings when using Maven 3.2.3. Then, when 
> I upgraded to Maven 3.3.3, Maven failed on most goals, even clean.  I'd like 
> to at least compile my code with mvn on this system with no file locking, 
> even if it can't run project tests.
> I uploaded log files for running with 3.2.3 and 3.3.3 here:
> 
> Scroll down halfway for the second file.
> Is there an option to disable file locking?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-parent] elharo commented on pull request #20: [MPOM-250] remove taglets

[GitBox]

elharo commented on pull request #20:
URL: https://github.com/apache/maven-parent/pull/20#issuecomment-674850451


   Ping @rfscholte Is this good to merge?



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.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Closed] (MDEPLOY-271) Allow to optionally disable checksum creation

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/MDEPLOY-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed MDEPLOY-271.
--
Fix Version/s: (was: waiting-for-feedback)
   Resolution: Invalid

> Allow to optionally disable checksum creation
> -
>
> Key: MDEPLOY-271
> URL: https://issues.apache.org/jira/browse/MDEPLOY-271
> Project: Maven Deploy Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.0-M1
>Reporter: Konrad Windszus
>Priority: Major
>
> Since 3.0.0-M1 the deploy goal will always generate SHA1/MD5 for all attached 
> artifacts. The old configuration option 
> https://maven.apache.org/plugins-archives/maven-install-plugin-2.4/install-mojo.html#createChecksum
>  is no longer exposed in the maven-deploy-plugin. That leads to the fact the 
> m-deploy-plugin 3.0.0-M1 will generate MD5/SHA1 even for attached SHA-512 
> artifacts (generated with 
> https://checksum-maven-plugin.nicoulaj.net/artifacts-mojo.html) which are 
> supported by Nexus since https://issues.sonatype.org/browse/NEXUS-21802.
> It would be nice if one would be able to configure _*which artifacts 
> (regex/glob on artifactId) should receive which hashes (algorithm)*_.
> That way generating only MD5 or SHA1 would be possible and also exclusion of 
> checksums for certain attached artifacts.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-javadoc-plugin] XenoAmess commented on pull request #48: [MJAVADOC-653] fix javadoc; fix code smells

[GitBox]

XenoAmess commented on pull request #48:
URL: 
https://github.com/apache/maven-javadoc-plugin/pull/48#issuecomment-674848442


   @elharo 
   Hi.
   What should we do next for this pr?
   Should I sqruash all commits now?



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Closed] (MDEP-444) maven-dependency-plugin goal copy-dependencies version 2.8 with flag stripVersion=false is always overwriting files even when artifact has not changed

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/MDEP-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed MDEP-444.
---
Fix Version/s: (was: more-investigation)
   Resolution: Incomplete

No sample provided.

> maven-dependency-plugin goal copy-dependencies version 2.8 with flag 
> stripVersion=false is always overwriting files even when artifact has not 
> changed
> --
>
> Key: MDEP-444
> URL: https://issues.apache.org/jira/browse/MDEP-444
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: copy-dependencies
>Affects Versions: 2.8
>Reporter: Andres Oviedo
>Priority: Minor
>  Labels: close-pending
>
> Issue:
> * When executing maven-dependency-plugin goal copy-dependencies version 2.8, 
> with flag stripVersion=true, only modified artifacts at nexus are being 
> overwritten at local folder destination (that's ok! so no problem here),  but 
> when stripVersion=false, all files are being overwritten at destination, even 
> when no changes has been made to remote artifacts.
> Diagnostic:
> * Debugging maven-dependency-plugin i think i have seen the bug.  The class 
> org.apache.maven.plugin.dependency.utils.filters.DestFileFilter is ignoring 
> "useBaseVersion" flag.  So, when comparing lastModification date for remote 
> and local artifact, destination file never exists because the generated 
> destination filename has the unique version instead the baseVersion.
> Proposed solution:
> * Propagate "useBaseVersion" flag to 
> org.apache.maven.plugin.dependency.utils.DependencyUtil#getFormattedFileName()
>  method to append baseVersion instead uniqueVersion.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (MDEP-470) Property fileSeparator overrides definition on property pathSeparator

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/MDEP-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed MDEP-470.
---
Resolution: Incomplete

No sample provided.

> Property fileSeparator overrides definition on property pathSeparator
> -
>
> Key: MDEP-470
> URL: https://issues.apache.org/jira/browse/MDEP-470
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: build-classpath
>Affects Versions: 2.8, 2.9
> Environment: Windows
>Reporter: Isabella Silva
>Priority: Major
>  Labels: close-pending
>
> I am trying to generate a classpath to use as a multi-line java property 
> value like this:
> libs/lib1.jar,\
> libs/lib2.jar,\ 
> libs/lib3.jar,\ 
> libs/lib4.jar   
> With this configuration on my pom:
>
>my.classpath
>${libs.dir}
>,\${line.separator}
>/
> 
> It works fine on Unix environments (where the native file separator matches 
> that of my configuration). On Windows, though, I get this (wrong) result:
> libs/lib1.jar,/
> libs/lib2.jar,/ 
> libs/lib3.jar,/ 
> libs/lib4.jar 
> Notice that I've configured the path separator to use the '\' character, not 
> the system native file separator. It seems the file separator is somehow 
> overriding the pathSeparator configuration.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (MDEP-423) Can not unpack dependencies from identified dependent POM without specifying version

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/MDEP-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed MDEP-423.
---
Resolution: Incomplete

No sample provided.

> Can not unpack dependencies from identified dependent POM without specifying 
> version
> 
>
> Key: MDEP-423
> URL: https://issues.apache.org/jira/browse/MDEP-423
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: unpack
>Affects Versions: 2.8
>Reporter: Eric Miles
>Priority: Major
>  Labels: close-pending
>
> Even if the dependency from the included POM is in the dependency tree, I can 
> not unpack it unless I specify the version...which defeats the purpose of an 
> aggregator POM.
> aggregator-pom.xml
> {noformat}
> ...
> mycompany.com
> aggregator-pom
> 1.0.0
> pom
> ...
> 
> somegroup
> someartifact
> 1.2.3
> 
> ...
> {noformat}
> pom-to-do-unpacking.xml
> {noformat}
> ...
> 
> mycompany.com
> aggregator-pom
> 1.0.0
> pom
> 
> ...
> 
> maven-dependency-plugin>
> 
> unpack
> 
> 
> 
>   
>   somegroup
>   someartifact
>   

[jira] [Closed] (MDEP-489) Regression: unpack-dependencies fails on Windows for tar.gz containing executable file

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/MDEP-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed MDEP-489.
---
Resolution: Incomplete

Nothing provided.

> Regression: unpack-dependencies fails on Windows for tar.gz containing 
> executable file
> --
>
> Key: MDEP-489
> URL: https://issues.apache.org/jira/browse/MDEP-489
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: unpack-dependencies
>Affects Versions: 2.10
>Reporter: Axel Fontaine
>Priority: Major
>  Labels: close-pending
>
> unpack-dependencies fails on Windows for a tar.gz dependency containing an 
> executable file with the following message:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-dependency-plugin:2.10:unpack-dependencies 
> (unpa
> ck-jres) on project boxfuse-commandline: Error unpacking file: 
> C:\Users\Axel\.m2\repository\com\oracle\server-
> jre\8.45\server-jre-8.45-linux-x64.tar.gz to: 
> C:\Workspaces\boxfuse-client\boxfuse-commandline\target\dependen
> cy\server-jre-linux-x64-tar.gz
> [ERROR] org.codehaus.plexus.archiver.ArchiverException: Error while expanding 
> C:\Users\Axel\.m2\repository\com
> \oracle\server-jre\8.45\server-jre-8.45-linux-x64.tar.gz: 
> C:\Workspaces\boxfuse-client\boxfuse-commandline\tar
> get\dependency\server-jre-linux-x64-tar.gz\jdk1.8.0_45\jre\lib\amd64\server\libjsig.so:
>  A required privilege i
> s not held by the client.
> This was working fine in all previous versions including 2.8 and 2.9



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (MRELEASE-984) release:perform checkout wrong url for svn, 2.5.3 regression

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/MRELEASE-984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed MRELEASE-984.
---
Fix Version/s: (was: waiting-for-feedback)
   Resolution: Incomplete

No feedback provided.

> release:perform checkout wrong url for svn, 2.5.3 regression
> 
>
> Key: MRELEASE-984
> URL: https://issues.apache.org/jira/browse/MRELEASE-984
> Project: Maven Release Plugin
>  Issue Type: Bug
>  Components: perform
>Affects Versions: 2.5.3
>Reporter: Dave Moten
>Priority: Major
>
> This is a 2.5.3 regresssion with svn only. No problem in 2.5.1.
> The first step of release:perform is to checkout the new tag into target. 
> This works fine using 2.5.1 and svn. With 2.5.3 the checkout tag is not 
> specified at the end of the svn url and a checkout occurs of 
> `svn://svn.amsa.gov.au/mainRepository/searchAndRescue/cvsTransfer/aussar/projects/master/tags`
>  which contains hundreds of tags so we hang and probably run out of disk on 
> our small jenkins instance.
> This is the log with 2.5.1:
> [INFO] --- maven-release-plugin:2.5.1:perform (default-cli) @ master ---
> [INFO] Checking out the project to perform the release ...
> [INFO] Executing: /bin/sh -c cd 
> /var/lib/jenkins/jobs/Build_release/workspace/target && svn --non-interactive 
> checkout 
> svn://svn.amsa.gov.au/mainRepository/searchAndRescue/cvsTransfer/aussar/projects/master/tags/7.12.4.6
>  /var/lib/jenkins/jobs/Build_release/workspace/target/checkout



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (MNG-6615) Failed to execute mvn site command for any project, including brand new

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-6615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed MNG-6615.
---
Fix Version/s: (was: waiting-for-feedback)
   Resolution: Incomplete

No information provided.

> Failed to execute mvn site command for any project, including brand new
> ---
>
> Key: MNG-6615
> URL: https://issues.apache.org/jira/browse/MNG-6615
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.6.0
>Reporter: Mykyta Bezverkhyi
>Priority: Major
>
> Steps to reproduce:
>  # Create project of any archetype using Maven 3.6.0.
>  # Execute _mvn site_ command.
> *Actual result:* [INFO] BUILD FAILURE
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project 
> test:
> Execution default-site of goal 
> org.apache.maven.plugins:maven-site-plugin:3.3:site failed:
> A required class was missing while executing 
> org.apache.maven.plugins:maven-site-plugin:3.3:site:
> org/apache/maven/doxia/siterenderer/DocumentContent
> *Expected result:* [INFO] BUILD SUCCESS
> Notes: As far as I know it can be fixed by updating _maven-site-plugin_ 
> version to the latest one, currently _3.7.1_, but it's kinda annoying to do 
> this for all of the projects and trying to remember what you did to fix it 
> coding the new one. So I think it makes sense for you to update the default 
> plugin version to _3.7.1_ in your next release, or to fix it in the way you 
> want.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (MNG-6673) Deprecate HTTP Download & Upload

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-6673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed MNG-6673.
---
Resolution: Not A Problem

> Deprecate HTTP Download & Upload
> 
>
> Key: MNG-6673
> URL: https://issues.apache.org/jira/browse/MNG-6673
> Project: Maven
>  Issue Type: Improvement
>  Components: Deployment
>Reporter: Jonathan Leitschuh
>Priority: Major
>  Labels: SECURITY, security
> Attachments: mitm_build.jpeg
>
>
> Some of the most popular Java projects in the JVM ecosystem are vulnerable to 
> a MITM of their dependencies. This is something that build tools can help 
> prevent.
> Starting in the next release of Maven, Maven should begin warning users about 
> the use of HTTP to download/upload artifacts to/from artifact servers.
> I believe that Maven/Gradle/SBT should require users to opt-out of the 
> security offered by using HTTPS to download/upload artifacts.
> Here's a list of projects that were found to be vulnerable to this:
> [https://docs.google.com/spreadsheets/d/1zemxj8QdIp0saqvwJx6Po1KnyEmJXl2KC_0j0SLd_2E/edit?usp=sharing]
>  
> 
> The full description of this industry-wide vulnerability can be found here:
> [Want to take over the Java ecosystem? All you need is a 
> MITM!|https://medium.com/@jonathan.leitschuh/want-to-take-over-the-java-ecosystem-all-you-need-is-a-mitm-1fc329d898fb?source=friends_link&sk=3c99970c55a899ad9ef41f126efcde0e]
>  !mitm_build.jpeg! 
>   



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (MDEPLOY-271) Allow to optionally disable checksum creation

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/MDEPLOY-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178935#comment-17178935
 ] 

Konrad Windszus edited comment on MDEPLOY-271 at 8/17/20, 11:58 AM:


With MSHARED-922 being implemented we can close this one as invalid.
[~michael-o] As I don't have the karma to close my own issues, can you do that?


was (Author: kwin):
With MSHARED-922 being implemented we can close this one as invalid.

> Allow to optionally disable checksum creation
> -
>
> Key: MDEPLOY-271
> URL: https://issues.apache.org/jira/browse/MDEPLOY-271
> Project: Maven Deploy Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.0-M1
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Since 3.0.0-M1 the deploy goal will always generate SHA1/MD5 for all attached 
> artifacts. The old configuration option 
> https://maven.apache.org/plugins-archives/maven-install-plugin-2.4/install-mojo.html#createChecksum
>  is no longer exposed in the maven-deploy-plugin. That leads to the fact the 
> m-deploy-plugin 3.0.0-M1 will generate MD5/SHA1 even for attached SHA-512 
> artifacts (generated with 
> https://checksum-maven-plugin.nicoulaj.net/artifacts-mojo.html) which are 
> supported by Nexus since https://issues.sonatype.org/browse/NEXUS-21802.
> It would be nice if one would be able to configure _*which artifacts 
> (regex/glob on artifactId) should receive which hashes (algorithm)*_.
> That way generating only MD5 or SHA1 would be possible and also exclusion of 
> checksums for certain attached artifacts.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MDEPLOY-271) Allow to optionally disable checksum creation

[Konrad Windszus (Jira)]

[ 
https://issues.apache.org/jira/browse/MDEPLOY-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178935#comment-17178935
 ] 

Konrad Windszus commented on MDEPLOY-271:
-

With MSHARED-922 being implemented we can close this one as invalid.

> Allow to optionally disable checksum creation
> -
>
> Key: MDEPLOY-271
> URL: https://issues.apache.org/jira/browse/MDEPLOY-271
> Project: Maven Deploy Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.0-M1
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Since 3.0.0-M1 the deploy goal will always generate SHA1/MD5 for all attached 
> artifacts. The old configuration option 
> https://maven.apache.org/plugins-archives/maven-install-plugin-2.4/install-mojo.html#createChecksum
>  is no longer exposed in the maven-deploy-plugin. That leads to the fact the 
> m-deploy-plugin 3.0.0-M1 will generate MD5/SHA1 even for attached SHA-512 
> artifacts (generated with 
> https://checksum-maven-plugin.nicoulaj.net/artifacts-mojo.html) which are 
> supported by Nexus since https://issues.sonatype.org/browse/NEXUS-21802.
> It would be nice if one would be able to configure _*which artifacts 
> (regex/glob on artifactId) should receive which hashes (algorithm)*_.
> That way generating only MD5 or SHA1 would be possible and also exclusion of 
> checksums for certain attached artifacts.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (DOXIA-568) Doxia Markdown extension > Support for some MarkDown extensions has been removed since 1.7

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/DOXIA-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed DOXIA-568.

Resolution: Incomplete

No reaction for six months.

> Doxia Markdown extension > Support for some MarkDown extensions has been 
> removed since 1.7
> --
>
> Key: DOXIA-568
> URL: https://issues.apache.org/jira/browse/DOXIA-568
> Project: Maven Doxia
>  Issue Type: Bug
>  Components: Module - Markdown
>Affects Versions: 1.8
>Reporter: Matthieu Ghilain
>Priority: Major
>
> Currently the markdown extensions which are allowed by the Doxia parser seems 
> to be fixed to a subset of what was allowed with Doxia 1.7 and old PegDown 
> library.
> I would like to be able to use the anchor link extension which was available 
> with 1.7 as well as the syntax highlighting that was also available for 
> scripts.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (MJAVADOC-641) 3.1.1 does not handle proxy username or proxy password

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/MJAVADOC-641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed MJAVADOC-641.
---
Fix Version/s: (was: wontfix-candidate)
   Resolution: Won't Fix

> 3.1.1 does not handle proxy username or proxy password
> --
>
> Key: MJAVADOC-641
> URL: https://issues.apache.org/jira/browse/MJAVADOC-641
> Project: Maven Javadoc Plugin
>  Issue Type: Bug
>  Components: jar
>Affects Versions: 3.1.1
>Reporter: Thomas Cunningham
>Priority: Major
>
> I'm seeing the following trying to build camel behind a firewall : 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-javadoc-plugin:3.1.1:jar (attach-javadocs) on 
> project camel-util: MavenReportException: Error while generating Javadoc: 
> [ERROR] Exit code: 1 - javadoc: error - Error fetching URL: 
> https://download.oracle.com/javase/7/docs/api/
> [ERROR] javadoc: error - Error fetching URL: 
> [https://download.oracle.com/javaee/7/api/]
>  
> This is a new issue for us, and maven-javadoc-plugin 3.0.1 seems to work fine 
> while 3.1.1 gives this error.
>  
> I dug in a little and I think the issue is that in 3.0.1 handles proxy 
> username and password :
> [https://github.com/apache/maven-javadoc-plugin/blob/maven-javadoc-plugin-3.0.1/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L3606-L3614]
>  
> As far as I can see (and I might be missing something here), 3.1.1 does not : 
> [https://github.com/apache/maven-javadoc-plugin/blob/maven-javadoc-plugin-3.1.1/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java#L3674-L3690]
>  
>  
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (SCM-934) Add Maven SCM Provider for Micro Focus Dimensions CM

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/SCM-934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed SCM-934.
--
Resolution: Won't Fix

We cannot and will not support another commercial SCM. This has to be 
maintained by the software vendor only.

> Add Maven SCM Provider for Micro Focus Dimensions CM
> 
>
> Key: SCM-934
> URL: https://issues.apache.org/jira/browse/SCM-934
> Project: Maven SCM
>  Issue Type: New Feature
>  Components: maven-plugin
>Affects Versions: 1.11.2
>Reporter: Peter Raymond
>Priority: Major
>  Labels: newbie
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> We have developed a Maven SCM Provider for the Micro Focus Dimensions CM SCCM 
> system ([https://www.microfocus.com/en-us/products/dimensions-cm/overview]) 
> and would like to add this to the maven-scm project.
> The code and documentation are currently hosted on GitHub under an Apache 2.0 
> License:
> [https://github.com/MicroFocus/maven-scm-provider-dimensionscm]
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (MNG-6446) @Parameters Annotation does not function

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-6446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed MNG-6446.
---
Fix Version/s: (was: waiting-for-feedback)
   Resolution: Incomplete

No sample provided.

> @Parameters Annotation does not function
> 
>
> Key: MNG-6446
> URL: https://issues.apache.org/jira/browse/MNG-6446
> Project: Maven
>  Issue Type: Bug
>  Components: Plugin API
>Reporter: Jonathan S Fisher
>Priority: Major
>  Labels: bug
>
> If you create a plugin with the following code:
> {code:java}
> @Named
> @Singleton
> public class FileKeysCache implements KeysCache {
>   @Inject
>   private Logger logger;
>   @Inject
>   @Parameters
>   private Map parameters;
> }
> {code}
> The `parameters` field is always a blank map. The doc here says is should be 
> a map of parameters: 
> https://wiki.eclipse.org/Sisu/PlexusMigration#.40Configuration



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MDEPLOY-271) Allow to optionally disable checksum creation

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MDEPLOY-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178928#comment-17178928
 ] 

Michael Osipov commented on MDEPLOY-271:


Can we close this?

> Allow to optionally disable checksum creation
> -
>
> Key: MDEPLOY-271
> URL: https://issues.apache.org/jira/browse/MDEPLOY-271
> Project: Maven Deploy Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.0-M1
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Since 3.0.0-M1 the deploy goal will always generate SHA1/MD5 for all attached 
> artifacts. The old configuration option 
> https://maven.apache.org/plugins-archives/maven-install-plugin-2.4/install-mojo.html#createChecksum
>  is no longer exposed in the maven-deploy-plugin. That leads to the fact the 
> m-deploy-plugin 3.0.0-M1 will generate MD5/SHA1 even for attached SHA-512 
> artifacts (generated with 
> https://checksum-maven-plugin.nicoulaj.net/artifacts-mojo.html) which are 
> supported by Nexus since https://issues.sonatype.org/browse/NEXUS-21802.
> It would be nice if one would be able to configure _*which artifacts 
> (regex/glob on artifactId) should receive which hashes (algorithm)*_.
> That way generating only MD5 or SHA1 would be possible and also exclusion of 
> checksums for certain attached artifacts.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (MNG-5622) Provided dependencies updated to 'compile' even when excluded

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-5622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed MNG-5622.
---
Resolution: Incomplete

No further information provided.

> Provided dependencies updated to 'compile' even when excluded
> -
>
> Key: MNG-5622
> URL: https://issues.apache.org/jira/browse/MNG-5622
> Project: Maven
>  Issue Type: Bug
>  Components: Dependencies
>Affects Versions: 3.0.5, 3.2.1
>Reporter: Cintia DR
>Priority: Minor
>  Labels: needs-attention
> Attachments: dependencies-maven.tar.gz
>
>
> I have a project A with the following dependency:
> {code}
>  
> dom4j
> dom4j
> 1.6.1
> 
> {code}
> _dom4j_ has a compile dependency _xml-api_. 
> In the project B, I use project A as a provided dependency. And it has 
> another dependency:
> {code}
> 
>   
> org.apache.poi
> poi-ooxml
> 3.9
> 
>   
> xml-apis
> xml-apis
>   
>  
>   
> {code}
> So, what happens is maven 3.2.1 adds xml-api as a compile dependency 
> regardless if you exclude it from poi-ooxml. 
> As far as I understood, maven is getting project A dependencies, and finds a 
> _dom4j_. It was initially supposed to be 
> [provided|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope],
>  but the compile dependency _poi-ooxml_ has _dom4j_ as a transitive compile 
> dependency - so maven correctly updates _dom4j_ scope to compile.
> The problem is, because it's adding _dom4j_ to compile scope, it decides to 
> upgrade _xml-api_ to a compile dependency, *even if we excluded it* in the 
> first place. 
> The obvious workaround is to exclude _dom4j_ from _poi-ooxml_.  
> I'm not sure if this is the expected behaviour, or just a corner case. I 
> couldn't find any valid documentation about that case. 
> This is a possible duplicate of MNG-5404, but it looks slightly different. I 
> wonder if they have the same root cause. 
> To run the test attached, "mvn package dependency:tree" will do it. 
> dependency:2.8:tree is showing the same resolution tree as maven itself. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MDEPLOY-271) Allow to optionally disable checksum creation

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/MDEPLOY-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MDEPLOY-271:
---
Fix Version/s: waiting-for-feedback

> Allow to optionally disable checksum creation
> -
>
> Key: MDEPLOY-271
> URL: https://issues.apache.org/jira/browse/MDEPLOY-271
> Project: Maven Deploy Plugin
>  Issue Type: Improvement
>Affects Versions: 3.0.0-M1
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Since 3.0.0-M1 the deploy goal will always generate SHA1/MD5 for all attached 
> artifacts. The old configuration option 
> https://maven.apache.org/plugins-archives/maven-install-plugin-2.4/install-mojo.html#createChecksum
>  is no longer exposed in the maven-deploy-plugin. That leads to the fact the 
> m-deploy-plugin 3.0.0-M1 will generate MD5/SHA1 even for attached SHA-512 
> artifacts (generated with 
> https://checksum-maven-plugin.nicoulaj.net/artifacts-mojo.html) which are 
> supported by Nexus since https://issues.sonatype.org/browse/NEXUS-21802.
> It would be nice if one would be able to configure _*which artifacts 
> (regex/glob on artifactId) should receive which hashes (algorithm)*_.
> That way generating only MD5 or SHA1 would be possible and also exclusion of 
> checksums for certain attached artifacts.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MINSTALL-138) option to calculate more checksum such sha-256 sha-512

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MINSTALL-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178924#comment-17178924
 ] 

Michael Osipov commented on MINSTALL-138:
-

I consider this one as wontfix and [~kwin] has layed out.

> option to calculate more checksum such sha-256 sha-512
> --
>
> Key: MINSTALL-138
> URL: https://issues.apache.org/jira/browse/MINSTALL-138
> Project: Maven Install Plugin
>  Issue Type: New Feature
>  Components: install:install, install:install-file
>Affects Versions: 2.5.2
>Reporter: Olivier Lamy
>Assignee: Olivier Lamy
>Priority: Major
>
> currently install generate only sha-1 we should be able to generate sha-256 
> and sha-512 as well.
> NOTE: sha-512 will be required by Apache policy.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (WAGON-598) Backblaze Wagon Provider

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/WAGON-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed WAGON-598.

Resolution: Won't Fix

This has to be maintained by Backblaze and Backblaze only!

> Backblaze Wagon Provider
> 
>
> Key: WAGON-598
> URL: https://issues.apache.org/jira/browse/WAGON-598
> Project: Maven Wagon
>  Issue Type: New Feature
>Reporter: Denis Ivanov
>Priority: Minor
>
> Hello friends!
> I'd like to implement a new provider for storing artifacts at Backblaze B2 
> Cloud.
>  Their raw HTTP API requires some additional steps for getting and uploading 
> data so using wagon-http extension is not possible.
>  Here is an official [client|https://github.com/Backblaze/b2-sdk-java] and I 
> can make a wrapper on top of it.
> I have a question about getting information from ~/.m2/settings.xml from my 
> java code.
> For example I have *settings.xml*:
> {code:xml}
> 
>   
> backblaze.com
> ${text}
> ${text}
>   
> 
> {code}
> and *pom.xml*:
> {code:xml}
> 
>   
> backblaze.com
> b2://bucket endpoint provided after 
> creating/bucket-name/release
>   
> 
> {code}
> If someone helps with an example usage it will be great! Any example 
> implementations are very appreciated!
> Thanks in advance!



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MDEPLOY-274) Deploy archetype failed with Unauthorized error

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/MDEPLOY-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MDEPLOY-274:
---
Fix Version/s: waiting-for-feedback

> Deploy archetype failed with Unauthorized error
> ---
>
> Key: MDEPLOY-274
> URL: https://issues.apache.org/jira/browse/MDEPLOY-274
> Project: Maven Deploy Plugin
>  Issue Type: Bug
>  Components: deploy:deploy
>Affects Versions: 3.0.0-M1
>Reporter: Yin Xiang
>Priority: Major
> Fix For: waiting-for-feedback
>
>
>  
> {code:java}
> [DEBUG] Using catalog /Users/sean/.m2/repository/archetype-catalog.xml
> [DEBUG] Reading the catalog /Users/sean/.m2/repository/archetype-catalog.xml
> [INFO] 
> [INFO] --- maven-deploy-plugin:3.0.0-M1:deploy (default-deploy) @ 
> athena-project-incubator ---
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=0, 
> ConflictMarker.markTime=0, ConflictMarker.nodeCount=74, 
> ConflictIdSorter.graphTime=0, ConflictIdSorter.topsortTime=0, 
> ConflictIdSorter.conflictIdCount=29, ConflictIdSorter.conflictIdCycleCount=0, 
> ConflictResolver.totalTime=2, ConflictResolver.conflictItemCount=73, 
> DefaultDependencyCollector.collectTime=5, 
> DefaultDependencyCollector.transformTime=2}
> [DEBUG] org.apache.maven.plugins:maven-deploy-plugin:jar:3.0.0-M1:
> [DEBUG]org.apache.maven:maven-plugin-api:jar:3.0:compile
> [DEBUG]   org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
> [DEBUG]  org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
> [DEBUG] org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
> [DEBUG]org.apache.maven:maven-core:jar:3.0:compile
> [DEBUG]   org.apache.maven:maven-settings:jar:3.0:compile
> [DEBUG]   org.apache.maven:maven-settings-builder:jar:3.0:compile
> [DEBUG]   org.apache.maven:maven-repository-metadata:jar:3.0:compile
> [DEBUG]   org.apache.maven:maven-model-builder:jar:3.0:compile
> [DEBUG]   org.apache.maven:maven-aether-provider:jar:3.0:runtime
> [DEBUG]   org.sonatype.aether:aether-impl:jar:1.7:compile
> [DEBUG]  org.sonatype.aether:aether-spi:jar:1.7:compile
> [DEBUG]   org.sonatype.aether:aether-api:jar:1.7:compile
> [DEBUG]   org.sonatype.aether:aether-util:jar:1.7:compile
> [DEBUG]   org.codehaus.plexus:plexus-interpolation:jar:1.14:compile
> [DEBUG]   org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
> [DEBUG]   
> org.codehaus.plexus:plexus-component-annotations:jar:1.7.1:compile
> [DEBUG]   org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3:compile
> [DEBUG]  org.sonatype.plexus:plexus-cipher:jar:1.4:compile
> [DEBUG]org.apache.maven:maven-model:jar:3.0:compile
> [DEBUG]org.apache.maven:maven-artifact:jar:3.0:compile
> [DEBUG]org.apache.maven.shared:maven-artifact-transfer:jar:0.10.0:compile
> [DEBUG]   
> org.apache.maven.shared:maven-common-artifact-filters:jar:3.0.1:compile
> [DEBUG]  org.apache.maven.shared:maven-shared-utils:jar:3.1.0:compile
> [DEBUG]   commons-codec:commons-codec:jar:1.11:compile
> [DEBUG]   org.slf4j:slf4j-api:jar:1.7.5:compile
> [DEBUG]commons-io:commons-io:jar:2.5:compile
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:3.1.0:compile
> [DEBUG] Created new class realm 
> plugin>org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1
> [DEBUG] Importing foreign packages into class realm 
> plugin>org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1
> [DEBUG]   Imported:  < 
> project>com.github.archetype:athena-project-incubator:1.0.2-SNAPSHOT
> [DEBUG] Populating class realm 
> plugin>org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1
> [DEBUG]   Included: org.apache.maven.plugins:maven-deploy-plugin:jar:3.0.0-M1
> [DEBUG]   Included: org.sonatype.sisu:sisu-inject-bean:jar:1.4.2
> [DEBUG]   Included: org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7
> [DEBUG]   Included: org.apache.maven:maven-aether-provider:jar:3.0
> [DEBUG]   Included: org.sonatype.aether:aether-util:jar:1.7
> [DEBUG]   Included: org.codehaus.plexus:plexus-interpolation:jar:1.14
> [DEBUG]   Included: org.codehaus.plexus:plexus-component-annotations:jar:1.7.1
> [DEBUG]   Included: org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3
> [DEBUG]   Included: org.sonatype.plexus:plexus-cipher:jar:1.4
> [DEBUG]   Included: org.apache.maven.shared:maven-artifact-transfer:jar:0.10.0
> [DEBUG]   Included: 
> org.apache.maven.shared:maven-common-artifact-filters:jar:3.0.1
> [DEBUG]   Included: org.apache.maven.shared:maven-shared-utils:jar:3.1.0
> [DEBUG]   Included: commons-codec:commons-codec:jar:1.11
> [DEBUG]   Included: commons-io:commons-io:jar:2.5
> [DEBUG]   Included: org.codehaus.plexus:plexus-utils:jar:3.1.0
> [DEBUG] Configuring mojo 
> org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy from plugin 
> realm 
> ClassRe

[jira] [Commented] (MDEPLOY-274) Deploy archetype failed with Unauthorized error

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MDEPLOY-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178922#comment-17178922
 ] 

Michael Osipov commented on MDEPLOY-274:


Enable debug logs on HttpClient.

> Deploy archetype failed with Unauthorized error
> ---
>
> Key: MDEPLOY-274
> URL: https://issues.apache.org/jira/browse/MDEPLOY-274
> Project: Maven Deploy Plugin
>  Issue Type: Bug
>  Components: deploy:deploy
>Affects Versions: 3.0.0-M1
>Reporter: Yin Xiang
>Priority: Major
> Fix For: waiting-for-feedback
>
>
>  
> {code:java}
> [DEBUG] Using catalog /Users/sean/.m2/repository/archetype-catalog.xml
> [DEBUG] Reading the catalog /Users/sean/.m2/repository/archetype-catalog.xml
> [INFO] 
> [INFO] --- maven-deploy-plugin:3.0.0-M1:deploy (default-deploy) @ 
> athena-project-incubator ---
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=0, 
> ConflictMarker.markTime=0, ConflictMarker.nodeCount=74, 
> ConflictIdSorter.graphTime=0, ConflictIdSorter.topsortTime=0, 
> ConflictIdSorter.conflictIdCount=29, ConflictIdSorter.conflictIdCycleCount=0, 
> ConflictResolver.totalTime=2, ConflictResolver.conflictItemCount=73, 
> DefaultDependencyCollector.collectTime=5, 
> DefaultDependencyCollector.transformTime=2}
> [DEBUG] org.apache.maven.plugins:maven-deploy-plugin:jar:3.0.0-M1:
> [DEBUG]org.apache.maven:maven-plugin-api:jar:3.0:compile
> [DEBUG]   org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile
> [DEBUG]  org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile
> [DEBUG] org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile
> [DEBUG]org.apache.maven:maven-core:jar:3.0:compile
> [DEBUG]   org.apache.maven:maven-settings:jar:3.0:compile
> [DEBUG]   org.apache.maven:maven-settings-builder:jar:3.0:compile
> [DEBUG]   org.apache.maven:maven-repository-metadata:jar:3.0:compile
> [DEBUG]   org.apache.maven:maven-model-builder:jar:3.0:compile
> [DEBUG]   org.apache.maven:maven-aether-provider:jar:3.0:runtime
> [DEBUG]   org.sonatype.aether:aether-impl:jar:1.7:compile
> [DEBUG]  org.sonatype.aether:aether-spi:jar:1.7:compile
> [DEBUG]   org.sonatype.aether:aether-api:jar:1.7:compile
> [DEBUG]   org.sonatype.aether:aether-util:jar:1.7:compile
> [DEBUG]   org.codehaus.plexus:plexus-interpolation:jar:1.14:compile
> [DEBUG]   org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile
> [DEBUG]   
> org.codehaus.plexus:plexus-component-annotations:jar:1.7.1:compile
> [DEBUG]   org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3:compile
> [DEBUG]  org.sonatype.plexus:plexus-cipher:jar:1.4:compile
> [DEBUG]org.apache.maven:maven-model:jar:3.0:compile
> [DEBUG]org.apache.maven:maven-artifact:jar:3.0:compile
> [DEBUG]org.apache.maven.shared:maven-artifact-transfer:jar:0.10.0:compile
> [DEBUG]   
> org.apache.maven.shared:maven-common-artifact-filters:jar:3.0.1:compile
> [DEBUG]  org.apache.maven.shared:maven-shared-utils:jar:3.1.0:compile
> [DEBUG]   commons-codec:commons-codec:jar:1.11:compile
> [DEBUG]   org.slf4j:slf4j-api:jar:1.7.5:compile
> [DEBUG]commons-io:commons-io:jar:2.5:compile
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:3.1.0:compile
> [DEBUG] Created new class realm 
> plugin>org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1
> [DEBUG] Importing foreign packages into class realm 
> plugin>org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1
> [DEBUG]   Imported:  < 
> project>com.github.archetype:athena-project-incubator:1.0.2-SNAPSHOT
> [DEBUG] Populating class realm 
> plugin>org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1
> [DEBUG]   Included: org.apache.maven.plugins:maven-deploy-plugin:jar:3.0.0-M1
> [DEBUG]   Included: org.sonatype.sisu:sisu-inject-bean:jar:1.4.2
> [DEBUG]   Included: org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7
> [DEBUG]   Included: org.apache.maven:maven-aether-provider:jar:3.0
> [DEBUG]   Included: org.sonatype.aether:aether-util:jar:1.7
> [DEBUG]   Included: org.codehaus.plexus:plexus-interpolation:jar:1.14
> [DEBUG]   Included: org.codehaus.plexus:plexus-component-annotations:jar:1.7.1
> [DEBUG]   Included: org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3
> [DEBUG]   Included: org.sonatype.plexus:plexus-cipher:jar:1.4
> [DEBUG]   Included: org.apache.maven.shared:maven-artifact-transfer:jar:0.10.0
> [DEBUG]   Included: 
> org.apache.maven.shared:maven-common-artifact-filters:jar:3.0.1
> [DEBUG]   Included: org.apache.maven.shared:maven-shared-utils:jar:3.1.0
> [DEBUG]   Included: commons-codec:commons-codec:jar:1.11
> [DEBUG]   Included: commons-io:commons-io:jar:2.5
> [DEBUG]   Included: org.codehaus.plexus:plexus-utils:jar:3.1.0
> [DEBUG] Configuring mojo 
> org.apache.maven.plugins:maven-deploy-plu

[jira] [Closed] (SUREFIRE-1833) Classes of dependency not found since 3.0.0-M5

[Tibor Digana (Jira)]

 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tibor Digana closed SUREFIRE-1833.
--
  Assignee: Tibor Digana
Resolution: Duplicate

> Classes of dependency not found since 3.0.0-M5
> --
>
> Key: SUREFIRE-1833
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1833
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
> Environment: java -version:
> openjdk version "11.0.8" 2020-07-14
> OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.8+10)
> OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.8+10, mixed mode)
> mvn -version:
> Apache Maven 3.6.0
> Maven home: /usr/share/maven
> Java version: 11.0.8, vendor: AdoptOpenJDK, runtime: […]/java/11.0.8.hs-adpt
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.13.0-21-generic", arch: "amd64", family: "unix"
> Operating system is Ubuntu Linux 18.04.
>Reporter: Jeroen Hoek
>Assignee: Tibor Digana
>Priority: Major
>
> During an upgrade of the surefire and failsafe plugins in my projects I ran 
> into an issue with failsafe {{3.0.0-M5}} not seeing the classes from a Maven 
> dependency on a module from the same project.
> I have created a minimal reproduction case that contains two modules, one 
> containing a single class and a unit-test, and one containing a single 
> integration test:
> [https://github.com/LableOrg/failsafe-classnotfound-reproduction]
> After cloning the repo, these three commands can be used to build the project 
> and run the tests. The Maven profiles set the version of surefire/failsafe 
> used:
> ||Version||Command||Result||
> |{{2.22.2}}|{{mvn clean install -Dold2}}|works|
> |{{3.0.0-M4}}|{{mvn clean install -Dold3}}|works|
> |{{3.0.0-M5}}|{{mvn clean install}}|*fails*|
> The result for me is:
> {code:java}
> java.lang.NoClassDefFoundError: 
> org/example/sample/failsafe300m5/SampleException
> {code}
> Is there something I am doing wrong, or is this a bug introduced in 
> {{3.0.0-M5}}?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1833) Classes of dependency not found since 3.0.0-M5

[Jeroen Hoek (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178915#comment-17178915
 ] 

Jeroen Hoek commented on SUREFIRE-1833:
---

Nice to see that the issue was already fixed, and thanks for the workaround.

> Classes of dependency not found since 3.0.0-M5
> --
>
> Key: SUREFIRE-1833
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1833
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
> Environment: java -version:
> openjdk version "11.0.8" 2020-07-14
> OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.8+10)
> OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.8+10, mixed mode)
> mvn -version:
> Apache Maven 3.6.0
> Maven home: /usr/share/maven
> Java version: 11.0.8, vendor: AdoptOpenJDK, runtime: […]/java/11.0.8.hs-adpt
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.13.0-21-generic", arch: "amd64", family: "unix"
> Operating system is Ubuntu Linux 18.04.
>Reporter: Jeroen Hoek
>Priority: Major
>
> During an upgrade of the surefire and failsafe plugins in my projects I ran 
> into an issue with failsafe {{3.0.0-M5}} not seeing the classes from a Maven 
> dependency on a module from the same project.
> I have created a minimal reproduction case that contains two modules, one 
> containing a single class and a unit-test, and one containing a single 
> integration test:
> [https://github.com/LableOrg/failsafe-classnotfound-reproduction]
> After cloning the repo, these three commands can be used to build the project 
> and run the tests. The Maven profiles set the version of surefire/failsafe 
> used:
> ||Version||Command||Result||
> |{{2.22.2}}|{{mvn clean install -Dold2}}|works|
> |{{3.0.0-M4}}|{{mvn clean install -Dold3}}|works|
> |{{3.0.0-M5}}|{{mvn clean install}}|*fails*|
> The result for me is:
> {code:java}
> java.lang.NoClassDefFoundError: 
> org/example/sample/failsafe300m5/SampleException
> {code}
> Is there something I am doing wrong, or is this a bug introduced in 
> {{3.0.0-M5}}?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1833) Classes of dependency not found since 3.0.0-M5

[Jeroen Hoek (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178914#comment-17178914
 ] 

Jeroen Hoek commented on SUREFIRE-1833:
---

That does look like the same thing. I've tested the workaround and it seems to 
work for my small reproduction case. I've added a Maven profile with it:

{{mvn clean install -Dworkaround}}


> Classes of dependency not found since 3.0.0-M5
> --
>
> Key: SUREFIRE-1833
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1833
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
> Environment: java -version:
> openjdk version "11.0.8" 2020-07-14
> OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.8+10)
> OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.8+10, mixed mode)
> mvn -version:
> Apache Maven 3.6.0
> Maven home: /usr/share/maven
> Java version: 11.0.8, vendor: AdoptOpenJDK, runtime: […]/java/11.0.8.hs-adpt
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.13.0-21-generic", arch: "amd64", family: "unix"
> Operating system is Ubuntu Linux 18.04.
>Reporter: Jeroen Hoek
>Priority: Major
>
> During an upgrade of the surefire and failsafe plugins in my projects I ran 
> into an issue with failsafe {{3.0.0-M5}} not seeing the classes from a Maven 
> dependency on a module from the same project.
> I have created a minimal reproduction case that contains two modules, one 
> containing a single class and a unit-test, and one containing a single 
> integration test:
> [https://github.com/LableOrg/failsafe-classnotfound-reproduction]
> After cloning the repo, these three commands can be used to build the project 
> and run the tests. The Maven profiles set the version of surefire/failsafe 
> used:
> ||Version||Command||Result||
> |{{2.22.2}}|{{mvn clean install -Dold2}}|works|
> |{{3.0.0-M4}}|{{mvn clean install -Dold3}}|works|
> |{{3.0.0-M5}}|{{mvn clean install}}|*fails*|
> The result for me is:
> {code:java}
> java.lang.NoClassDefFoundError: 
> org/example/sample/failsafe300m5/SampleException
> {code}
> Is there something I am doing wrong, or is this a bug introduced in 
> {{3.0.0-M5}}?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-6977) Use hyphen when creating builder threads (names)

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-6977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178911#comment-17178911
 ] 

Hudson commented on MNG-6977:
-

Build succeeded in Jenkins: Maven » Maven TLP » maven » master #15

See 
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/15/

> Use hyphen when creating builder threads (names)
> 
>
> Key: MNG-6977
> URL: https://issues.apache.org/jira/browse/MNG-6977
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0
>
>
> We currently create bulder threads as {{BuilderThread %d}}. This is bit 
> problematic because you cannot properly {{grep}} or {{cut}} through this due 
> to the while space. Most other use a hyphen and is then a snap to analyze 
> debug output.
>  
> Proposal is to use {{BuilderThread-%d}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1833) Classes of dependency not found since 3.0.0-M5

[Tibor Digana (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178906#comment-17178906
 ] 

Tibor Digana commented on SUREFIRE-1833:


[~Jeroen Hoek]
I think you have run into the same issue with SUREFIRE-1809. A temporal 
workaround is _false_.

> Classes of dependency not found since 3.0.0-M5
> --
>
> Key: SUREFIRE-1833
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1833
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
> Environment: java -version:
> openjdk version "11.0.8" 2020-07-14
> OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.8+10)
> OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.8+10, mixed mode)
> mvn -version:
> Apache Maven 3.6.0
> Maven home: /usr/share/maven
> Java version: 11.0.8, vendor: AdoptOpenJDK, runtime: […]/java/11.0.8.hs-adpt
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.13.0-21-generic", arch: "amd64", family: "unix"
> Operating system is Ubuntu Linux 18.04.
>Reporter: Jeroen Hoek
>Priority: Major
>
> During an upgrade of the surefire and failsafe plugins in my projects I ran 
> into an issue with failsafe {{3.0.0-M5}} not seeing the classes from a Maven 
> dependency on a module from the same project.
> I have created a minimal reproduction case that contains two modules, one 
> containing a single class and a unit-test, and one containing a single 
> integration test:
> [https://github.com/LableOrg/failsafe-classnotfound-reproduction]
> After cloning the repo, these three commands can be used to build the project 
> and run the tests. The Maven profiles set the version of surefire/failsafe 
> used:
> ||Version||Command||Result||
> |{{2.22.2}}|{{mvn clean install -Dold2}}|works|
> |{{3.0.0-M4}}|{{mvn clean install -Dold3}}|works|
> |{{3.0.0-M5}}|{{mvn clean install}}|*fails*|
> The result for me is:
> {code:java}
> java.lang.NoClassDefFoundError: 
> org/example/sample/failsafe300m5/SampleException
> {code}
> Is there something I am doing wrong, or is this a bug introduced in 
> {{3.0.0-M5}}?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MINVOKER-268) invoker:run skips invocation when the sources are unmodified

[Hudson (Jira)]

[ 
https://issues.apache.org/jira/browse/MINVOKER-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178897#comment-17178897
 ] 

Hudson commented on MINVOKER-268:
-

Build succeeded in Jenkins: Maven » Maven TLP » maven-invoker-plugin » master 
#10

See 
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-invoker-plugin/job/master/10/

> invoker:run skips invocation when the sources are unmodified  
> --
>
> Key: MINVOKER-268
> URL: https://issues.apache.org/jira/browse/MINVOKER-268
> Project: Maven Invoker Plugin
>  Issue Type: New Feature
>Reporter: Robert James Oxspring
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.2.2
>
>
> As a user I want to skip repeated invocations of invoker:run goal when the 
> sources have not changed so that incremental builds when the test projects 
> are unmodified.
> My team have been using the Maven Invoker Plugin’s run goal to package some 
> sample test projects during pre-integration-test which we then use during 
> integration tests. We’re not using it to test a maven plugin but it doesn’t 
> feel like we’re straying very far from the intended use case. The approach 
> works well but as we add more test projects the time taken for each increases 
> as each test project is rebuilt, even when the test project hasn’t changed at 
> all. People making changes to unrelated parts of the codebase don’t want to 
> rebuild these test samples for every unrelated change they make.
> As a result I’m thinking of adding an “updateOnly” (default false) 
> configuration option modelled after the Maven Assembly Plugin’s, linked 
> below, such that we only rebuild each project if a source file is newer than 
> one of the target files. 
> [https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#updateOnly]
>  
> Given an invoker:run goal with updateOnly=false (default existing case)
> When the goal is repeated
> Then the invocation is repeated
>  
> Given an invoker:run goal with updateOnly=true (new case)
> When the goal is repeated
> Then the invocation is skipped



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (SUREFIRE-1833) Classes of dependency not found since 3.0.0-M5

[Jeroen Hoek (Jira)]

Jeroen Hoek created SUREFIRE-1833:
-

 Summary: Classes of dependency not found since 3.0.0-M5
 Key: SUREFIRE-1833
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1833
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Failsafe Plugin
Affects Versions: 3.0.0-M5
 Environment: java -version:

openjdk version "11.0.8" 2020-07-14
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.8+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.8+10, mixed mode)

mvn -version:

Apache Maven 3.6.0
Maven home: /usr/share/maven
Java version: 11.0.8, vendor: AdoptOpenJDK, runtime: […]/java/11.0.8.hs-adpt
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.13.0-21-generic", arch: "amd64", family: "unix"

Operating system is Ubuntu Linux 18.04.
Reporter: Jeroen Hoek


During an upgrade of the surefire and failsafe plugins in my projects I ran 
into an issue with failsafe {{3.0.0-M5}} not seeing the classes from a Maven 
dependency on a module from the same project.

I have created a minimal reproduction case that contains two modules, one 
containing a single class and a unit-test, and one containing a single 
integration test:

[https://github.com/LableOrg/failsafe-classnotfound-reproduction]

After cloning the repo, these three commands can be used to build the project 
and run the tests. The Maven profiles set the version of surefire/failsafe used:
||Version||Command||Result||
|{{2.22.2}}|{{mvn clean install -Dold2}}|works|
|{{3.0.0-M4}}|{{mvn clean install -Dold3}}|works|
|{{3.0.0-M5}}|{{mvn clean install}}|*fails*|

The result for me is:
{code:java}
java.lang.NoClassDefFoundError: org/example/sample/failsafe300m5/SampleException
{code}

Is there something I am doing wrong, or is this a bug introduced in 
{{3.0.0-M5}}?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-5315) Artifact resolution sporadically fails in parallel builds

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-5315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178878#comment-17178878
 ] 

Michael Osipov commented on MNG-5315:
-

MRESOLVER-131 introduces a fully new, multi-JVM concurrent approach based on 
Redis. Try it from here: 
https://github.com/apache/maven-resolver/tree/MRESOLVER-131. Read it from here: 
https://maven.apache.org/resolver-archives/resolver-LATEST/maven-resolver-synccontext-redisson/index.html

> Artifact resolution sporadically fails in parallel builds
> -
>
> Key: MNG-5315
> URL: https://issues.apache.org/jira/browse/MNG-5315
> Project: Maven
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 3.0.4
>Reporter: Ivan Dubrov
>Priority: Minor
> Attachments: MNG-5315-3.0.x.patch, MNG-5315-3.1.2-SNAPSHOT.patch
>
>
> Artifact resolution can fail during the parallel build if it was downloaded 
> during the same session.
> Scenario:
> 1) Delete the whole Maven local repository.
> 2) Run build "mvn compile -T1.5C"
> 3) Build fails (see log extracts below)
> 4) If I run build again, it succeeds.
> It seems like the problem is due to two thread trying to resolve same 
> artifact concurrently. This problem never happens once I have all 
> dependencies cached in the local repository.
> Extracts from the log output:
> {noformat}Downloading: 
> http://nexus/content/repositories/thirdparty/com/googlecode/guava-osgi/guava-osgi/11.0.0/guava-osgi-11.0.0.jar
>  12444/13937 KB ...
> ...
> [DEBUG] Skipped remote update check for commons-cli:commons-cli:jar:1.2, 
> already updated during this session.
> [DEBUG] Skipped remote update check for 
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0, already updated during this 
> session.
> [DEBUG] Skipped remote update check for org.slf4j:slf4j-api:jar:1.6.4, 
> already updated during this session.
> [DEBUG] Skipped remote update check for org.slf4j:slf4j-jdk14:jar:1.6.4, 
> already updated during this session.
> ...
> [ERROR] Failed to execute goal on project util: Could not resolve 
> dependencies for project com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The 
> following artifacts could not be resolved: commons-cli:commons-cli:jar:1.2, 
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0, 
> org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to 
> find commons-cli:commons-cli:jar:1.2 in 
> http://nexus/content/repositories/thirdparty was cached in the local 
> repository, resolution will not be reattempted until the update interval of 
> gw.thirdparty has elapsed or updates are forced -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal on project util: Could not resolve dependencies for project 
> com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The following artifacts could not 
> be resolved: commons-cli:commons-cli:jar:1.2, 
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0, 
> org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to 
> find commons-cli:commons-cli:jar:1.2 in 
> http://nexus/content/repositories/thirdparty was cached in the local 
> repository, resolution will not be reattempted until the update interval of 
> gw.thirdparty has elapsed or updates are forced
> at 
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210)
> at 
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at 
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
> at 
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 

[jira] [Commented] (MNG-6604) Intermittent failures while downloading GAVs from Nexus

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178881#comment-17178881
 ] 

Michael Osipov commented on MNG-6604:
-

MRESOLVER-131 introduces a fully new, multi-JVM concurrent approach based on 
Redis. Try it from here: 
https://github.com/apache/maven-resolver/tree/MRESOLVER-131. Read it from here: 
https://maven.apache.org/resolver-archives/resolver-LATEST/maven-resolver-synccontext-redisson/index.html

> Intermittent failures while downloading GAVs from Nexus
> ---
>
> Key: MNG-6604
> URL: https://issues.apache.org/jira/browse/MNG-6604
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line, Toolchains
>Affects Versions: 3.6.0
> Environment: Nexus OSS 3.15.2-01
> Docker 18.09.2 on Ubuntu 18.04.2 LTS
> Gitlab runner 11.8.0
>Reporter: Ivan Rizzante
>Priority: Major
> Attachments: docker-env.txt, log.txt
>
>
> Hello
> we're running maven 3.6.0 builds in a docker container and we use Nexus OSS 
> configured as proxy for Maven Central.
> While running our builds using Gitlab CI, we're experiencing intermittent 
> build failures because Maven cannot find artifacts in Nexus which we verified 
> they are actually available.
> Error example below:
> {noformat}
> 20744 [main] [ERROR] Failed to execute goal on project EcotransitWSClient: 
> Could not resolve dependencies for project 
> it.sdb.ecotransit:EcotransitWSClient:jar:7.0.1-SNAPSHOT: Could not transfer 
> artifact commons-beanutils:commons-beanutils:jar:1.9.3 from/to nexus 
> (http://maven-repo.sdb.it:8081/repository/maven-public/): 
> /builds/sdb/webportal/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar.part
>  (No such file or directory) -> [Help 1]
> {noformat}
> I attached the full maven build log and our Docker env settings.
> We tried disabling the keep alive and also disabling the connection pooling 
> but nothing seems to fix the issue.
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-wagon] michael-o commented on pull request #72: [MNG-6975] Wagon-HTTP, set content-type when determinable from file extension

[GitBox]

michael-o commented on pull request #72:
URL: https://github.com/apache/maven-wagon/pull/72#issuecomment-674779314


   There are still statements which have not been responded to. Until then this 
PR will remain open.



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.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Updated] (MNG-6977) Use hyphen when creating builder threads (names)

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-6977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MNG-6977:

Fix Version/s: (was: 3.7.0-candidate)
   3.7.0

> Use hyphen when creating builder threads (names)
> 
>
> Key: MNG-6977
> URL: https://issues.apache.org/jira/browse/MNG-6977
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0
>
>
> We currently create bulder threads as {{BuilderThread %d}}. This is bit 
> problematic because you cannot properly {{grep}} or {{cut}} through this due 
> to the while space. Most other use a hyphen and is then a snap to analyze 
> debug output.
>  
> Proposal is to use {{BuilderThread-%d}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (MNG-6977) Use hyphen when creating builder threads (names)

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-6977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed MNG-6977.
---
Resolution: Fixed

Fixed with 
[9120d86573bd6fe3a3548d87331087fe610d90b8|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=9120d86573bd6fe3a3548d87331087fe610d90b8].

> Use hyphen when creating builder threads (names)
> 
>
> Key: MNG-6977
> URL: https://issues.apache.org/jira/browse/MNG-6977
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0-candidate
>
>
> We currently create bulder threads as {{BuilderThread %d}}. This is bit 
> problematic because you cannot properly {{grep}} or {{cut}} through this due 
> to the while space. Most other use a hyphen and is then a snap to analyze 
> debug output.
>  
> Proposal is to use {{BuilderThread-%d}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MNG-6977) Use hyphen when creating builder threads (names)

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/MNG-6977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MNG-6977:

Description: 
We currently create bulder threads as {{BuilderThread %d}}. This is bit 
problematic because you cannot properly {{grep}} or {{cut}} through this due to 
the while space. Most other use a hyphen and is then a snap to analyze debug 
output.

 

Proposal is to use {{BuilderThread-%d}}.

  was:
We currently create bulder threads as {{Builder Thread %d}}. This is bit 
problematic because you cannot properly {{grep}} or {{cut}} through this due to 
the while space. Most other use a hyphen and is then a snap to analyze debug 
output.

 

Proposal is to use {{BuilderThread-%d}}.


> Use hyphen when creating builder threads (names)
> 
>
> Key: MNG-6977
> URL: https://issues.apache.org/jira/browse/MNG-6977
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0-candidate
>
>
> We currently create bulder threads as {{BuilderThread %d}}. This is bit 
> problematic because you cannot properly {{grep}} or {{cut}} through this due 
> to the while space. Most other use a hyphen and is then a snap to analyze 
> debug output.
>  
> Proposal is to use {{BuilderThread-%d}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (MINVOKER-268) invoker:run skips invocation when the sources are unmodified

[Olivier Lamy (Jira)]

 [ 
https://issues.apache.org/jira/browse/MINVOKER-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy closed MINVOKER-268.
-
Resolution: Fixed

pr merged.

Thanks!

> invoker:run skips invocation when the sources are unmodified  
> --
>
> Key: MINVOKER-268
> URL: https://issues.apache.org/jira/browse/MINVOKER-268
> Project: Maven Invoker Plugin
>  Issue Type: New Feature
>Reporter: Robert James Oxspring
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.2.2
>
>
> As a user I want to skip repeated invocations of invoker:run goal when the 
> sources have not changed so that incremental builds when the test projects 
> are unmodified.
> My team have been using the Maven Invoker Plugin’s run goal to package some 
> sample test projects during pre-integration-test which we then use during 
> integration tests. We’re not using it to test a maven plugin but it doesn’t 
> feel like we’re straying very far from the intended use case. The approach 
> works well but as we add more test projects the time taken for each increases 
> as each test project is rebuilt, even when the test project hasn’t changed at 
> all. People making changes to unrelated parts of the codebase don’t want to 
> rebuild these test samples for every unrelated change they make.
> As a result I’m thinking of adding an “updateOnly” (default false) 
> configuration option modelled after the Maven Assembly Plugin’s, linked 
> below, such that we only rebuild each project if a source file is newer than 
> one of the target files. 
> [https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#updateOnly]
>  
> Given an invoker:run goal with updateOnly=false (default existing case)
> When the goal is repeated
> Then the invocation is repeated
>  
> Given an invoker:run goal with updateOnly=true (new case)
> When the goal is repeated
> Then the invocation is skipped



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MINVOKER-268) invoker:run skips invocation when the sources are unmodified

[Olivier Lamy (Jira)]

 [ 
https://issues.apache.org/jira/browse/MINVOKER-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy updated MINVOKER-268:
--
Fix Version/s: 3.2.2

> invoker:run skips invocation when the sources are unmodified  
> --
>
> Key: MINVOKER-268
> URL: https://issues.apache.org/jira/browse/MINVOKER-268
> Project: Maven Invoker Plugin
>  Issue Type: New Feature
>Reporter: Robert James Oxspring
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.2.2
>
>
> As a user I want to skip repeated invocations of invoker:run goal when the 
> sources have not changed so that incremental builds when the test projects 
> are unmodified.
> My team have been using the Maven Invoker Plugin’s run goal to package some 
> sample test projects during pre-integration-test which we then use during 
> integration tests. We’re not using it to test a maven plugin but it doesn’t 
> feel like we’re straying very far from the intended use case. The approach 
> works well but as we add more test projects the time taken for each increases 
> as each test project is rebuilt, even when the test project hasn’t changed at 
> all. People making changes to unrelated parts of the codebase don’t want to 
> rebuild these test samples for every unrelated change they make.
> As a result I’m thinking of adding an “updateOnly” (default false) 
> configuration option modelled after the Maven Assembly Plugin’s, linked 
> below, such that we only rebuild each project if a source file is newer than 
> one of the target files. 
> [https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#updateOnly]
>  
> Given an invoker:run goal with updateOnly=false (default existing case)
> When the goal is repeated
> Then the invocation is repeated
>  
> Given an invoker:run goal with updateOnly=true (new case)
> When the goal is repeated
> Then the invocation is skipped



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-invoker-plugin] olamy merged pull request #24: [MINVOKER-268] - Introduce updateOnly parameter to AbstractInvokerMojo

[GitBox]

olamy merged pull request #24:
URL: https://github.com/apache/maven-invoker-plugin/pull/24


   



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.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Assigned] (MINVOKER-268) invoker:run skips invocation when the sources are unmodified

[Olivier Lamy (Jira)]

 [ 
https://issues.apache.org/jira/browse/MINVOKER-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Olivier Lamy reassigned MINVOKER-268:
-

Assignee: Olivier Lamy

> invoker:run skips invocation when the sources are unmodified  
> --
>
> Key: MINVOKER-268
> URL: https://issues.apache.org/jira/browse/MINVOKER-268
> Project: Maven Invoker Plugin
>  Issue Type: New Feature
>Reporter: Robert James Oxspring
>Assignee: Olivier Lamy
>Priority: Major
>
> As a user I want to skip repeated invocations of invoker:run goal when the 
> sources have not changed so that incremental builds when the test projects 
> are unmodified.
> My team have been using the Maven Invoker Plugin’s run goal to package some 
> sample test projects during pre-integration-test which we then use during 
> integration tests. We’re not using it to test a maven plugin but it doesn’t 
> feel like we’re straying very far from the intended use case. The approach 
> works well but as we add more test projects the time taken for each increases 
> as each test project is rebuilt, even when the test project hasn’t changed at 
> all. People making changes to unrelated parts of the codebase don’t want to 
> rebuild these test samples for every unrelated change they make.
> As a result I’m thinking of adding an “updateOnly” (default false) 
> configuration option modelled after the Maven Assembly Plugin’s, linked 
> below, such that we only rebuild each project if a source file is newer than 
> one of the target files. 
> [https://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#updateOnly]
>  
> Given an invoker:run goal with updateOnly=false (default existing case)
> When the goal is repeated
> Then the invocation is repeated
>  
> Given an invoker:run goal with updateOnly=true (new case)
> When the goal is repeated
> Then the invocation is skipped



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MRESOLVER-132) Remove synchronization in TrackingFileManager

[Michael Osipov (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178790#comment-17178790
 ] 

Michael Osipov commented on MRESOLVER-132:
--

[~elharo], please have a look at this.

> Remove synchronization in TrackingFileManager
> -
>
> Key: MRESOLVER-132
> URL: https://issues.apache.org/jira/browse/MRESOLVER-132
> Project: Maven Resolver
>  Issue Type: Task
>  Components: resolver
>Affects Versions: 1.5.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Attachments: call-hierarchy-read.png, call-hierarchy-write.png
>
>
> Motivation: The {{TrackingFileManager}} is package private, thus never used 
> externally. It uses the interned string reperesentation of the canonical path 
> and file locking. We all know that file locking in a single JVM are 
> pointless, it will lead to race conditions. This is why the locking is 
> multistage. Single JVM and file locks for multi JVM. The interesting part is 
> that if you look up the call stack of  {{TrackingFileManager#read(File)}} and 
> {{TrackingFileManager#update(File, Map)}} you'll see that all 
> of them are wrapped in a {{SyncContext}} which already adds locks for them. I 
> don't understand why this is done here. If outer lock works, I see no need to 
> lock again somewhere deeper. I am also keen to say that this kind of 
> synchronization can be completely removed if you have a decent 
> {{SyncContextFactory}} implementation.
>  I am inclined to override the {{TrackingFileManager}} with MRESOLVER-130 and 
> MRESOLVER-131 for obvious reasons.
> In short: the locking (synchronization) has to happen in a sync context, not 
> here. Especially because the canonicalization of paths adds an unnecessary 
> performance penalty.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [maven-resolver] michael-o commented on pull request #22: Introduce caching for tracking files.

[GitBox]

michael-o commented on pull request #22:
URL: https://github.com/apache/maven-resolver/pull/22#issuecomment-674707053


   See: https://issues.apache.org/jira/browse/MRESOLVER-132



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.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [maven-resolver] michael-o commented on pull request #29: [MRESOLVER-68] Add cache around TrackingFileManager.getLock(File)

[GitBox]

michael-o commented on pull request #29:
URL: https://github.com/apache/maven-resolver/pull/29#issuecomment-674706994


   See: https://issues.apache.org/jira/browse/MRESOLVER-132



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.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Updated] (MRESOLVER-132) Remove synchronization in TrackingFileManager

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/MRESOLVER-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MRESOLVER-132:
-
Attachment: call-hierarchy-write.png

> Remove synchronization in TrackingFileManager
> -
>
> Key: MRESOLVER-132
> URL: https://issues.apache.org/jira/browse/MRESOLVER-132
> Project: Maven Resolver
>  Issue Type: Task
>  Components: resolver
>Affects Versions: 1.5.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Attachments: call-hierarchy-read.png, call-hierarchy-write.png
>
>
> Motivation: The {{TrackingFileManager}} is package private, thus never used 
> externally. It uses the interned string reperesentation of the canonical path 
> and file locking. We all know that file locking in a single JVM are 
> pointless, it will lead to race conditions. This is why the locking is 
> multistage. Single JVM and file locks for multi JVM. The interesting part is 
> that if you look up the call stack of  {{TrackingFileManager#read(File)}} and 
> {{TrackingFileManager#update(File, Map)}} you'll see that all 
> of them are wrapped in a {{SyncContext}} which already adds locks for them. I 
> don't understand why this is done here. If outer lock works, I see no need to 
> lock again somewhere deeper. I am also keen to say that this kind of 
> synchronization can be completely removed if you have a decent 
> {{SyncContextFactory}} implementation.
>  I am inclined to override the {{TrackingFileManager}} with MRESOLVER-130 and 
> MRESOLVER-131 for obvious reasons.
> In short: the locking (synchronization) has to happen in a sync context, not 
> here. Especially because the canonicalization of paths adds an unnecessary 
> performance penalty.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MRESOLVER-132) Remove synchronization in TrackingFileManager

[Michael Osipov (Jira)]

 [ 
https://issues.apache.org/jira/browse/MRESOLVER-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MRESOLVER-132:
-
Attachment: call-hierarchy-read.png

> Remove synchronization in TrackingFileManager
> -
>
> Key: MRESOLVER-132
> URL: https://issues.apache.org/jira/browse/MRESOLVER-132
> Project: Maven Resolver
>  Issue Type: Task
>  Components: resolver
>Affects Versions: 1.5.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Attachments: call-hierarchy-read.png
>
>
> Motivation: The {{TrackingFileManager}} is package private, thus never used 
> externally. It uses the interned string reperesentation of the canonical path 
> and file locking. We all know that file locking in a single JVM are 
> pointless, it will lead to race conditions. This is why the locking is 
> multistage. Single JVM and file locks for multi JVM. The interesting part is 
> that if you look up the call stack of  {{TrackingFileManager#read(File)}} and 
> {{TrackingFileManager#update(File, Map)}} you'll see that all 
> of them are wrapped in a {{SyncContext}} which already adds locks for them. I 
> don't understand why this is done here. If outer lock works, I see no need to 
> lock again somewhere deeper. I am also keen to say that this kind of 
> synchronization can be completely removed if you have a decent 
> {{SyncContextFactory}} implementation.
>  I am inclined to override the {{TrackingFileManager}} with MRESOLVER-130 and 
> MRESOLVER-131 for obvious reasons.
> In short: the locking (synchronization) has to happen in a sync context, not 
> here. Especially because the canonicalization of paths adds an unnecessary 
> performance penalty.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)