RE: [VOTE] Release Apache Maven EAR Plugin version 3.1.0
+1 Thank you. Regards, Marat Abrarov. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Resolver version 1.6.0
Alright, thanks! I know what to do now. Will work on this next week and let you know. Thank you very much again for your support! Am 2020-09-27 um 00:14 schrieb Dan Tran: without -Daether.checksums.algorithms=SHA1,MD5, very slow -D On Sat, Sep 26, 2020 at 3:11 PM Michael Osipov wrote: Awesome, what about with the fix, but with the default list of hashing algos (SHA-512, SHA-256, SHA-1, MD5) in place? Am 2020-09-27 um 00:07 schrieb Dan Tran: it works using the provided commitID + -Daether.checksums.algorithms=SHA1,MD5 -D On Sat, Sep 26, 2020 at 2:25 PM Michael Osipov wrote: Gosh, I assumed so. Every SHA family is horrible in terms of performance. This is going to be a huge problem for the community, I would prefer Blake2 or Blake3 for this. Anyway, I think this is the root cause, actually the fix: https://github.com/apache/maven-resolver/commit/a9e0ca8307e532fc30591a47d7d96e27fa647465 Can you please try with the property set (-Daether.checksums.algorithms=SHA1,MD5)? Thrilled to see your results. If this works, please remove the property and see whether the patch along with SHA-2 on URLs changes the performance as well. Michael Am 2020-09-26 um 21:45 schrieb Dan Tran: I am able to pin down the problematic commit: https://github.com/apache/maven-resolver/commit/8e8a4f1944a0589397e36a5dd049ec765424e863 Adding -Daether.checksums.algorithms=SHA1,MD5 to maven command line does not help Sorry about the delay -D On Wed, Sep 16, 2020 at 1:57 AM Michael Osipov wrote: Your logging config is sound, so appearently nothing is wrong. You see no trace because DefaultSyncContextFactory is empty and there is nothing to trace. Something else is the cause. Can you git bisect 1.4.2 and 1.6.0 to find the offending commit? Otherwise I have no idea and we are searching the needle in the haystack. The only commits which come to my mind are: * https://github.com/apache/maven-resolver/commit/8e8a4f1944a0589397e36a5dd049ec765424e863?w=1 You can disable/restore this one by using: -Daether.checksums.algorithms=SHA1,MD5 (previous behavior) * https://github.com/apache/maven-resolver/commit/3c2a5141c9d393a45bdee873e6aa2c9c275b7b58?w=1 But still this wouldn't make any sense. Looking forward for some findings. Am 2020-09-15 um 22:45 schrieb Dan Tran: this is my log config org.slf4j.simpleLogger.defaultLogLevel=info org.slf4j.simpleLogger.showDateTime=true org.slf4j.simpleLogger.showThreadName=true org.slf4j.simpleLogger.showShortLogName=true org.slf4j.simpleLogger.showLogName=false org.slf4j.simpleLogger.logFile=System.out org.slf4j.simpleLogger.cacheOutputStream=true org.slf4j.simpleLogger.levelInBrackets=true org.slf4j.simpleLogger.log.Sisu=info org.slf4j.simpleLogger.warnLevelString=WARNING # MNG-6181: mvn -X also prints all debug logging from HttpClient # Be aware that the shaded packages are used # org.apache.http -> org.apache.maven.wagon.providers.http.httpclient org.slf4j.simpleLogger.log.org.apache.maven.wagon.providers.http.httpclient=off org.slf4j.simpleLogger.log.org.apache.maven.wagon.providers.http.httpclient.wire=off org.slf4j.simpleLogger.log.org.eclipse.aether.synccontext=trace no sign of [TRACE] On Tue, Sep 15, 2020 at 1:30 PM Dan Tran wrote: Maven 3.7.0 with Resolver 1.4.2 - no issue Maven 3.7.0 with Resolver 1.6.0 + trace. I cant get any indication about 4626 [main] [TRACE] GlobalSyncContextFactory$GlobalSyncContext - Acquiring global... 35318 [main] [TRACE] GlobalSyncContextFactory$GlobalSyncContext - Releasing global... Very strange -D On Tue, Sep 15, 2020 at 4:37 AM Michael Osipov wrote: There is no new feature active in 1.6.0 in this regard. Here is the diff: https://github.com/apache/maven-resolver/compare/maven-resolver-1.4.2...maven-resolver-1.6.0?w=1 Since I do not have access to your project, can you please try the following: * Maven 3.7.0 with Resolver 1.4.2 * Maven 3.6.3 with Resolver 1.6.0 * If 3.7.0/1.4.2 does not affect the build, do a git bisect with 1.4.2 and 1.6.0. Alternatively, provide the log output as configured here: https://maven.apache.org/resolver-archives/resolver-LATEST/maven-resolver-synccontext-global/index.html#Debugging In 1.6.0 there is even less synchronization because the TrackingFileManager does not lock anything anymore. I will hold off vote completion until I get some analyzable data from you. Michael Am 2020-09-15 um 11:49 schrieb Dan Tran: I build maven 3.7.0 + MResolve 1.6.0. The same slow build observed at my 300+ modules ( 60min versus 5min) -1 ( non-binding) from me. there must and option to disable this new feature -D On Mon, Sep 14, 2020 at 4:33 AM Michael Osipov < micha...@apache.org wrote: Am 2020-09-14 um 10:57 schrieb Dan Tran: sorry about the fast finger, my test shows a huge increase in build time for large builds. Possible to disable this feature? This cannot be. It has been superceded by
Re: [VOTE] Release Maven Resolver version 1.6.0
without -Daether.checksums.algorithms=SHA1,MD5, very slow -D On Sat, Sep 26, 2020 at 3:11 PM Michael Osipov wrote: > Awesome, what about with the fix, but with the default list of hashing > algos (SHA-512, SHA-256, SHA-1, MD5) in place? > > Am 2020-09-27 um 00:07 schrieb Dan Tran: > > it works using the provided commitID + > >-Daether.checksums.algorithms=SHA1,MD5 > > > > -D > > > > On Sat, Sep 26, 2020 at 2:25 PM Michael Osipov > wrote: > > > >> Gosh, I assumed so. Every SHA family is horrible in terms of > >> performance. This is going to be a huge problem for the community, I > >> would prefer Blake2 or Blake3 for this. > >> > >> Anyway, I think this is the root cause, actually the fix: > >> > >> > https://github.com/apache/maven-resolver/commit/a9e0ca8307e532fc30591a47d7d96e27fa647465 > >> > >> Can you please try with the property set > >> (-Daether.checksums.algorithms=SHA1,MD5)? > >> > >> Thrilled to see your results. If this works, please remove the property > >> and see whether the patch along with SHA-2 on URLs changes the > >> performance as well. > >> > >> Michael > >> > >> Am 2020-09-26 um 21:45 schrieb Dan Tran: > >>> I am able to pin down the problematic commit: > >>> > >> > https://github.com/apache/maven-resolver/commit/8e8a4f1944a0589397e36a5dd049ec765424e863 > >>> > >>> Adding -Daether.checksums.algorithms=SHA1,MD5 to maven command line > does > >>> not help > >>> > >>> Sorry about the delay > >>> > >>> -D > >>> > >>> On Wed, Sep 16, 2020 at 1:57 AM Michael Osipov > >> wrote: > >>> > Your logging config is sound, so appearently nothing is wrong. > You see no trace because DefaultSyncContextFactory is empty and there > is > nothing to trace. Something else is the cause. > > Can you git bisect 1.4.2 and 1.6.0 to find the offending commit? > Otherwise I have no idea and we are searching the needle in the > >> haystack. > > The only commits which come to my mind are: > * > > > >> > https://github.com/apache/maven-resolver/commit/8e8a4f1944a0589397e36a5dd049ec765424e863?w=1 > > You can disable/restore this one by using: > -Daether.checksums.algorithms=SHA1,MD5 (previous behavior) > > * > > > >> > https://github.com/apache/maven-resolver/commit/3c2a5141c9d393a45bdee873e6aa2c9c275b7b58?w=1 > > But still this wouldn't make any sense. > > Looking forward for some findings. > > Am 2020-09-15 um 22:45 schrieb Dan Tran: > > this is my log config > > > > org.slf4j.simpleLogger.defaultLogLevel=info > > org.slf4j.simpleLogger.showDateTime=true > > org.slf4j.simpleLogger.showThreadName=true > > org.slf4j.simpleLogger.showShortLogName=true > > org.slf4j.simpleLogger.showLogName=false > > org.slf4j.simpleLogger.logFile=System.out > > org.slf4j.simpleLogger.cacheOutputStream=true > > org.slf4j.simpleLogger.levelInBrackets=true > > org.slf4j.simpleLogger.log.Sisu=info > > org.slf4j.simpleLogger.warnLevelString=WARNING > > > > # MNG-6181: mvn -X also prints all debug logging from HttpClient > > # Be aware that the shaded packages are used > > # org.apache.http -> org.apache.maven.wagon.providers.http.httpclient > > > > >> > org.slf4j.simpleLogger.log.org.apache.maven.wagon.providers.http.httpclient=off > > > > >> > org.slf4j.simpleLogger.log.org.apache.maven.wagon.providers.http.httpclient.wire=off > > > > org.slf4j.simpleLogger.log.org.eclipse.aether.synccontext=trace > > > > > > no sign of [TRACE] > > > > > > > > On Tue, Sep 15, 2020 at 1:30 PM Dan Tran wrote: > > > >> Maven 3.7.0 with Resolver 1.4.2 - no issue > >> > >> Maven 3.7.0 with Resolver 1.6.0 + trace. I cant get any indication > >> about > >> > >> 4626 [main] [TRACE] GlobalSyncContextFactory$GlobalSyncContext - > Acquiring global... > >> 35318 [main] [TRACE] GlobalSyncContextFactory$GlobalSyncContext - > Releasing global... > >> > >> > >> Very strange > >> > >> -D > >> > >> On Tue, Sep 15, 2020 at 4:37 AM Michael Osipov > > >> wrote: > >> > >>> There is no new feature active in 1.6.0 in this regard. > >>> Here is the diff: > >>> > >>> > > >> > https://github.com/apache/maven-resolver/compare/maven-resolver-1.4.2...maven-resolver-1.6.0?w=1 > >>> > >>> Since I do not have access to your project, can you please try the > >>> following: > >>> * Maven 3.7.0 with Resolver 1.4.2 > >>> * Maven 3.6.3 with Resolver 1.6.0 > >>> * If 3.7.0/1.4.2 does not affect the build, do a git bisect with > >> 1.4.2 > >>> and 1.6.0. > >>> > >>> Alternatively, provide the log output as configured here: > >>> > >>> > > >> > https://maven.apache.org/resolver-archives/resolver-LATEST/maven-resolver-synccontext-global/index.html#Debugging > >>> > >>> In 1.6.0 there is
Re: [VOTE] Release Maven Resolver version 1.6.0
Awesome, what about with the fix, but with the default list of hashing
algos (SHA-512, SHA-256, SHA-1, MD5) in place?
Am 2020-09-27 um 00:07 schrieb Dan Tran:
it works using the provided commitID +
-Daether.checksums.algorithms=SHA1,MD5
-D
On Sat, Sep 26, 2020 at 2:25 PM Michael Osipov wrote:
Gosh, I assumed so. Every SHA family is horrible in terms of
performance. This is going to be a huge problem for the community, I
would prefer Blake2 or Blake3 for this.
Anyway, I think this is the root cause, actually the fix:
https://github.com/apache/maven-resolver/commit/a9e0ca8307e532fc30591a47d7d96e27fa647465
Can you please try with the property set
(-Daether.checksums.algorithms=SHA1,MD5)?
Thrilled to see your results. If this works, please remove the property
and see whether the patch along with SHA-2 on URLs changes the
performance as well.
Michael
Am 2020-09-26 um 21:45 schrieb Dan Tran:
I am able to pin down the problematic commit:
https://github.com/apache/maven-resolver/commit/8e8a4f1944a0589397e36a5dd049ec765424e863
Adding -Daether.checksums.algorithms=SHA1,MD5 to maven command line does
not help
Sorry about the delay
-D
On Wed, Sep 16, 2020 at 1:57 AM Michael Osipov
wrote:
Your logging config is sound, so appearently nothing is wrong.
You see no trace because DefaultSyncContextFactory is empty and there is
nothing to trace. Something else is the cause.
Can you git bisect 1.4.2 and 1.6.0 to find the offending commit?
Otherwise I have no idea and we are searching the needle in the
haystack.
The only commits which come to my mind are:
*
https://github.com/apache/maven-resolver/commit/8e8a4f1944a0589397e36a5dd049ec765424e863?w=1
You can disable/restore this one by using:
-Daether.checksums.algorithms=SHA1,MD5 (previous behavior)
*
https://github.com/apache/maven-resolver/commit/3c2a5141c9d393a45bdee873e6aa2c9c275b7b58?w=1
But still this wouldn't make any sense.
Looking forward for some findings.
Am 2020-09-15 um 22:45 schrieb Dan Tran:
this is my log config
org.slf4j.simpleLogger.defaultLogLevel=info
org.slf4j.simpleLogger.showDateTime=true
org.slf4j.simpleLogger.showThreadName=true
org.slf4j.simpleLogger.showShortLogName=true
org.slf4j.simpleLogger.showLogName=false
org.slf4j.simpleLogger.logFile=System.out
org.slf4j.simpleLogger.cacheOutputStream=true
org.slf4j.simpleLogger.levelInBrackets=true
org.slf4j.simpleLogger.log.Sisu=info
org.slf4j.simpleLogger.warnLevelString=WARNING
# MNG-6181: mvn -X also prints all debug logging from HttpClient
# Be aware that the shaded packages are used
# org.apache.http -> org.apache.maven.wagon.providers.http.httpclient
org.slf4j.simpleLogger.log.org.apache.maven.wagon.providers.http.httpclient=off
org.slf4j.simpleLogger.log.org.apache.maven.wagon.providers.http.httpclient.wire=off
org.slf4j.simpleLogger.log.org.eclipse.aether.synccontext=trace
no sign of [TRACE]
On Tue, Sep 15, 2020 at 1:30 PM Dan Tran wrote:
Maven 3.7.0 with Resolver 1.4.2 - no issue
Maven 3.7.0 with Resolver 1.6.0 + trace. I cant get any indication
about
4626 [main] [TRACE] GlobalSyncContextFactory$GlobalSyncContext -
Acquiring global...
35318 [main] [TRACE] GlobalSyncContextFactory$GlobalSyncContext -
Releasing global...
Very strange
-D
On Tue, Sep 15, 2020 at 4:37 AM Michael Osipov
wrote:
There is no new feature active in 1.6.0 in this regard.
Here is the diff:
https://github.com/apache/maven-resolver/compare/maven-resolver-1.4.2...maven-resolver-1.6.0?w=1
Since I do not have access to your project, can you please try the
following:
* Maven 3.7.0 with Resolver 1.4.2
* Maven 3.6.3 with Resolver 1.6.0
* If 3.7.0/1.4.2 does not affect the build, do a git bisect with
1.4.2
and 1.6.0.
Alternatively, provide the log output as configured here:
https://maven.apache.org/resolver-archives/resolver-LATEST/maven-resolver-synccontext-global/index.html#Debugging
In 1.6.0 there is even less synchronization because the
TrackingFileManager does not lock anything anymore.
I will hold off vote completion until I get some analyzable data from
you.
Michael
Am 2020-09-15 um 11:49 schrieb Dan Tran:
I build maven 3.7.0 + MResolve 1.6.0. The same slow build observed
at
my
300+ modules ( 60min versus 5min)
-1 ( non-binding) from me. there must and option to disable this
new
feature
-D
On Mon, Sep 14, 2020 at 4:33 AM Michael Osipov
wrote:
Am 2020-09-14 um 10:57 schrieb Dan Tran:
sorry about the fast finger, my test shows a huge increase in
build
time
for large builds. Possible to disable this feature?
This cannot be. It has been superceded by
https://issues.apache.org/jira/browse/MRESOLVER-130. The
GlobalSyncContextFactory have been moved to a separate module, the
original behavior has been restored. I.e., this feature is not
enabled
by default.
Are you certain that you don't have leftovers in
${maven.home}/lib/ext?
On Mon, Sep 14, 2020 at 1:49 AM Dan Tran
wrote:
possible to
Re: [VOTE] Release Maven Resolver version 1.6.0
it works using the provided commitID + -Daether.checksums.algorithms=SHA1,MD5 -D On Sat, Sep 26, 2020 at 2:25 PM Michael Osipov wrote: > Gosh, I assumed so. Every SHA family is horrible in terms of > performance. This is going to be a huge problem for the community, I > would prefer Blake2 or Blake3 for this. > > Anyway, I think this is the root cause, actually the fix: > > https://github.com/apache/maven-resolver/commit/a9e0ca8307e532fc30591a47d7d96e27fa647465 > > Can you please try with the property set > (-Daether.checksums.algorithms=SHA1,MD5)? > > Thrilled to see your results. If this works, please remove the property > and see whether the patch along with SHA-2 on URLs changes the > performance as well. > > Michael > > Am 2020-09-26 um 21:45 schrieb Dan Tran: > > I am able to pin down the problematic commit: > > > https://github.com/apache/maven-resolver/commit/8e8a4f1944a0589397e36a5dd049ec765424e863 > > > > Adding -Daether.checksums.algorithms=SHA1,MD5 to maven command line does > > not help > > > > Sorry about the delay > > > > -D > > > > On Wed, Sep 16, 2020 at 1:57 AM Michael Osipov > wrote: > > > >> Your logging config is sound, so appearently nothing is wrong. > >> You see no trace because DefaultSyncContextFactory is empty and there is > >> nothing to trace. Something else is the cause. > >> > >> Can you git bisect 1.4.2 and 1.6.0 to find the offending commit? > >> Otherwise I have no idea and we are searching the needle in the > haystack. > >> > >> The only commits which come to my mind are: > >> * > >> > >> > https://github.com/apache/maven-resolver/commit/8e8a4f1944a0589397e36a5dd049ec765424e863?w=1 > >> > >> You can disable/restore this one by using: > >> -Daether.checksums.algorithms=SHA1,MD5 (previous behavior) > >> > >> * > >> > >> > https://github.com/apache/maven-resolver/commit/3c2a5141c9d393a45bdee873e6aa2c9c275b7b58?w=1 > >> > >> But still this wouldn't make any sense. > >> > >> Looking forward for some findings. > >> > >> Am 2020-09-15 um 22:45 schrieb Dan Tran: > >>> this is my log config > >>> > >>> org.slf4j.simpleLogger.defaultLogLevel=info > >>> org.slf4j.simpleLogger.showDateTime=true > >>> org.slf4j.simpleLogger.showThreadName=true > >>> org.slf4j.simpleLogger.showShortLogName=true > >>> org.slf4j.simpleLogger.showLogName=false > >>> org.slf4j.simpleLogger.logFile=System.out > >>> org.slf4j.simpleLogger.cacheOutputStream=true > >>> org.slf4j.simpleLogger.levelInBrackets=true > >>> org.slf4j.simpleLogger.log.Sisu=info > >>> org.slf4j.simpleLogger.warnLevelString=WARNING > >>> > >>> # MNG-6181: mvn -X also prints all debug logging from HttpClient > >>> # Be aware that the shaded packages are used > >>> # org.apache.http -> org.apache.maven.wagon.providers.http.httpclient > >>> > >> > org.slf4j.simpleLogger.log.org.apache.maven.wagon.providers.http.httpclient=off > >>> > >> > org.slf4j.simpleLogger.log.org.apache.maven.wagon.providers.http.httpclient.wire=off > >>> > >>> org.slf4j.simpleLogger.log.org.eclipse.aether.synccontext=trace > >>> > >>> > >>> no sign of [TRACE] > >>> > >>> > >>> > >>> On Tue, Sep 15, 2020 at 1:30 PM Dan Tran wrote: > >>> > Maven 3.7.0 with Resolver 1.4.2 - no issue > > Maven 3.7.0 with Resolver 1.6.0 + trace. I cant get any indication > about > > 4626 [main] [TRACE] GlobalSyncContextFactory$GlobalSyncContext - > >> Acquiring global... > 35318 [main] [TRACE] GlobalSyncContextFactory$GlobalSyncContext - > >> Releasing global... > > > Very strange > > -D > > On Tue, Sep 15, 2020 at 4:37 AM Michael Osipov > wrote: > > > There is no new feature active in 1.6.0 in this regard. > > Here is the diff: > > > > > >> > https://github.com/apache/maven-resolver/compare/maven-resolver-1.4.2...maven-resolver-1.6.0?w=1 > > > > Since I do not have access to your project, can you please try the > > following: > > * Maven 3.7.0 with Resolver 1.4.2 > > * Maven 3.6.3 with Resolver 1.6.0 > > * If 3.7.0/1.4.2 does not affect the build, do a git bisect with > 1.4.2 > > and 1.6.0. > > > > Alternatively, provide the log output as configured here: > > > > > >> > https://maven.apache.org/resolver-archives/resolver-LATEST/maven-resolver-synccontext-global/index.html#Debugging > > > > In 1.6.0 there is even less synchronization because the > > TrackingFileManager does not lock anything anymore. > > > > I will hold off vote completion until I get some analyzable data from > >> you. > > > > Michael > > > > > > Am 2020-09-15 um 11:49 schrieb Dan Tran: > >> I build maven 3.7.0 + MResolve 1.6.0. The same slow build observed > at > > my > >> 300+ modules ( 60min versus 5min) > >> > >> -1 ( non-binding) from me. there must and option to disable this > new > >> feature > >> > >> -D > >> > >> On Mon, Sep 14, 2020 at 4:33 AM Michael Osipov > > >
Re: [VOTE] Release Maven Resolver version 1.6.0
Gosh, I assumed so. Every SHA family is horrible in terms of
performance. This is going to be a huge problem for the community, I
would prefer Blake2 or Blake3 for this.
Anyway, I think this is the root cause, actually the fix:
https://github.com/apache/maven-resolver/commit/a9e0ca8307e532fc30591a47d7d96e27fa647465
Can you please try with the property set
(-Daether.checksums.algorithms=SHA1,MD5)?
Thrilled to see your results. If this works, please remove the property
and see whether the patch along with SHA-2 on URLs changes the
performance as well.
Michael
Am 2020-09-26 um 21:45 schrieb Dan Tran:
I am able to pin down the problematic commit:
https://github.com/apache/maven-resolver/commit/8e8a4f1944a0589397e36a5dd049ec765424e863
Adding -Daether.checksums.algorithms=SHA1,MD5 to maven command line does
not help
Sorry about the delay
-D
On Wed, Sep 16, 2020 at 1:57 AM Michael Osipov wrote:
Your logging config is sound, so appearently nothing is wrong.
You see no trace because DefaultSyncContextFactory is empty and there is
nothing to trace. Something else is the cause.
Can you git bisect 1.4.2 and 1.6.0 to find the offending commit?
Otherwise I have no idea and we are searching the needle in the haystack.
The only commits which come to my mind are:
*
https://github.com/apache/maven-resolver/commit/8e8a4f1944a0589397e36a5dd049ec765424e863?w=1
You can disable/restore this one by using:
-Daether.checksums.algorithms=SHA1,MD5 (previous behavior)
*
https://github.com/apache/maven-resolver/commit/3c2a5141c9d393a45bdee873e6aa2c9c275b7b58?w=1
But still this wouldn't make any sense.
Looking forward for some findings.
Am 2020-09-15 um 22:45 schrieb Dan Tran:
this is my log config
org.slf4j.simpleLogger.defaultLogLevel=info
org.slf4j.simpleLogger.showDateTime=true
org.slf4j.simpleLogger.showThreadName=true
org.slf4j.simpleLogger.showShortLogName=true
org.slf4j.simpleLogger.showLogName=false
org.slf4j.simpleLogger.logFile=System.out
org.slf4j.simpleLogger.cacheOutputStream=true
org.slf4j.simpleLogger.levelInBrackets=true
org.slf4j.simpleLogger.log.Sisu=info
org.slf4j.simpleLogger.warnLevelString=WARNING
# MNG-6181: mvn -X also prints all debug logging from HttpClient
# Be aware that the shaded packages are used
# org.apache.http -> org.apache.maven.wagon.providers.http.httpclient
org.slf4j.simpleLogger.log.org.apache.maven.wagon.providers.http.httpclient=off
org.slf4j.simpleLogger.log.org.apache.maven.wagon.providers.http.httpclient.wire=off
org.slf4j.simpleLogger.log.org.eclipse.aether.synccontext=trace
no sign of [TRACE]
On Tue, Sep 15, 2020 at 1:30 PM Dan Tran wrote:
Maven 3.7.0 with Resolver 1.4.2 - no issue
Maven 3.7.0 with Resolver 1.6.0 + trace. I cant get any indication
about
4626 [main] [TRACE] GlobalSyncContextFactory$GlobalSyncContext -
Acquiring global...
35318 [main] [TRACE] GlobalSyncContextFactory$GlobalSyncContext -
Releasing global...
Very strange
-D
On Tue, Sep 15, 2020 at 4:37 AM Michael Osipov
wrote:
There is no new feature active in 1.6.0 in this regard.
Here is the diff:
https://github.com/apache/maven-resolver/compare/maven-resolver-1.4.2...maven-resolver-1.6.0?w=1
Since I do not have access to your project, can you please try the
following:
* Maven 3.7.0 with Resolver 1.4.2
* Maven 3.6.3 with Resolver 1.6.0
* If 3.7.0/1.4.2 does not affect the build, do a git bisect with 1.4.2
and 1.6.0.
Alternatively, provide the log output as configured here:
https://maven.apache.org/resolver-archives/resolver-LATEST/maven-resolver-synccontext-global/index.html#Debugging
In 1.6.0 there is even less synchronization because the
TrackingFileManager does not lock anything anymore.
I will hold off vote completion until I get some analyzable data from
you.
Michael
Am 2020-09-15 um 11:49 schrieb Dan Tran:
I build maven 3.7.0 + MResolve 1.6.0. The same slow build observed at
my
300+ modules ( 60min versus 5min)
-1 ( non-binding) from me. there must and option to disable this new
feature
-D
On Mon, Sep 14, 2020 at 4:33 AM Michael Osipov
wrote:
Am 2020-09-14 um 10:57 schrieb Dan Tran:
sorry about the fast finger, my test shows a huge increase in build
time
for large builds. Possible to disable this feature?
This cannot be. It has been superceded by
https://issues.apache.org/jira/browse/MRESOLVER-130. The
GlobalSyncContextFactory have been moved to a separate module, the
original behavior has been restored. I.e., this feature is not
enabled
by default.
Are you certain that you don't have leftovers in
${maven.home}/lib/ext?
On Mon, Sep 14, 2020 at 1:49 AM Dan Tran wrote:
possible to disable this feature
https://issues.apache.org/jira/browse/MRESOLVER-123 ?
On Mon, Sep 14, 2020 at 12:06 AM Romain Manni-Bucau <
rmannibu...@gmail.com>
wrote:
+1, tested in java 8 with mvn 3.6.3.
Romain Manni-Bucau
@rmannibucau | Blog
[VOTE] Release Apache Maven EAR Plugin version 3.1.0
Hi, We solved 8 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317422=12346511=Text There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%20MEAR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-1606/ https://repository.apache.org/content/repositories/maven-1606/org/apache/maven/plugins/maven-ear-plugin/3.1.0/maven-ear-plugin-3.1.0-source-release.zip Source release checksum(s): maven-ear-plugin-3.1.0-source-release.zip sha512: 8bef3e02d0c4f73e82b3a2b156154aa00949839f5b8b9514df3c64df75082c8adb3c6f6b8060d72ba6aaabbaae38ad49eb9d5bb81e4485e2e2b3319cc4d217d1 Staging site: https://maven.apache.org/plugins-archives/maven-ear-plugin-LATEST/ Guide to testing staged releases: https://maven.apache.org/guides/development/guide-testing-releases.html Vote open for at least 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Resolver version 1.6.0
I am able to pin down the problematic commit:
https://github.com/apache/maven-resolver/commit/8e8a4f1944a0589397e36a5dd049ec765424e863
Adding -Daether.checksums.algorithms=SHA1,MD5 to maven command line does
not help
Sorry about the delay
-D
On Wed, Sep 16, 2020 at 1:57 AM Michael Osipov wrote:
> Your logging config is sound, so appearently nothing is wrong.
> You see no trace because DefaultSyncContextFactory is empty and there is
> nothing to trace. Something else is the cause.
>
> Can you git bisect 1.4.2 and 1.6.0 to find the offending commit?
> Otherwise I have no idea and we are searching the needle in the haystack.
>
> The only commits which come to my mind are:
> *
>
> https://github.com/apache/maven-resolver/commit/8e8a4f1944a0589397e36a5dd049ec765424e863?w=1
>
> You can disable/restore this one by using:
> -Daether.checksums.algorithms=SHA1,MD5 (previous behavior)
>
> *
>
> https://github.com/apache/maven-resolver/commit/3c2a5141c9d393a45bdee873e6aa2c9c275b7b58?w=1
>
> But still this wouldn't make any sense.
>
> Looking forward for some findings.
>
> Am 2020-09-15 um 22:45 schrieb Dan Tran:
> > this is my log config
> >
> > org.slf4j.simpleLogger.defaultLogLevel=info
> > org.slf4j.simpleLogger.showDateTime=true
> > org.slf4j.simpleLogger.showThreadName=true
> > org.slf4j.simpleLogger.showShortLogName=true
> > org.slf4j.simpleLogger.showLogName=false
> > org.slf4j.simpleLogger.logFile=System.out
> > org.slf4j.simpleLogger.cacheOutputStream=true
> > org.slf4j.simpleLogger.levelInBrackets=true
> > org.slf4j.simpleLogger.log.Sisu=info
> > org.slf4j.simpleLogger.warnLevelString=WARNING
> >
> > # MNG-6181: mvn -X also prints all debug logging from HttpClient
> > # Be aware that the shaded packages are used
> > # org.apache.http -> org.apache.maven.wagon.providers.http.httpclient
> >
> org.slf4j.simpleLogger.log.org.apache.maven.wagon.providers.http.httpclient=off
> >
> org.slf4j.simpleLogger.log.org.apache.maven.wagon.providers.http.httpclient.wire=off
> >
> > org.slf4j.simpleLogger.log.org.eclipse.aether.synccontext=trace
> >
> >
> > no sign of [TRACE]
> >
> >
> >
> > On Tue, Sep 15, 2020 at 1:30 PM Dan Tran wrote:
> >
> >> Maven 3.7.0 with Resolver 1.4.2 - no issue
> >>
> >> Maven 3.7.0 with Resolver 1.6.0 + trace. I cant get any indication
> >> about
> >>
> >> 4626 [main] [TRACE] GlobalSyncContextFactory$GlobalSyncContext -
> Acquiring global...
> >> 35318 [main] [TRACE] GlobalSyncContextFactory$GlobalSyncContext -
> Releasing global...
> >>
> >>
> >> Very strange
> >>
> >> -D
> >>
> >> On Tue, Sep 15, 2020 at 4:37 AM Michael Osipov
> >> wrote:
> >>
> >>> There is no new feature active in 1.6.0 in this regard.
> >>> Here is the diff:
> >>>
> >>>
> https://github.com/apache/maven-resolver/compare/maven-resolver-1.4.2...maven-resolver-1.6.0?w=1
> >>>
> >>> Since I do not have access to your project, can you please try the
> >>> following:
> >>> * Maven 3.7.0 with Resolver 1.4.2
> >>> * Maven 3.6.3 with Resolver 1.6.0
> >>> * If 3.7.0/1.4.2 does not affect the build, do a git bisect with 1.4.2
> >>> and 1.6.0.
> >>>
> >>> Alternatively, provide the log output as configured here:
> >>>
> >>>
> https://maven.apache.org/resolver-archives/resolver-LATEST/maven-resolver-synccontext-global/index.html#Debugging
> >>>
> >>> In 1.6.0 there is even less synchronization because the
> >>> TrackingFileManager does not lock anything anymore.
> >>>
> >>> I will hold off vote completion until I get some analyzable data from
> you.
> >>>
> >>> Michael
> >>>
> >>>
> >>> Am 2020-09-15 um 11:49 schrieb Dan Tran:
> I build maven 3.7.0 + MResolve 1.6.0. The same slow build observed at
> >>> my
> 300+ modules ( 60min versus 5min)
>
> -1 ( non-binding) from me. there must and option to disable this new
> feature
>
> -D
>
> On Mon, Sep 14, 2020 at 4:33 AM Michael Osipov
> >>> wrote:
>
> > Am 2020-09-14 um 10:57 schrieb Dan Tran:
> >> sorry about the fast finger, my test shows a huge increase in build
> >>> time
> >> for large builds. Possible to disable this feature?
> >
> > This cannot be. It has been superceded by
> > https://issues.apache.org/jira/browse/MRESOLVER-130. The
> > GlobalSyncContextFactory have been moved to a separate module, the
> > original behavior has been restored. I.e., this feature is not
> enabled
> > by default.
> >
> > Are you certain that you don't have leftovers in
> ${maven.home}/lib/ext?
> >
> >> On Mon, Sep 14, 2020 at 1:49 AM Dan Tran wrote:
> >>
> >>> possible to disable this feature
> >>> https://issues.apache.org/jira/browse/MRESOLVER-123 ?
> >>>
> >>> On Mon, Sep 14, 2020 at 12:06 AM Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> >>> wrote:
> >>>
> +1, tested in java 8 with mvn 3.6.3.
>
> Romain Manni-Bucau
> @rmannibucau | Blog
>
Re: Maven Sign Plugin
Am 2020-09-20 um 20:38 schrieb Robert Scholte: With the next release of Maven the current maven-gpg-plugin will become useless. With the build//consumer pom, the local pom will be different compared to the uploaded pom. However, the maven-gpg-plugin now uses the pom.xml of the local project. (btw, the plugin uses the gpg commandline with a bunch of arguments. The stdio is used for passing the passphrase, you cannot stream the file via commandline) In Maven 3.6.x changes have been made to support InputStream next to File. This way we don't have to create a backdoor of writing a temporary file, which is likely to cause issues with very creative plugin/extension writers. Instead we should do in memory signing. It would make sense to introduce a new plugin, and during a discussion with the PMC the idea of maven-sign-plugin was proposed (a much better alternative campared to maven-gpg2-plugin) Dennis Lundberg started a POC based on Apache Common OpenGPG, however, it is still in the sandbox[1] Olivier Lamy already discovered that signing doesn't work with the current Maven 3.7.0-SNAPSHOT. Before we can even start thinking of an alpha-release, this issue must be fixed, because signing is a critical step for sharing artifacts. I'm still struggling with MNG-6957, but in parallel a few should be able implement this. Anybody willing to make this work? The entry interface of OpenPGP leaks abstraction and obviously retained in incubator for a good reason... - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven Sign Plugin
Ok, I don't want to reinvent the wheels, so How to reach handle to project artifacts list, especially project pom after transformation in plugin code? Some plugin examples, point which component should I use to achieve this will be great. pt., 25 wrz 2020 o 17:05 Robert Scholte napisał(a): > There no plugin yet, but I suggest to start with a branch under > https://github.com/apache/maven-studies before making an official new > repository. > > Let me quote 2 points mentioned by Stephen Connolly, which we still need > to address: > > - If we switch to bouncycastle based, we will now own the key storage. > This is both good and bad. > * People who have their keys stored in gpg2 will have a “fun time” > extracting them... or else we will have to do the dance of extracting them > ourselves. > * If we “own” the key storage, publishing keys to a key registry and > generating keys may become our problem from the user’s perspective. > * One of the biggest complaints about publishing on central has been the > difficulty of gpg signing. New users will likely thank us if we make it > easier. > > - PGP functionality provider security issues become our problem. Before, > users could independently upgrade the gpg CLI tooling to work past security > issues (causing it’s own issues as CLI options changed from gpg1 to gpg2). > With this plugin, the pgp provider version will be baked into the pom. How > will users be able to assure their security team that signatures have been > made in the version without a security issue? > > thanks, > Robert > On 25-9-2020 15:35:01, Slawomir Jaranowski wrote: > Hi > > On the weekend I will have some spare time, so I can do something about it > .. > > My questions: > - are there git repository, jira project for new plugin > - does anybody working on it now - what is progress > - if you want to use Apache Common OpenGPG, I think should be refreshed > first - is there git repo for it > > > czw., 24 wrz 2020 o 18:57 Robert Scholte napisał(a): > > > Thanks for the offer. > > Signing is very delicate process, so I appreciate the extra help. > > > > thanks, > > Robert > > On 21-9-2020 09:14:54, Slawomir Jaranowski wrote: > > Hi > > > > I have some experience in case of verifying pgp signatures using Bouncy > > Castle during work on my pgpverify-maven-plugin. > > So If you would, I can try to help with the sign plugin. > > > > Let me know if you are interested. > > > > niedz., 20 wrz 2020 o 20:38 Robert Scholte > > napisał(a): > > > > > With the next release of Maven the current maven-gpg-plugin will become > > > useless. > > > With the build//consumer pom, the local pom will be different compared > to > > > the uploaded pom. > > > However, the maven-gpg-plugin now uses the pom.xml of the local > project. > > > (btw, the plugin uses the gpg commandline with a bunch of arguments. > The > > > stdio is used for passing the passphrase, you cannot stream the file > via > > > commandline) > > > > > > In Maven 3.6.x changes have been made to support InputStream next to > > File. > > > This way we don't have to create a backdoor of writing a temporary > file, > > > which is likely to cause issues with very creative plugin/extension > > > writers. Instead we should do in memory signing. > > > > > > It would make sense to introduce a new plugin, and during a discussion > > > with the PMC the idea of maven-sign-plugin was proposed (a much better > > > alternative campared to maven-gpg2-plugin) > > > > > > Dennis Lundberg started a POC based on Apache Common OpenGPG, however, > it > > > is still in the sandbox[1] > > > > > > Olivier Lamy already discovered that signing doesn't work with the > > current > > > Maven 3.7.0-SNAPSHOT. > > > Before we can even start thinking of an alpha-release, this issue must > be > > > fixed, because signing is a critical step for sharing artifacts. > > > > > > I'm still struggling with MNG-6957, but in parallel a few should be > able > > > implement this. > > > > > > Anybody willing to make this work? > > > > > > thanks, > > > Robert > > > > > > [1] http://commons.apache.org/sandbox/commons-openpgp/ [ > > > http://commons.apache.org/sandbox/commons-openpgp/] > > > > > > > > > -- > > Sławomir Jaranowski > > > > > -- > Sławomir Jaranowski > -- Sławomir Jaranowski
[GitHub] [maven-site] hboutemy merged pull request #201: Added CycloneDX maven plugin
hboutemy merged pull request #201: URL: https://github.com/apache/maven-site/pull/201 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
