[GitHub] [maven-indexer] dependabot[bot] commented on pull request #111: Bump version.spring from 5.3.6 to 5.3.8
dependabot[bot] commented on pull request #111: URL: https://github.com/apache/maven-indexer/pull/111#issuecomment-880373560 Superseded by #118. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-indexer] dependabot[bot] opened a new pull request #118: Bump version.spring from 5.3.6 to 5.3.9
dependabot[bot] opened a new pull request #118:
URL: https://github.com/apache/maven-indexer/pull/118
Bumps `version.spring` from 5.3.6 to 5.3.9.
Updates `spring-beans` from 5.3.6 to 5.3.9
Release notes
Sourced from https://github.com/spring-projects/spring-framework/releases;>spring-beans's
releases.
v5.3.9
:star: New Features
Configure CommonsMultipartResolver to support specific HTTP methods https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27161;>#27161
Allow BeanDefinitionBuilder to set an instance supplier with a
ResolvableType https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27160;>#27160
Reason of @ResponseStatus on handler method is not resolved
by MessageSource https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27156;>#27156
ResourceHandlerRegistry#getHandlerMapping should initialize handler once
in outer loop https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27153;>#27153
Set synthetic flag using BeanDefinitionBuilder https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27141;>#27141
BeanCreationException error message should always include declaring
class of constructor (or factory method) https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27139;>#27139
Improve Jetty 10 check in JettyClientHttpResponse https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27136;>#27136
Jetty10RequestUpgradeStrategy use an old jetty 9 class HandshakeRFC6455
https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27121;>#27121
ClassNotFoundException using Jetty 10 and its reactive client https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27112;>#27112
Use StringBuilder.append(char) where possible https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27098;>#27098
Consider wss and https for secure flag in
Forwarded header checks https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27097;>#27097
SynchronossPartHttpMessageReader should only create temp directory when
needed https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27092;>#27092
Implement equals, hashCode, toString in BeanMethod and *Metadata
types https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27076;>#27076
Remove logging dependency in BeanUtils https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27070;>#27070
Exclude sealed interfaces from auto-proxying (for JDK 17 compatibility)
https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27027;>#27027
Blockhound error when running with transaction with a
TransactionOperator https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/26955;>#26955
Configure StandardServletMultipartResolver to only support
multipart/form-data https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/26826;>#26826
Add a way to set executeExistingDelayedTasksAfterShutdown from
ThreadPoolTaskScheduler https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/26719;>#26719
Apply dynamic changes in ThreadPoolTaskExecutor before setting local
value https://github-redirect.dependabot.com/spring-projects/spring-framework/pull/26700;>#26700
:beetle: Bug Fixes
JettyHttpHandlerAdapter is not aware of Server[Request|Response]Wrapper
https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27146;>#27146
{*path} pattern (CaptureTheRestPathElement) includes undocumented
leading slash in @PathVariable path https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27132;>#27132
NoSuchMethodError when invoke JettyWebSocketSession.getRemoteAddress in
jetty 10 https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27120;>#27120
CronExpression is still broken on spring-context-5.3.8 https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27117;>#27117
SimpleMethodMetadataReadingVisitor.Source.toString() omits separator for
method arguments https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27095;>#27095
DefaultPathSegment allows shared empty parameters map to be mutated https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27064;>#27064
AOP auto-proxying with proxyTargetClass=true and introduction advice
does not work for JDK proxy targets https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/27044;>#27044
ServletRequestDataBinder assumes Standard servlet multipart handling https://github-redirect.dependabot.com/spring-projects/spring-framework/issues/26999;>#26999
[GitHub] [maven-indexer] dependabot[bot] closed pull request #111: Bump version.spring from 5.3.6 to 5.3.8
dependabot[bot] closed pull request #111: URL: https://github.com/apache/maven-indexer/pull/111 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MINVOKER-281) Require Java 8
[ https://issues.apache.org/jira/browse/MINVOKER-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MINVOKER-281: -- Fix Version/s: 3.2.3 > Require Java 8 > -- > > Key: MINVOKER-281 > URL: https://issues.apache.org/jira/browse/MINVOKER-281 > Project: Maven Invoker Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.2.3 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MINVOKER-281) Require Java 8
Sylwester Lachiewicz created MINVOKER-281: - Summary: Require Java 8 Key: MINVOKER-281 URL: https://issues.apache.org/jira/browse/MINVOKER-281 Project: Maven Invoker Plugin Issue Type: Dependency upgrade Reporter: Sylwester Lachiewicz -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MINVOKER-280) Update java version in GitHub Action
[
https://issues.apache.org/jira/browse/MINVOKER-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380875#comment-17380875
]
Hudson commented on MINVOKER-280:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven-invoker-plugin » master
#54
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-invoker-plugin/job/master/54/
> Update java version in GitHub Action
>
>
> Key: MINVOKER-280
> URL: https://issues.apache.org/jira/browse/MINVOKER-280
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Reporter: Slawomir Jaranowski
>Assignee: Sylwester Lachiewicz
>Priority: Major
>
> Currently GitHub Action use:
> {code}
> matrix:
> os: [ubuntu-20.04, windows-latest, macOS-latest]
> java: [7, 8, 11, 15, 16-ea]
> {code}
> 16 - is released,
> now 17 is in early access
> 15 - is out of support
> version 7 - probably should be removed - MPOM-262
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MINVOKER-280) Update java version in GitHub Action
[
https://issues.apache.org/jira/browse/MINVOKER-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz closed MINVOKER-280.
-
Resolution: Fixed
> Update java version in GitHub Action
>
>
> Key: MINVOKER-280
> URL: https://issues.apache.org/jira/browse/MINVOKER-280
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Reporter: Slawomir Jaranowski
>Assignee: Sylwester Lachiewicz
>Priority: Major
>
> Currently GitHub Action use:
> {code}
> matrix:
> os: [ubuntu-20.04, windows-latest, macOS-latest]
> java: [7, 8, 11, 15, 16-ea]
> {code}
> 16 - is released,
> now 17 is in early access
> 15 - is out of support
> version 7 - probably should be removed - MPOM-262
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MINVOKER-280) Update java version in GitHub Action
[
https://issues.apache.org/jira/browse/MINVOKER-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz reassigned MINVOKER-280:
-
Assignee: Sylwester Lachiewicz
> Update java version in GitHub Action
>
>
> Key: MINVOKER-280
> URL: https://issues.apache.org/jira/browse/MINVOKER-280
> Project: Maven Invoker Plugin
> Issue Type: Improvement
>Reporter: Slawomir Jaranowski
>Assignee: Sylwester Lachiewicz
>Priority: Major
>
> Currently GitHub Action use:
> {code}
> matrix:
> os: [ubuntu-20.04, windows-latest, macOS-latest]
> java: [7, 8, 11, 15, 16-ea]
> {code}
> 16 - is released,
> now 17 is in early access
> 15 - is out of support
> version 7 - probably should be removed - MPOM-262
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-invoker-plugin] dependabot[bot] closed pull request #45: Bump actions/setup-java from 1 to 2.1.0
dependabot[bot] closed pull request #45: URL: https://github.com/apache/maven-invoker-plugin/pull/45 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-invoker-plugin] dependabot[bot] commented on pull request #45: Bump actions/setup-java from 1 to 2.1.0
dependabot[bot] commented on pull request #45: URL: https://github.com/apache/maven-invoker-plugin/pull/45#issuecomment-880227621 Looks like actions/setup-java is up-to-date now, so this is no longer needed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-invoker-plugin] slachiewicz merged pull request #51: [MINVOKER-280] Update java version in GitHub Action
slachiewicz merged pull request #51: URL: https://github.com/apache/maven-invoker-plugin/pull/51 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-invoker-plugin] slawekjaranowski opened a new pull request #51: [MINVOKER-280] Update java version in GitHub Action
slawekjaranowski opened a new pull request #51: URL: https://github.com/apache/maven-invoker-plugin/pull/51 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6241) Load -Dstyle.color from system properties also
[
https://issues.apache.org/jira/browse/MNG-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380851#comment-17380851
]
Thorsten Glaser commented on MNG-6241:
--
I don’t need to, I’m the maintainer of a shell and see it works.
But wouldn’t you want to add {{${NO_COLOR+-B}}} instead?
> Load -Dstyle.color from system properties also
> --
>
> Key: MNG-6241
> URL: https://issues.apache.org/jira/browse/MNG-6241
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Thorsten Glaser
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Coloured output does not look very nice in a Jenkins logfile *and* breaks
> some plugins we use, therefore I wish to disable it programmatically.
> However, looking at the source, I find it can only be disabled by passing the
> command-line options -B or -l, but not from settings.xml or via MAVEN_OPTS in
> the environment.
> I’ve worked around this by using dpkg-divert to move the mvn binary away and
> placing this…
> {{{
> # cat /usr/share/maven/bin/mvn
> #!/bin/mksh-static
> exec /usr/share/maven/bin/mvn.dpkg-dist -B "$@"
> }}}
> … in its stead, but that’s creepy at best. Please implement a setting,
> ideally for settings.xml *and* MAVEN_OPTS, to disable colour.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6241) Load -Dstyle.color from system properties also
[
https://issues.apache.org/jira/browse/MNG-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380836#comment-17380836
]
Michael Osipov commented on MNG-6241:
-
Please modify the following snippet and see whether this works for you:
{noformat}
exec "$JAVACMD" \
$MAVEN_OPTS \
$MAVEN_DEBUG_OPTS \
-classpath "${LAUNCHER_JAR}" \
$MAVENHOME_CONFIG
"-Dmaven.multiModuleProjectDirectory=${MAVEN_PROJECTBASEDIR}" \
$MAVEN_LAUNCHER "$@"
{noformat}
to
{noformat}
exec "$JAVACMD" \
$MAVEN_OPTS \
$MAVEN_DEBUG_OPTS \
-classpath "${LAUNCHER_JAR}" \
$MAVENHOME_CONFIG
"-Dmaven.multiModuleProjectDirectory=${MAVEN_PROJECTBASEDIR}" \
$MAVEN_LAUNCHER $MAVEN_ARGS "$@"
{noformat}
> Load -Dstyle.color from system properties also
> --
>
> Key: MNG-6241
> URL: https://issues.apache.org/jira/browse/MNG-6241
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Thorsten Glaser
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Coloured output does not look very nice in a Jenkins logfile *and* breaks
> some plugins we use, therefore I wish to disable it programmatically.
> However, looking at the source, I find it can only be disabled by passing the
> command-line options -B or -l, but not from settings.xml or via MAVEN_OPTS in
> the environment.
> I’ve worked around this by using dpkg-divert to move the mvn binary away and
> placing this…
> {{{
> # cat /usr/share/maven/bin/mvn
> #!/bin/mksh-static
> exec /usr/share/maven/bin/mvn.dpkg-dist -B "$@"
> }}}
> … in its stead, but that’s creepy at best. Please implement a setting,
> ideally for settings.xml *and* MAVEN_OPTS, to disable colour.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6241) Load -Dstyle.color from system properties also
[
https://issues.apache.org/jira/browse/MNG-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380821#comment-17380821
]
Thorsten Glaser commented on MNG-6241:
--
Exactly.
> Load -Dstyle.color from system properties also
> --
>
> Key: MNG-6241
> URL: https://issues.apache.org/jira/browse/MNG-6241
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Thorsten Glaser
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Coloured output does not look very nice in a Jenkins logfile *and* breaks
> some plugins we use, therefore I wish to disable it programmatically.
> However, looking at the source, I find it can only be disabled by passing the
> command-line options -B or -l, but not from settings.xml or via MAVEN_OPTS in
> the environment.
> I’ve worked around this by using dpkg-divert to move the mvn binary away and
> placing this…
> {{{
> # cat /usr/share/maven/bin/mvn
> #!/bin/mksh-static
> exec /usr/share/maven/bin/mvn.dpkg-dist -B "$@"
> }}}
> … in its stead, but that’s creepy at best. Please implement a setting,
> ideally for settings.xml *and* MAVEN_OPTS, to disable colour.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ on Windows10 and MinTTY(Cygwin) console
[ https://issues.apache.org/jira/browse/SUREFIRE-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380817#comment-17380817 ] Tibor Digana commented on SUREFIRE-1631: >> why this complex magic with PINGs and the like? Because we do not use pipes only. We also use TCP connector which will be default. So , detecting an exception on System.in.read() would not help in the future. > Forked VM terminated without properly saying goodbye with AciveMQ on > Windows10 and MinTTY(Cygwin) console > - > > Key: SUREFIRE-1631 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1631 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1 >Reporter: Aaron Digulla >Assignee: Tibor Digana >Priority: Major > Attachments: cmd.PNG, cmd2.PNG, shurefire-shutdownhook-bug-0.0.1.zip > > > I'm seeing spurious "The forked VM terminated without properly saying > goodbye. VM crash or System.exit called?" messages when running unit tests in > a big multi-module project. > OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of > Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191. > I'm running Maven from the command line using MinTTY (Cygwin). > Things I tried which have no effect: > * Reboot / Cold boot (happens first thing on Monday morning when I come into > the office and turn on my PC). > * More free memory (happens when I only have a single window open). I have > 16GB of RAM. > * Different terminal. I tried CMD prompt and urxvt (Cygwin/X). > * Different versions of the Surefire plugin or Maven > * Different JDK 8 builds > Things that affect the bug: > * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log > * Redirecting all log output to a file using logback-test.xml > * Running Surefire with forkCount=0 > * Running a subset of the tests (-Dtest=...) > * Pending Windows updates (I think, not sure about this one). > Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never > seen it with redirecting log output (~ 10 builds). Redirecting sometimes > helps but not always. > One thing which I notice is that one of the tests creates an ActiveMQ broker > and uses a shutdown hook to stop it. So I created a small test project which > demonstrates that Surefire will sometimes cut off stdout. I think that > happens because the main process kills the child after a timeout (correct?). > So my guess would be that shutdown hooks can mess with the pipeline between > the surefire child VM and main Maven process. ActiveMQ might be worse since > it stops threads and execution pools (so the output comes slowly with a > couple of exceptions sprinkled in when one component loses connection because > another is shutting down). > But now, it gets weird. When the build succeeds, it takes about ~5 minutes to > run 1028 tests. The log is 25 MB. > When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) > and the log stops in the middle of a test but is also 25 MB. > Some of the time discrepancy is probably because writing to a file is faster > than printing on a terminal. The strange part is that the log file is about > the same size but 30% of the tests haven't run. Most tests log a lot, do I > would expect to see a difference of at least a few MB. The Maven part (which > contains escape sequences, etc). is just 60 KB. > Maybe the parent takes some part of the log output as "child terminated". > I'm running out of ideas what to try next. I think a way to log the > communication between parent and child would help. Also the parent should > terminate the child and then read stdout until EOF to we can see anything > that happens afterwards. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380807#comment-17380807
]
Naga Vijayapuram commented on MRESOLVER-153:
Ok, Will Do
> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.6.3, 1.7.0
>
> Attachments: gdmr.txt, gdmr.txt, image-2021-06-05-10-00-08-542.png,
> screenshot-1.png, with-global-sync-context.txt,
> without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}}
> after [this
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
> we face the following error:
> {code:java}
> [main] [INFO]
>
> [main] [INFO] BUILD FAILURE
> [main] [INFO]
>
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO]
>
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
> at java.util.Properties.loadConvert (Properties.java:675)
> at java.util.Properties.load0 (Properties.java:451)
> at java.util.Properties.load (Properties.java:404)
> at org.eclipse.aether.internal.impl.TrackingFileManager.read
> (TrackingFileManager.java:56)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read
> (DefaultUpdateCheckManager.java:511)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata
> (DefaultUpdateCheckManager.java:250)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
> (DefaultMetadataResolver.java:302)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata
> (DefaultMetadataResolver.java:181)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata
> (DefaultRepositorySystem.java:277)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
> (DefaultPluginVersionResolver.java:134)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve
> (DefaultPluginVersionResolver.java:97)
> at
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
> (LifecyclePluginResolver.java:67)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:104)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:86)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:92)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> It's not consistently failing and OSX based CI agents fail more often than
> Linux or Windows ones. After some investigations we saw that as part of
> https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has
> been removed on the {{TrackingFileManager}}
> ([https://github.com/apache/maven-resolver/pull/67]). This now leads to
> concurrent writes on the {{resolver-status.properties}} file in our tests and
> causes the error during the {{Properties#load()}} method
[jira] [Closed] (SUREFIRE-1928) NullPointerException at AbstractSurefireMojo.java:3300
[ https://issues.apache.org/jira/browse/SUREFIRE-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1928. -- Resolution: Not A Bug Related to https://github.com/apache/maven/pull/413 > NullPointerException at AbstractSurefireMojo.java:3300 > -- > > Key: SUREFIRE-1928 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1928 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 3.0.0-M5 > Environment: Windows, Java 8 >Reporter: Rich M >Assignee: Tibor Digana >Priority: Blocker > > I have following dependency in my pom: > > org.apache.maven.plugins > maven-surefire-plugin > 3.0.0-M5 > > > org.apache.maven.surefire > surefire-junit-platform > 3.0.0-M5 > > > > > Running the tests leads to NPE: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (default-test) > on project junit5: Execution default-test of goal org.ap > ache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed.: > NullPointerException -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test > (default-test) on proje > ct junit5: Execution default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed. > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:215) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:156) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:148) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:117) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:81) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build > (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute > (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:193) > at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:90) > at sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke (Method.java:508) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced > (Launcher.java:282) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch > (Launcher.java:225) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode > (Launcher.java:406) > at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347) > Caused by: org.apache.maven.plugin.PluginExecutionException: Execution > default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed. > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo > (DefaultBuildPluginManager.java:148) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:210) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:156) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:148) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:117) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:81) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build > (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute > (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:193) > at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:90) > at sun.reflect.DelegatingMethodAccessorImpl.invoke >
[jira] [Commented] (SUREFIRE-1928) NullPointerException at AbstractSurefireMojo.java:3300
[ https://issues.apache.org/jira/browse/SUREFIRE-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380799#comment-17380799 ] Tibor Digana commented on SUREFIRE-1928: There is nothing to do. We resolved the same issue in Jira and closed it because it is Maven bug. The problem is that Maven in parallel build (-T 1C) does this and it is not only in Surefire. It is also visible in Maven itself and the Maven crashes. You have to follow our mailing list in order to understand it https://lists.apache.org/thread.html/rb8b8a825a485a9b651fdc64771e92328d5cb828e6da481fe0d3ca11b%40%3Cdev.maven.apache.org%3E and our fixes https://github.com/apache/maven/pull/413 So if you want to know when the release will be fired, you should ask the team or force the tem on the @dev mailing list. > NullPointerException at AbstractSurefireMojo.java:3300 > -- > > Key: SUREFIRE-1928 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1928 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 3.0.0-M5 > Environment: Windows, Java 8 >Reporter: Rich M >Assignee: Tibor Digana >Priority: Blocker > > I have following dependency in my pom: > > org.apache.maven.plugins > maven-surefire-plugin > 3.0.0-M5 > > > org.apache.maven.surefire > surefire-junit-platform > 3.0.0-M5 > > > > > Running the tests leads to NPE: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (default-test) > on project junit5: Execution default-test of goal org.ap > ache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed.: > NullPointerException -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test > (default-test) on proje > ct junit5: Execution default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed. > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:215) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:156) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:148) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:117) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:81) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build > (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute > (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:193) > at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:90) > at sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke (Method.java:508) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced > (Launcher.java:282) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch > (Launcher.java:225) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode > (Launcher.java:406) > at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347) > Caused by: org.apache.maven.plugin.PluginExecutionException: Execution > default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed. > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo > (DefaultBuildPluginManager.java:148) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:210) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:156) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:148) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:117) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:81) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build > (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute > (LifecycleStarter.java:128) > at
[jira] [Created] (MINVOKER-280) Update java version in GitHub Action
Slawomir Jaranowski created MINVOKER-280:
Summary: Update java version in GitHub Action
Key: MINVOKER-280
URL: https://issues.apache.org/jira/browse/MINVOKER-280
Project: Maven Invoker Plugin
Issue Type: Improvement
Reporter: Slawomir Jaranowski
Currently GitHub Action use:
{code}
matrix:
os: [ubuntu-20.04, windows-latest, macOS-latest]
java: [7, 8, 11, 15, 16-ea]
{code}
16 - is released,
now 17 is in early access
15 - is out of support
version 7 - probably should be removed - MPOM-262
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-resolver] nvijayap commented on pull request #114: Update TrackingFileManager.java to help with MRESOLVER-153
nvijayap commented on pull request #114: URL: https://github.com/apache/maven-resolver/pull/114#issuecomment-880068465 . The purpose of this PR is to spot the file with `malformed encoding` . Issue is not resolved as end user still needs to go through the manual steps outlined in MRESOLVER-153 as workaround -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-shade-plugin] slachiewicz commented on pull request #106: Bump asmVersion from 9.1 to 9.2
slachiewicz commented on pull request #106: URL: https://github.com/apache/maven-shade-plugin/pull/106#issuecomment-880061283 @dependabot recreate -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380742#comment-17380742
]
Michael Osipov commented on MRESOLVER-153:
--
[~nv], create a new issue with proper debug logs, all args and the Maven and
Maven Resolver version you have used.
> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.6.3, 1.7.0
>
> Attachments: gdmr.txt, gdmr.txt, image-2021-06-05-10-00-08-542.png,
> screenshot-1.png, with-global-sync-context.txt,
> without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}}
> after [this
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
> we face the following error:
> {code:java}
> [main] [INFO]
>
> [main] [INFO] BUILD FAILURE
> [main] [INFO]
>
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO]
>
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
> at java.util.Properties.loadConvert (Properties.java:675)
> at java.util.Properties.load0 (Properties.java:451)
> at java.util.Properties.load (Properties.java:404)
> at org.eclipse.aether.internal.impl.TrackingFileManager.read
> (TrackingFileManager.java:56)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read
> (DefaultUpdateCheckManager.java:511)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata
> (DefaultUpdateCheckManager.java:250)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
> (DefaultMetadataResolver.java:302)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata
> (DefaultMetadataResolver.java:181)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata
> (DefaultRepositorySystem.java:277)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
> (DefaultPluginVersionResolver.java:134)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve
> (DefaultPluginVersionResolver.java:97)
> at
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
> (LifecyclePluginResolver.java:67)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:104)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:86)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:92)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> It's not consistently failing and OSX based CI agents fail more often than
> Linux or Windows ones. After some investigations we saw that as part of
> https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has
> been removed on the {{TrackingFileManager}}
> ([https://github.com/apache/maven-resolver/pull/67]). This now leads to
> concurrent writes on the
[jira] [Comment Edited] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380735#comment-17380735
]
Naga Vijayapuram edited comment on MRESOLVER-153 at 7/14/21, 4:52 PM:
--
[~David Hayes] - That is right. The sysprop helps in detecting the file that
has malformed encoding.
[~michael-o] - I am very sorry to say that this issue has reoccurred. Everyone
is referring to this and the comments are continuing. Do you think this issue
can be reopened or do you want me to open a new issue altogether?
was (Author: nv):
[~David Hayes] - That is right. The sysprop helps in detecting the file that
has malformed encoding.
[~michael-o] - I am very sorry to say that this issue has reoccurred. Everyone
is referring to this and the comments are continuing. Do you think this issue
can be reopened or do you want me open a new issue altogether?
> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.6.3, 1.7.0
>
> Attachments: gdmr.txt, gdmr.txt, image-2021-06-05-10-00-08-542.png,
> screenshot-1.png, with-global-sync-context.txt,
> without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}}
> after [this
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
> we face the following error:
> {code:java}
> [main] [INFO]
>
> [main] [INFO] BUILD FAILURE
> [main] [INFO]
>
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO]
>
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
> at java.util.Properties.loadConvert (Properties.java:675)
> at java.util.Properties.load0 (Properties.java:451)
> at java.util.Properties.load (Properties.java:404)
> at org.eclipse.aether.internal.impl.TrackingFileManager.read
> (TrackingFileManager.java:56)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read
> (DefaultUpdateCheckManager.java:511)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata
> (DefaultUpdateCheckManager.java:250)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
> (DefaultMetadataResolver.java:302)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata
> (DefaultMetadataResolver.java:181)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata
> (DefaultRepositorySystem.java:277)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
> (DefaultPluginVersionResolver.java:134)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve
> (DefaultPluginVersionResolver.java:97)
> at
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
> (LifecyclePluginResolver.java:67)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:104)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:86)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:92)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at
[jira] [Comment Edited] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380721#comment-17380721
]
Naga Vijayapuram edited comment on MRESOLVER-153 at 7/14/21, 4:51 PM:
--
Here's the latest workaround that I have resorted to ... steps ...
. git clone [https://github.com/apache/maven-resolver.git]
. cd maven-resolver
. git checkout 1.6.x
. Modify TrackingFileManager.java ; The diff after the modification is ...++
diff --git
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
index e31f0969..2dcc0a88 100644
---
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
+++
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
@@ -53,7 +53,17 @@ class TrackingFileManager
stream = new FileInputStream( file );
Properties props = new Properties();
\- props.load( stream );
+
+ if (System.getProperty("spot_file_with_malformed_encoding").equals("true")) {
+ try {
+ props.load(stream);
+ } catch (Throwable t) {
+ System.out.println("\nfile: " + file + "\n");
+ System.exit(1);
+ }
+ } else {
+ props.load(stream);
+ }
return props;
}
. Do Maven Build
. Copy maven-resolver-impl/target/maven-resolver-impl-1.6.4-SNAPSHOT.jar to
MAVEN_HOME/lib
. Remove MAVEN_HOME/lib/maven-resolver-impl-1.6.2.jar
was (Author: nv):
Here's the latest workaround that I have resorted to ... steps ...
. git clone [https://github.com/apache/maven-resolver.git]
. cd maven-resolver
. git checkout 1.6.x
. Modify TrackingFileManager.java ; The diff after the modification is ...++
diff --git
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
index e31f0969..2dcc0a88 100644
---
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
+++
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
@@ -53,7 +53,17 @@ class TrackingFileManager
stream = new FileInputStream( file );
Properties props = new Properties();
- props.load( stream );
+
+ if (System.getProperty("spot_file_with_malformed_encoding").equals("true")) {
+ try {
+ props.load(stream);
+ } catch (Throwable t) {
+ System.out.println("\nfile: " + file + "\n");
+ System.exit(1);
+ }
+ } else {
+ props.load(stream);
+ }
return props;
}
. Do Maven Build
. Copy maven-resolver-impl/target/maven-resolver-impl-1.6.4-SNAPSHOT.jar to
MAVEN_HOME/lib
. Remove MAVEN_HOME/lib/maven-resolver-impl-1.6.2.jar
> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.6.3, 1.7.0
>
> Attachments: gdmr.txt, gdmr.txt, image-2021-06-05-10-00-08-542.png,
> screenshot-1.png, with-global-sync-context.txt,
> without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}}
> after [this
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
> we face the following error:
> {code:java}
> [main] [INFO]
>
> [main] [INFO] BUILD FAILURE
> [main] [INFO]
>
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO]
>
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
> at java.util.Properties.loadConvert (Properties.java:675)
> at java.util.Properties.load0 (Properties.java:451)
> at java.util.Properties.load (Properties.java:404)
> at org.eclipse.aether.internal.impl.TrackingFileManager.read
> (TrackingFileManager.java:56)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read
> (DefaultUpdateCheckManager.java:511)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata
> (DefaultUpdateCheckManager.java:250)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
> (DefaultMetadataResolver.java:302)
> at
[jira] [Commented] (MNG-6241) Load -Dstyle.color from system properties also
[
https://issues.apache.org/jira/browse/MNG-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380739#comment-17380739
]
Michael Osipov commented on MNG-6241:
-
Yes, but your question was solely about colors, not other args, right?
> Load -Dstyle.color from system properties also
> --
>
> Key: MNG-6241
> URL: https://issues.apache.org/jira/browse/MNG-6241
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Thorsten Glaser
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Coloured output does not look very nice in a Jenkins logfile *and* breaks
> some plugins we use, therefore I wish to disable it programmatically.
> However, looking at the source, I find it can only be disabled by passing the
> command-line options -B or -l, but not from settings.xml or via MAVEN_OPTS in
> the environment.
> I’ve worked around this by using dpkg-divert to move the mvn binary away and
> placing this…
> {{{
> # cat /usr/share/maven/bin/mvn
> #!/bin/mksh-static
> exec /usr/share/maven/bin/mvn.dpkg-dist -B "$@"
> }}}
> … in its stead, but that’s creepy at best. Please implement a setting,
> ideally for settings.xml *and* MAVEN_OPTS, to disable colour.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380721#comment-17380721
]
Naga Vijayapuram edited comment on MRESOLVER-153 at 7/14/21, 4:50 PM:
--
Here's the latest workaround that I have resorted to ... steps ...
. git clone [https://github.com/apache/maven-resolver.git]
. cd maven-resolver
. git checkout 1.6.x
. Modify TrackingFileManager.java ; The diff after the modification is ...++
diff --git
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
index e31f0969..2dcc0a88 100644
---
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
+++
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
@@ -53,7 +53,17 @@ class TrackingFileManager
stream = new FileInputStream( file );
Properties props = new Properties();
- props.load( stream );
+
+ if (System.getProperty("spot_file_with_malformed_encoding").equals("true")) {
+ try {
+ props.load(stream);
+ } catch (Throwable t) {
+ System.out.println("\nfile: " + file + "\n");
+ System.exit(1);
+ }
+ } else {
+ props.load(stream);
+ }
return props;
}
. Do Maven Build
. Copy maven-resolver-impl/target/maven-resolver-impl-1.6.4-SNAPSHOT.jar to
MAVEN_HOME/lib
. Remove MAVEN_HOME/lib/maven-resolver-impl-1.6.2.jar
was (Author: nv):
Here's the latest workaround that I have resorted to ... steps ...
. git clone [https://github.com/apache/maven-resolver.git]
. cd maven-resolver
. git checkout 1.6.x
. Modify TrackingFileManager.java ; The diff after the modification is in
+attached+ file
. Do Maven Build
. Copy maven-resolver-impl/target/maven-resolver-impl-1.6.4-SNAPSHOT.jar to
MAVEN_HOME/lib
. Remove MAVEN_HOME/lib/maven-resolver-impl-1.6.2.jar
> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.6.3, 1.7.0
>
> Attachments: gdmr.txt, gdmr.txt, image-2021-06-05-10-00-08-542.png,
> screenshot-1.png, with-global-sync-context.txt,
> without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}}
> after [this
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
> we face the following error:
> {code:java}
> [main] [INFO]
>
> [main] [INFO] BUILD FAILURE
> [main] [INFO]
>
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO]
>
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
> at java.util.Properties.loadConvert (Properties.java:675)
> at java.util.Properties.load0 (Properties.java:451)
> at java.util.Properties.load (Properties.java:404)
> at org.eclipse.aether.internal.impl.TrackingFileManager.read
> (TrackingFileManager.java:56)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read
> (DefaultUpdateCheckManager.java:511)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata
> (DefaultUpdateCheckManager.java:250)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
> (DefaultMetadataResolver.java:302)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata
> (DefaultMetadataResolver.java:181)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata
> (DefaultRepositorySystem.java:277)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
> (DefaultPluginVersionResolver.java:134)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve
> (DefaultPluginVersionResolver.java:97)
> at
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
> (LifecyclePluginResolver.java:67)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:104)
> at
>
[jira] [Comment Edited] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380735#comment-17380735
]
Naga Vijayapuram edited comment on MRESOLVER-153 at 7/14/21, 4:46 PM:
--
[~David Hayes] - That is right. The sysprop helps in detecting the file that
has malformed encoding.
[~michael-o] - I am very sorry to say that this issue has reoccurred. Everyone
is referring to this and the comments are continuing. Do you think this issue
can be reopened or do you want me open a new issue altogether?
was (Author: nv):
[~David Hayes] - That is right. The sysprop helps in detecting the file that
has malformed encoding.
[~michael-o] - I am very sorry to say that the has reoccurred. Do you think
this issue can be reopened or do you want me open a new issue altogether?
> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.6.3, 1.7.0
>
> Attachments: gdmr.txt, gdmr.txt, image-2021-06-05-10-00-08-542.png,
> screenshot-1.png, with-global-sync-context.txt,
> without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}}
> after [this
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
> we face the following error:
> {code:java}
> [main] [INFO]
>
> [main] [INFO] BUILD FAILURE
> [main] [INFO]
>
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO]
>
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
> at java.util.Properties.loadConvert (Properties.java:675)
> at java.util.Properties.load0 (Properties.java:451)
> at java.util.Properties.load (Properties.java:404)
> at org.eclipse.aether.internal.impl.TrackingFileManager.read
> (TrackingFileManager.java:56)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read
> (DefaultUpdateCheckManager.java:511)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata
> (DefaultUpdateCheckManager.java:250)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
> (DefaultMetadataResolver.java:302)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata
> (DefaultMetadataResolver.java:181)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata
> (DefaultRepositorySystem.java:277)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
> (DefaultPluginVersionResolver.java:134)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve
> (DefaultPluginVersionResolver.java:97)
> at
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
> (LifecyclePluginResolver.java:67)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:104)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:86)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:92)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at
[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380735#comment-17380735
]
Naga Vijayapuram commented on MRESOLVER-153:
[~David Hayes] - That is right. The sysprop helps in detecting the file that
has malformed encoding.
[~michael-o] - I am very sorry to say that the has reoccurred. Do you think
this issue can be reopened or do you want me open a new issue altogether?
> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.6.3, 1.7.0
>
> Attachments: gdmr.txt, gdmr.txt, image-2021-06-05-10-00-08-542.png,
> screenshot-1.png, with-global-sync-context.txt,
> without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}}
> after [this
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
> we face the following error:
> {code:java}
> [main] [INFO]
>
> [main] [INFO] BUILD FAILURE
> [main] [INFO]
>
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO]
>
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
> at java.util.Properties.loadConvert (Properties.java:675)
> at java.util.Properties.load0 (Properties.java:451)
> at java.util.Properties.load (Properties.java:404)
> at org.eclipse.aether.internal.impl.TrackingFileManager.read
> (TrackingFileManager.java:56)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read
> (DefaultUpdateCheckManager.java:511)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata
> (DefaultUpdateCheckManager.java:250)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
> (DefaultMetadataResolver.java:302)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata
> (DefaultMetadataResolver.java:181)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata
> (DefaultRepositorySystem.java:277)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
> (DefaultPluginVersionResolver.java:134)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve
> (DefaultPluginVersionResolver.java:97)
> at
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
> (LifecyclePluginResolver.java:67)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:104)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:86)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:92)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> It's not consistently failing and OSX based CI agents fail more often than
> Linux or Windows ones. After some investigations we saw that as part of
> https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has
> been removed on the
[jira] [Updated] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Naga Vijayapuram updated MRESOLVER-153:
---
Attachment: gdmr.txt
> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.6.3, 1.7.0
>
> Attachments: gdmr.txt, gdmr.txt, image-2021-06-05-10-00-08-542.png,
> screenshot-1.png, with-global-sync-context.txt,
> without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}}
> after [this
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
> we face the following error:
> {code:java}
> [main] [INFO]
>
> [main] [INFO] BUILD FAILURE
> [main] [INFO]
>
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO]
>
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
> at java.util.Properties.loadConvert (Properties.java:675)
> at java.util.Properties.load0 (Properties.java:451)
> at java.util.Properties.load (Properties.java:404)
> at org.eclipse.aether.internal.impl.TrackingFileManager.read
> (TrackingFileManager.java:56)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read
> (DefaultUpdateCheckManager.java:511)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata
> (DefaultUpdateCheckManager.java:250)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
> (DefaultMetadataResolver.java:302)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata
> (DefaultMetadataResolver.java:181)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata
> (DefaultRepositorySystem.java:277)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
> (DefaultPluginVersionResolver.java:134)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve
> (DefaultPluginVersionResolver.java:97)
> at
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
> (LifecyclePluginResolver.java:67)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:104)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:86)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:92)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> It's not consistently failing and OSX based CI agents fail more often than
> Linux or Windows ones. After some investigations we saw that as part of
> https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has
> been removed on the {{TrackingFileManager}}
> ([https://github.com/apache/maven-resolver/pull/67]). This now leads to
> concurrent writes on the {{resolver-status.properties}} file in our tests and
> causes the error during the {{Properties#load()}} method wich then throws the
> above
[jira] [Comment Edited] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380721#comment-17380721
]
Naga Vijayapuram edited comment on MRESOLVER-153 at 7/14/21, 4:41 PM:
--
Here's the latest workaround that I have resorted to ... steps ...
. git clone [https://github.com/apache/maven-resolver.git]
. cd maven-resolver
. git checkout 1.6.x
. Modify TrackingFileManager.java ; The diff after the modification is in
+attached+ file
. Do Maven Build
. Copy maven-resolver-impl/target/maven-resolver-impl-1.6.4-SNAPSHOT.jar to
MAVEN_HOME/lib
. Remove MAVEN_HOME/lib/maven-resolver-impl-1.6.2.jar
was (Author: nv):
Here's the latest workaround that I have resorted to ... steps ...
. git clone [https://github.com/apache/maven-resolver.git]
. cd maven-resolver
. git checkout 1.6.x
. Modify TrackingFileManager.java ; Here's the diff after the modification ...
{quote}diff --git
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
index e31f0969..2dcc0a88 100644
—
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
+++
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
@@ -53,7 +53,17 @@ class TrackingFileManager
stream = new FileInputStream( file );
Properties props = new Properties();
- props.load( stream );
+
+ if (System.getProperty("spot_file_with_malformed_encoding").equals("true"))
{ + try {
+ props.load(stream);
+ }
+ catch (Throwable t) {
+ System.out.println("\\nfile: " + file + "\\n");
+ }
+ } else {
+ props.load(stream);
+ }
return props;
}
{quote}
. Do Maven Build
. Copy maven-resolver-impl/target/maven-resolver-impl-1.6.4-SNAPSHOT.jar to
MAVEN_HOME/lib
. Remove MAVEN_HOME/lib/maven-resolver-impl-1.6.2.jar
> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.6.3, 1.7.0
>
> Attachments: gdmr.txt, image-2021-06-05-10-00-08-542.png,
> screenshot-1.png, with-global-sync-context.txt,
> without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}}
> after [this
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
> we face the following error:
> {code:java}
> [main] [INFO]
>
> [main] [INFO] BUILD FAILURE
> [main] [INFO]
>
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO]
>
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
> at java.util.Properties.loadConvert (Properties.java:675)
> at java.util.Properties.load0 (Properties.java:451)
> at java.util.Properties.load (Properties.java:404)
> at org.eclipse.aether.internal.impl.TrackingFileManager.read
> (TrackingFileManager.java:56)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read
> (DefaultUpdateCheckManager.java:511)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata
> (DefaultUpdateCheckManager.java:250)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
> (DefaultMetadataResolver.java:302)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata
> (DefaultMetadataResolver.java:181)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata
> (DefaultRepositorySystem.java:277)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
> (DefaultPluginVersionResolver.java:134)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve
> (DefaultPluginVersionResolver.java:97)
> at
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
> (LifecyclePluginResolver.java:67)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:104)
> at
>
[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380731#comment-17380731
]
Michael Osipov commented on MRESOLVER-153:
--
This issue has been resolved. If you experience new issues open new issues with
the latest resolver.
> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.6.3, 1.7.0
>
> Attachments: gdmr.txt, image-2021-06-05-10-00-08-542.png,
> screenshot-1.png, with-global-sync-context.txt,
> without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}}
> after [this
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
> we face the following error:
> {code:java}
> [main] [INFO]
>
> [main] [INFO] BUILD FAILURE
> [main] [INFO]
>
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO]
>
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
> at java.util.Properties.loadConvert (Properties.java:675)
> at java.util.Properties.load0 (Properties.java:451)
> at java.util.Properties.load (Properties.java:404)
> at org.eclipse.aether.internal.impl.TrackingFileManager.read
> (TrackingFileManager.java:56)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read
> (DefaultUpdateCheckManager.java:511)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata
> (DefaultUpdateCheckManager.java:250)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
> (DefaultMetadataResolver.java:302)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata
> (DefaultMetadataResolver.java:181)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata
> (DefaultRepositorySystem.java:277)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
> (DefaultPluginVersionResolver.java:134)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve
> (DefaultPluginVersionResolver.java:97)
> at
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
> (LifecyclePluginResolver.java:67)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:104)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:86)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:92)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> It's not consistently failing and OSX based CI agents fail more often than
> Linux or Windows ones. After some investigations we saw that as part of
> https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has
> been removed on the {{TrackingFileManager}}
> ([https://github.com/apache/maven-resolver/pull/67]). This now leads to
> concurrent writes on the {{resolver-status.properties}} file in
[jira] [Updated] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Naga Vijayapuram updated MRESOLVER-153:
---
Attachment: gdmr.txt
> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.6.3, 1.7.0
>
> Attachments: gdmr.txt, image-2021-06-05-10-00-08-542.png,
> screenshot-1.png, with-global-sync-context.txt,
> without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}}
> after [this
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
> we face the following error:
> {code:java}
> [main] [INFO]
>
> [main] [INFO] BUILD FAILURE
> [main] [INFO]
>
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO]
>
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
> at java.util.Properties.loadConvert (Properties.java:675)
> at java.util.Properties.load0 (Properties.java:451)
> at java.util.Properties.load (Properties.java:404)
> at org.eclipse.aether.internal.impl.TrackingFileManager.read
> (TrackingFileManager.java:56)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read
> (DefaultUpdateCheckManager.java:511)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata
> (DefaultUpdateCheckManager.java:250)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
> (DefaultMetadataResolver.java:302)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata
> (DefaultMetadataResolver.java:181)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata
> (DefaultRepositorySystem.java:277)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
> (DefaultPluginVersionResolver.java:134)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve
> (DefaultPluginVersionResolver.java:97)
> at
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
> (LifecyclePluginResolver.java:67)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:104)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:86)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:92)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> It's not consistently failing and OSX based CI agents fail more often than
> Linux or Windows ones. After some investigations we saw that as part of
> https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has
> been removed on the {{TrackingFileManager}}
> ([https://github.com/apache/maven-resolver/pull/67]). This now leads to
> concurrent writes on the {{resolver-status.properties}} file in our tests and
> causes the error during the {{Properties#load()}} method wich then throws the
> above error. See
[jira] [Comment Edited] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380721#comment-17380721
]
Naga Vijayapuram edited comment on MRESOLVER-153 at 7/14/21, 4:37 PM:
--
Here's the latest workaround that I have resorted to ... steps ...
. git clone [https://github.com/apache/maven-resolver.git]
. cd maven-resolver
. git checkout 1.6.x
. Modify TrackingFileManager.java ; Here's the diff after the modification ...
{quote}diff --git
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
index e31f0969..2dcc0a88 100644
—
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
+++
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
@@ -53,7 +53,17 @@ class TrackingFileManager
stream = new FileInputStream( file );
Properties props = new Properties();
- props.load( stream );
+
+ if (System.getProperty("spot_file_with_malformed_encoding").equals("true"))
{ + try {
+ props.load(stream);
+ }
+ catch (Throwable t) {
+ System.out.println("\\nfile: " + file + "\\n");
+ }
+ } else {
+ props.load(stream);
+ }
return props;
}
{quote}
. Do Maven Build
. Copy maven-resolver-impl/target/maven-resolver-impl-1.6.4-SNAPSHOT.jar to
MAVEN_HOME/lib
. Remove MAVEN_HOME/lib/maven-resolver-impl-1.6.2.jar
was (Author: nv):
Here's the latest workaround that I have resorted to ... steps ...
. git clone [https://github.com/apache/maven-resolver.git]
. cd maven-resolver
. git checkout 1.6.x
. Modify TrackingFileManager.java ; Here's the diff after the modification ...
{quote}diff --git
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
index e31f0969..2dcc0a88 100644
—
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
+++
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
@@ -53,7 +53,17 @@ class TrackingFileManager
stream = new FileInputStream( file );
Properties props = new Properties();
\- props.load( stream );
+
+ if (System.getProperty("spot_file_with_malformed_encoding").equals("true"))
{ + try {
+ props.load(stream);
+ } catch (Throwable t) {
+ System.out.println("\nfile: " + file + "\n");
+ System.exit(1);
+ }
+ } else {
+ props.load(stream);
+ }
return props;
}
{quote}
. Do Maven Build
. Copy maven-resolver-impl/target/maven-resolver-impl-1.6.4-SNAPSHOT.jar to
MAVEN_HOME/lib
. Remove MAVEN_HOME/lib/maven-resolver-impl-1.6.2.jar
> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.6.3, 1.7.0
>
> Attachments: image-2021-06-05-10-00-08-542.png, screenshot-1.png,
> with-global-sync-context.txt, without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}}
> after [this
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
> we face the following error:
> {code:java}
> [main] [INFO]
>
> [main] [INFO] BUILD FAILURE
> [main] [INFO]
>
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO]
>
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
> at java.util.Properties.loadConvert (Properties.java:675)
> at java.util.Properties.load0 (Properties.java:451)
> at java.util.Properties.load (Properties.java:404)
> at org.eclipse.aether.internal.impl.TrackingFileManager.read
> (TrackingFileManager.java:56)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read
> (DefaultUpdateCheckManager.java:511)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata
> (DefaultUpdateCheckManager.java:250)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
> (DefaultMetadataResolver.java:302)
>
[jira] [Comment Edited] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380721#comment-17380721
]
Naga Vijayapuram edited comment on MRESOLVER-153 at 7/14/21, 4:32 PM:
--
Here's the latest workaround that I have resorted to ... steps ...
. git clone [https://github.com/apache/maven-resolver.git]
. cd maven-resolver
. git checkout 1.6.x
. Modify TrackingFileManager.java ; Here's the diff after the modification ...
{quote}diff --git
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
index e31f0969..2dcc0a88 100644
—
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
+++
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
@@ -53,7 +53,17 @@ class TrackingFileManager
stream = new FileInputStream( file );
Properties props = new Properties();
\- props.load( stream );
+
+ if (System.getProperty("spot_file_with_malformed_encoding").equals("true"))
{ + try {
+ props.load(stream);
+ } catch (Throwable t) {
+ System.out.println("\nfile: " + file + "\n");
+ System.exit(1);
+ }
+ } else {
+ props.load(stream);
+ }
return props;
}
{quote}
. Do Maven Build
. Copy maven-resolver-impl/target/maven-resolver-impl-1.6.4-SNAPSHOT.jar to
MAVEN_HOME/lib
. Remove MAVEN_HOME/lib/maven-resolver-impl-1.6.2.jar
was (Author: nv):
Here's the latest workaround that I have resorted to ... steps ...
. git clone [https://github.com/apache/maven-resolver.git]
. cd maven-resolver
. git checkout 1.6.x
. Modify TrackingFileManager.java ; Here's the diff after the modification ...
{quote}diff --git
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
index e31f0969..2dcc0a88 100644
—
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
+++
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
@@ -53,7 +53,17 @@ class TrackingFileManager
stream = new FileInputStream( file );
Properties props = new Properties();
- props.load( stream );
+
+ if (System.getProperty("spot_file_with_malformed_encoding").equals("true"))
\{ + try { + props.load(stream); + }
catch (Throwable t) \{ + System.out.println("\nfile: " + file + "\n"); +
System.exit(1); + }
+ } else \{ + props.load(stream); + }
return props;
}
{quote}
. Do Maven Build
. Copy maven-resolver-impl/target/maven-resolver-impl-1.6.4-SNAPSHOT.jar to
MAVEN_HOME/lib
. Remove MAVEN_HOME/lib/maven-resolver-impl-1.6.2.jar
> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.6.3, 1.7.0
>
> Attachments: image-2021-06-05-10-00-08-542.png, screenshot-1.png,
> with-global-sync-context.txt, without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}}
> after [this
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
> we face the following error:
> {code:java}
> [main] [INFO]
>
> [main] [INFO] BUILD FAILURE
> [main] [INFO]
>
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO]
>
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
> at java.util.Properties.loadConvert (Properties.java:675)
> at java.util.Properties.load0 (Properties.java:451)
> at java.util.Properties.load (Properties.java:404)
> at org.eclipse.aether.internal.impl.TrackingFileManager.read
> (TrackingFileManager.java:56)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read
> (DefaultUpdateCheckManager.java:511)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata
> (DefaultUpdateCheckManager.java:250)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
> (DefaultMetadataResolver.java:302)
[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380729#comment-17380729
]
David Hayes commented on MRESOLVER-153:
---
[~nv], so this is to highlight which files are corrupted and then exit early?
And to enable this behaviour you'd need to specify:
{code:java}
-Dspot_file_with_malformed_encoding=true
{code}
to enable it?
> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.6.3, 1.7.0
>
> Attachments: image-2021-06-05-10-00-08-542.png, screenshot-1.png,
> with-global-sync-context.txt, without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}}
> after [this
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
> we face the following error:
> {code:java}
> [main] [INFO]
>
> [main] [INFO] BUILD FAILURE
> [main] [INFO]
>
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO]
>
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
> at java.util.Properties.loadConvert (Properties.java:675)
> at java.util.Properties.load0 (Properties.java:451)
> at java.util.Properties.load (Properties.java:404)
> at org.eclipse.aether.internal.impl.TrackingFileManager.read
> (TrackingFileManager.java:56)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read
> (DefaultUpdateCheckManager.java:511)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata
> (DefaultUpdateCheckManager.java:250)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
> (DefaultMetadataResolver.java:302)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata
> (DefaultMetadataResolver.java:181)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata
> (DefaultRepositorySystem.java:277)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
> (DefaultPluginVersionResolver.java:134)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve
> (DefaultPluginVersionResolver.java:97)
> at
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
> (LifecyclePluginResolver.java:67)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:104)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:86)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:92)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> It's not consistently failing and OSX based CI agents fail more often than
> Linux or Windows ones. After some investigations we saw that as part of
> https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has
> been removed on the {{TrackingFileManager}}
> ([https://github.com/apache/maven-resolver/pull/67]).
[GitHub] [maven-resolver] michael-o commented on pull request #114: Update TrackingFileManager.java to help with MRESOLVER-153
michael-o commented on pull request #114: URL: https://github.com/apache/maven-resolver/pull/114#issuecomment-880036997 What is the purpose of this PR if the issue has been resolved? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380721#comment-17380721
]
Naga Vijayapuram edited comment on MRESOLVER-153 at 7/14/21, 4:28 PM:
--
Here's the latest workaround that I have resorted to ... steps ...
. git clone [https://github.com/apache/maven-resolver.git]
. cd maven-resolver
. git checkout 1.6.x
. Modify TrackingFileManager.java ; Here's the diff after the modification ...
{quote}diff --git
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
index e31f0969..2dcc0a88 100644
—
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
+++
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
@@ -53,7 +53,17 @@ class TrackingFileManager
stream = new FileInputStream( file );
Properties props = new Properties();
- props.load( stream );
+
+ if (System.getProperty("spot_file_with_malformed_encoding").equals("true"))
\{ + try { + props.load(stream); + }
catch (Throwable t) \{ + System.out.println("\nfile: " + file + "\n"); +
System.exit(1); + }
+ } else \{ + props.load(stream); + }
return props;
}
{quote}
. Do Maven Build
. Copy maven-resolver-impl/target/maven-resolver-impl-1.6.4-SNAPSHOT.jar to
MAVEN_HOME/lib
. Remove MAVEN_HOME/lib/maven-resolver-impl-1.6.2.jar
was (Author: nv):
Here's the latest workaround that I have resorted to ... steps ...
. git clone [https://github.com/apache/maven-resolver.git]
. cd maven-resolver
. git checkout 1.6.x
. Modify TrackingFileManager.java ; Here's the diff after the modification ...
```
diff --git
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
index e31f0969..2dcc0a88 100644
—
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
+++
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
@@ -53,7 +53,17 @@ class TrackingFileManager
stream = new FileInputStream( file );
Properties props = new Properties();
\- props.load( stream );
+
+ if (System.getProperty("spot_file_with_malformed_encoding").equals("true"))
\{ + try \{ + props.load(stream); + }
catch (Throwable t) \{ + System.out.println("\nfile: " + file + "\n"); +
System.exit(1); + }
+ } else \{ + props.load(stream); + }
return props;
}
```
. Do Maven Build
. Copy maven-resolver-impl/target/maven-resolver-impl-1.6.4-SNAPSHOT.jar to
MAVEN_HOME/lib
. Remove MAVEN_HOME/lib/maven-resolver-impl-1.6.2.jar
> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.6.3, 1.7.0
>
> Attachments: image-2021-06-05-10-00-08-542.png, screenshot-1.png,
> with-global-sync-context.txt, without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}}
> after [this
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
> we face the following error:
> {code:java}
> [main] [INFO]
>
> [main] [INFO] BUILD FAILURE
> [main] [INFO]
>
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO]
>
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
> at java.util.Properties.loadConvert (Properties.java:675)
> at java.util.Properties.load0 (Properties.java:451)
> at java.util.Properties.load (Properties.java:404)
> at org.eclipse.aether.internal.impl.TrackingFileManager.read
> (TrackingFileManager.java:56)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read
> (DefaultUpdateCheckManager.java:511)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata
> (DefaultUpdateCheckManager.java:250)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
> (DefaultMetadataResolver.java:302)
> at
[jira] [Comment Edited] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380721#comment-17380721
]
Naga Vijayapuram edited comment on MRESOLVER-153 at 7/14/21, 4:25 PM:
--
Here's the latest workaround that I have resorted to ... steps ...
. git clone [https://github.com/apache/maven-resolver.git]
. cd maven-resolver
. git checkout 1.6.x
. Modify TrackingFileManager.java ; Here's the diff after the modification ...
```
diff --git
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
index e31f0969..2dcc0a88 100644
—
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
+++
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
@@ -53,7 +53,17 @@ class TrackingFileManager
stream = new FileInputStream( file );
Properties props = new Properties();
\- props.load( stream );
+
+ if (System.getProperty("spot_file_with_malformed_encoding").equals("true"))
\{ + try \{ + props.load(stream); + }
catch (Throwable t) \{ + System.out.println("\nfile: " + file + "\n"); +
System.exit(1); + }
+ } else \{ + props.load(stream); + }
return props;
}
```
. Do Maven Build
. Copy maven-resolver-impl/target/maven-resolver-impl-1.6.4-SNAPSHOT.jar to
MAVEN_HOME/lib
. Remove MAVEN_HOME/lib/maven-resolver-impl-1.6.2.jar
was (Author: nv):
Here's the latest workaround that I have resorted to ... steps ...
. git clone [https://github.com/apache/maven-resolver.git]
.cd maven-resolver
. git checkout 1.6.x
. Modify TrackingFileManager.java ; Here's the diff after the modification ...
```
diff --git
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
index e31f0969..2dcc0a88 100644
—
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
+++
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
@@ -53,7 +53,17 @@ class TrackingFileManager
stream = new FileInputStream( file );
Properties props = new Properties();
- props.load( stream );
+
+ if (System.getProperty("spot_file_with_malformed_encoding").equals("true")) {
+ try \{ + props.load(stream); + } catch (Throwable t) \{ +
System.out.println("\nfile: " + file + "\n"); + System.exit(1); + }
+ } else \{ + props.load(stream); + }
return props;
}
```
. Do Maven Build
. Copy maven-resolver-impl/target/maven-resolver-impl-1.6.4-SNAPSHOT.jar to
MAVEN_HOME/lib
. Remove MAVEN_HOME/lib/maven-resolver-impl-1.6.2.jar
> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.6.3, 1.7.0
>
> Attachments: image-2021-06-05-10-00-08-542.png, screenshot-1.png,
> with-global-sync-context.txt, without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}}
> after [this
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
> we face the following error:
> {code:java}
> [main] [INFO]
>
> [main] [INFO] BUILD FAILURE
> [main] [INFO]
>
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO]
>
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
> at java.util.Properties.loadConvert (Properties.java:675)
> at java.util.Properties.load0 (Properties.java:451)
> at java.util.Properties.load (Properties.java:404)
> at org.eclipse.aether.internal.impl.TrackingFileManager.read
> (TrackingFileManager.java:56)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read
> (DefaultUpdateCheckManager.java:511)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata
> (DefaultUpdateCheckManager.java:250)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
> (DefaultMetadataResolver.java:302)
> at
[jira] [Comment Edited] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380721#comment-17380721
]
Naga Vijayapuram edited comment on MRESOLVER-153 at 7/14/21, 4:24 PM:
--
Here's the latest workaround that I have resorted to ... steps ...
. git clone [https://github.com/apache/maven-resolver.git]
.cd maven-resolver
. git checkout 1.6.x
. Modify TrackingFileManager.java ; Here's the diff after the modification ...
```
diff --git
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
index e31f0969..2dcc0a88 100644
—
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
+++
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
@@ -53,7 +53,17 @@ class TrackingFileManager
stream = new FileInputStream( file );
Properties props = new Properties();
- props.load( stream );
+
+ if (System.getProperty("spot_file_with_malformed_encoding").equals("true")) {
+ try \{ + props.load(stream); + } catch (Throwable t) \{ +
System.out.println("\nfile: " + file + "\n"); + System.exit(1); + }
+ } else \{ + props.load(stream); + }
return props;
}
```
. Do Maven Build
. Copy maven-resolver-impl/target/maven-resolver-impl-1.6.4-SNAPSHOT.jar to
MAVEN_HOME/lib
. Remove MAVEN_HOME/lib/maven-resolver-impl-1.6.2.jar
was (Author: nv):
Here's the latest workaround that I have resorted to ... steps ...
. git clone [https://github.com/apache/maven-resolver.git]
. git checkout 1.6.x
. Modify TrackingFileManager.java ; Here's the diff after the modification ...
```
diff --git
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
index e31f0969..2dcc0a88 100644
---
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
+++
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
@@ -53,7 +53,17 @@ class TrackingFileManager
stream = new FileInputStream( file );
Properties props = new Properties();
- props.load( stream );
+
+ if (System.getProperty("spot_file_with_malformed_encoding").equals("true")) {
+ try {
+ props.load(stream);
+ } catch (Throwable t) {
+ System.out.println("\nfile: " + file + "\n");
+ System.exit(1);
+ }
+ } else {
+ props.load(stream);
+ }
return props;
}
```
. Do Maven Build
. Copy maven-resolver-impl/target/maven-resolver-impl-1.6.4-SNAPSHOT.jar to
MAVEN_HOME/lib
. Remove MAVEN_HOME/lib/maven-resolver-impl-1.6.2.jar
> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.6.3, 1.7.0
>
> Attachments: image-2021-06-05-10-00-08-542.png, screenshot-1.png,
> with-global-sync-context.txt, without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}}
> after [this
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
> we face the following error:
> {code:java}
> [main] [INFO]
>
> [main] [INFO] BUILD FAILURE
> [main] [INFO]
>
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO]
>
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
> at java.util.Properties.loadConvert (Properties.java:675)
> at java.util.Properties.load0 (Properties.java:451)
> at java.util.Properties.load (Properties.java:404)
> at org.eclipse.aether.internal.impl.TrackingFileManager.read
> (TrackingFileManager.java:56)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read
> (DefaultUpdateCheckManager.java:511)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata
> (DefaultUpdateCheckManager.java:250)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
> (DefaultMetadataResolver.java:302)
> at
[jira] [Commented] (SUREFIRE-1928) NullPointerException at AbstractSurefireMojo.java:3300
[ https://issues.apache.org/jira/browse/SUREFIRE-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380723#comment-17380723 ] Rich M commented on SUREFIRE-1928: -- [~tibordigana], any further update on this ? > NullPointerException at AbstractSurefireMojo.java:3300 > -- > > Key: SUREFIRE-1928 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1928 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 3.0.0-M5 > Environment: Windows, Java 8 >Reporter: Rich M >Assignee: Tibor Digana >Priority: Blocker > > I have following dependency in my pom: > > org.apache.maven.plugins > maven-surefire-plugin > 3.0.0-M5 > > > org.apache.maven.surefire > surefire-junit-platform > 3.0.0-M5 > > > > > Running the tests leads to NPE: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (default-test) > on project junit5: Execution default-test of goal org.ap > ache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed.: > NullPointerException -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test > (default-test) on proje > ct junit5: Execution default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed. > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:215) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:156) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:148) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:117) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:81) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build > (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute > (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:193) > at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:90) > at sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke (Method.java:508) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced > (Launcher.java:282) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch > (Launcher.java:225) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode > (Launcher.java:406) > at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347) > Caused by: org.apache.maven.plugin.PluginExecutionException: Execution > default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed. > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo > (DefaultBuildPluginManager.java:148) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:210) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:156) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:148) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:117) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:81) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build > (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute > (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:193) > at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:90) > at sun.reflect.DelegatingMethodAccessorImpl.invoke >
[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380721#comment-17380721
]
Naga Vijayapuram commented on MRESOLVER-153:
Here's the latest workaround that I have resorted to ... steps ...
. git clone [https://github.com/apache/maven-resolver.git]
. git checkout 1.6.x
. Modify TrackingFileManager.java ; Here's the diff after the modification ...
```
diff --git
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
index e31f0969..2dcc0a88 100644
---
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
+++
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/TrackingFileManager.java
@@ -53,7 +53,17 @@ class TrackingFileManager
stream = new FileInputStream( file );
Properties props = new Properties();
- props.load( stream );
+
+ if (System.getProperty("spot_file_with_malformed_encoding").equals("true")) {
+ try {
+ props.load(stream);
+ } catch (Throwable t) {
+ System.out.println("\nfile: " + file + "\n");
+ System.exit(1);
+ }
+ } else {
+ props.load(stream);
+ }
return props;
}
```
. Do Maven Build
. Copy maven-resolver-impl/target/maven-resolver-impl-1.6.4-SNAPSHOT.jar to
MAVEN_HOME/lib
. Remove MAVEN_HOME/lib/maven-resolver-impl-1.6.2.jar
> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.6.3, 1.7.0
>
> Attachments: image-2021-06-05-10-00-08-542.png, screenshot-1.png,
> with-global-sync-context.txt, without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}}
> after [this
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
> we face the following error:
> {code:java}
> [main] [INFO]
>
> [main] [INFO] BUILD FAILURE
> [main] [INFO]
>
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO]
>
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
> at java.util.Properties.loadConvert (Properties.java:675)
> at java.util.Properties.load0 (Properties.java:451)
> at java.util.Properties.load (Properties.java:404)
> at org.eclipse.aether.internal.impl.TrackingFileManager.read
> (TrackingFileManager.java:56)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read
> (DefaultUpdateCheckManager.java:511)
> at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata
> (DefaultUpdateCheckManager.java:250)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve
> (DefaultMetadataResolver.java:302)
> at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata
> (DefaultMetadataResolver.java:181)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata
> (DefaultRepositorySystem.java:277)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
> (DefaultPluginVersionResolver.java:134)
> at
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve
> (DefaultPluginVersionResolver.java:97)
> at
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
> (LifecyclePluginResolver.java:67)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:104)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
> (DefaultLifecycleTaskSegmentCalculator.java:86)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:92)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
> at
[jira] [Updated] (MPOM-210) Adding CVE Checks via OWASP
[
https://issues.apache.org/jira/browse/MPOM-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MPOM-210:
---
Fix Version/s: (was: MAVEN-35)
> Adding CVE Checks via OWASP
> ---
>
> Key: MPOM-210
> URL: https://issues.apache.org/jira/browse/MPOM-210
> Project: Maven POMs
> Issue Type: Improvement
> Components: maven
>Affects Versions: MAVEN-33
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> We should add a configuration for CVS checks for example via OWASP maven
> plugin.
> I think the first step should be add at least an entry in pluginManagement:
> {code}
>
> org.owasp
> dependency-check-maven
> 3.3.2
>
> {code}
> The other parts would be to add an entry for:
> https://github.com/sonatype/ossindex-maven
> which is not a good idea at the moment, cause it does not support JDK 10...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-shade-plugin] dependabot[bot] opened a new pull request #106: Bump asmVersion from 9.1 to 9.2
dependabot[bot] opened a new pull request #106: URL: https://github.com/apache/maven-shade-plugin/pull/106 Bumps `asmVersion` from 9.1 to 9.2. Updates `asm` from 9.1 to 9.2 Updates `asm-commons` from 9.1 to 9.2 Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-shade-plugin] elharo commented on pull request #102: Bump slf4j-simple from 1.7.30 to 1.7.31
elharo commented on pull request #102: URL: https://github.com/apache/maven-shade-plugin/pull/102#issuecomment-879998126 @dependabot rebase -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MEAR-303) Problem when using EJBClient in an EAR
Berry created MEAR-303: -- Summary: Problem when using EJBClient in an EAR Key: MEAR-303 URL: https://issues.apache.org/jira/browse/MEAR-303 Project: Maven EAR Plugin Issue Type: Bug Affects Versions: 3.2.0 Reporter: Berry Hello, When trying to upgrade the EAR plugin from version 3.1.0 to 3.2.0, I'm running into a problem with the packaging of an EJB dependency. I've created a sample project to show the issue. I'm using a 'core' module with EJB packaging and a web module packaged as a WAR, all wrapped up in an EAR. Additionally, this is a Camunda project and deployed to a WildFly Camunda instance, version 7.9.0. If I build the EAR using plugin version 3.1.0, I get the Camunda ejb-client dependency inside the WAR and everything works just fine. After upgrading to version 3.2.0 of the EAR plugin, this dependency is missing and it stops working. That's the only difference I've been able to find in the real project. I'm not sure if this is a bug or a mistake in the plugin configuration, but I've not been able to get it to package as I would expect. Any help would be appreciated! Here is the sample project: https://github.com/berryh/CamundaEJBMavenEarPluginBugDemo -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-shade-plugin] elharo merged pull request #101: Bump slf4j-api from 1.7.30 to 1.7.31
elharo merged pull request #101: URL: https://github.com/apache/maven-shade-plugin/pull/101 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MENFORCER-335) Documentation suggests unreliable practice for dependency convergence
[ https://issues.apache.org/jira/browse/MENFORCER-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380679#comment-17380679 ] Robert Scholte commented on MENFORCER-335: -- The example is for more reasons misleading: it should not use 2 SLF4J dependencies, but 2 unrelated dependencies both using some shared dependency, e.g. slf4j-api. My advice would be: If one dependency chain ends in $coordinate1 and another ends in $coordinate2, apply dependencyManagement for version $version. A PR can be created by using the edit-button in the navigation-bar, which is available for almost any page within the maven project, or go to https://github.com/apache/maven-enforcer/blob/enforcer-3.0.0-M3/enforcer-rules/src/site/apt/dependencyConvergence.apt.vm > Documentation suggests unreliable practice for dependency convergence > - > > Key: MENFORCER-335 > URL: https://issues.apache.org/jira/browse/MENFORCER-335 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Documentation >Affects Versions: 3.0.0-M2 >Reporter: Roland Illig >Priority: Major > > The [documentation for Dependency > Convergence|https://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html] > describes how to suppress an error reported by the check. This description > leads to unreliable project configurations. It may or may not be intentional > that the documentation merely states "And this will succeed" without > explicitly saying that doing this is good or bad practice. > In the example from the documentation, using an exclusion element works for > the very moment, but as soon as the dependency slf4j-jdk14 is no longer > needed, the project will break since slf4j-api is still required by > slf4j-nop, but not included anymore. > A more reliable and sustainable solution would be to have declarations like > the following: > * If one dependency chain ends in org.slf4j:slf4j-api:1.6.1 and another ends > in org.slf4j:slf4j-api:1.6.0, use version 1.6.1. > The general pattern is: > * If one dependency chain ends in $coordinate1 and another ends in > $coordinate2, use version $version. > Using this pattern instead of globally saying "don't use version 1.6.0" would > not break the above scenario where slf4j-jdk14 is no longer needed. Even > better, since during dependency resolution this particular conflict does not > occur anymore, this rule can be flagged as being no longer necessary. > It should be possible to specify not only the last coordinate of a dependency > chain but any elements, as in the following example: > * If one dependency chain ends in org.slf4j:slf4j-jdk14:1.6.1, > org.slf4j:slf4j-api:1.6.1 and another ends in org.slf4j:slf4j-nop:1.6.0, > org.slf4j:slf4j-api:1.6.0, use version 1.6.1. > As it is now, the dependency convergence test encourages Maven users to > specify overly general and therefore wrong exclusion rules. This should be > avoided. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MENFORCER-372) Switch to JUnit5
[ https://issues.apache.org/jira/browse/MENFORCER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MENFORCER-372: - Labels: Java8 up-for-grabs (was: Java8) > Switch to JUnit5 > > > Key: MENFORCER-372 > URL: https://issues.apache.org/jira/browse/MENFORCER-372 > Project: Maven Enforcer Plugin > Issue Type: Dependency upgrade > Components: Plugin >Affects Versions: 3.0.0-M3 >Reporter: Krosheninnikov Artem >Priority: Minor > Labels: Java8, up-for-grabs > Fix For: 3.0.1 > > > Since even Maven switched to JUnit5 [1], it'd be great to move forward and > use JUnit5 in Enforcer too. The only problem is that it requires Java 8. [2] > Even if it won't happen with 3.x version, it's ok to put this task to backlog. > > [1] > [https://github.com/apache/maven/commit/bb916d0784c7631866167928e4d0615df3317567] > > [2] [https://junit.org/junit5/docs/current/user-guide/#overview-java-versions] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-dependency-plugin] antoniolucasnobar commented on pull request #145: [MDEP-568] - Moves similar methods to parent class
antoniolucasnobar commented on pull request #145: URL: https://github.com/apache/maven-dependency-plugin/pull/145#issuecomment-879958466 @bmarwell this is the refactor we talked about in #135 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MENFORCER-252) DependencyConvergence rule doesn't account dependencyManagement section correctly
[
https://issues.apache.org/jira/browse/MENFORCER-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MENFORCER-252.
Assignee: Robert Scholte
Resolution: Not A Bug
If you start with an empty local repo and you try to build a project with only
the org.asynchttpclient:async-http-client:2.0.3 you will see that Maven
downloads netty-handler-4.0.34.
To me this means that the Dependency Converge Rule does exactly the same as
Maven and fails for that reason, so it is not a bug.
To understand why Maven wants to download this artifact, somebody needs to
investigate Maven Artifact Resolver ( https://github.com/apache/maven-resolver )
> DependencyConvergence rule doesn't account dependencyManagement section
> correctly
> -
>
> Key: MENFORCER-252
> URL: https://issues.apache.org/jira/browse/MENFORCER-252
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 1.4.1
>Reporter: Dmitry Spikhalskiy
>Assignee: Robert Scholte
>Priority: Major
> Labels: S2, dependency-tree
>
> DependencyConvergence doesn't catch dependencyManagement section of
> dependency correctly.
> Specific example:
> We have module that depends on async-http-client:
> {code:xml}
>
> org.asynchttpclient
> async-http-client
> 2.0.3
>
> {code}
> From dependencyConvergence rule we get
> {noformat}
> [WARNING] Rule 0: org.apache.maven.plugins.enforcer.DependencyConvergence
> failed with message:
> Failed while enforcing releasability the error(s) are [
> Dependency convergence error for io.netty:netty-handler:4.0.36.Final paths to
> dependency are:
> +-our_artifact
> +-org.asynchttpclient:async-http-client:2.0.3
> +-io.netty:netty-codec-http:4.0.36.Final
> +-io.netty:netty-handler:4.0.36.Final
> and
> +-our_artifact
> +-org.asynchttpclient:async-http-client:2.0.3
> +-com.typesafe.netty:netty-reactive-streams:1.0.4
> +-io.netty:netty-handler:4.0.34.Final
> {noformat}
> While, actually, dependencyManagement section of async-http-client specifies
> and enforce netty-handler:4.0.36.Final and it's dependency tree doesn't
> contain netty-handler:4.0.34.Final
> So... if it's not a bug, it should be a way to ignore such cases of
> explicitly resolved conflicts in external artifact maybe.
> Current fix for this is
> {code:xml}
>
> org.asynchttpclient
> async-http-client
>
>
> io.netty
> netty-handler
>
>
>
>
> io.netty
> netty-handler
> 4.0.36.Final
>
> {code}
> But it's stupid, because netty-handler already contains only
> netty-handler:4.0.36.Final
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-resolver] nvijayap opened a new pull request #114: Update TrackingFileManager.java to help with MRESOLVER-153
nvijayap opened a new pull request #114: URL: https://github.com/apache/maven-resolver/pull/114 This PR is to spot files that have malformed encoding by setting the system property "spot_file_with_malformed_encoding" on the mvn command-line ... `mvn -Dspot_file_with_malformed_encoding=true` This should help with https://issues.apache.org/jira/browse/MRESOLVER-153 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6241) Load -Dstyle.color from system properties also
[
https://issues.apache.org/jira/browse/MNG-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380593#comment-17380593
]
Thorsten Glaser commented on MNG-6241:
--
Sure. That would help with the colour option specifically, not with other
options, but that’s the one I need.
> Load -Dstyle.color from system properties also
> --
>
> Key: MNG-6241
> URL: https://issues.apache.org/jira/browse/MNG-6241
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Thorsten Glaser
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Coloured output does not look very nice in a Jenkins logfile *and* breaks
> some plugins we use, therefore I wish to disable it programmatically.
> However, looking at the source, I find it can only be disabled by passing the
> command-line options -B or -l, but not from settings.xml or via MAVEN_OPTS in
> the environment.
> I’ve worked around this by using dpkg-divert to move the mvn binary away and
> placing this…
> {{{
> # cat /usr/share/maven/bin/mvn
> #!/bin/mksh-static
> exec /usr/share/maven/bin/mvn.dpkg-dist -B "$@"
> }}}
> … in its stead, but that’s creepy at best. Please implement a setting,
> ideally for settings.xml *and* MAVEN_OPTS, to disable colour.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-compiler-plugin] mseele commented on a change in pull request #40: [MCOMPILER-272] - When annotationProcessorPaths has multiple entries,…
mseele commented on a change in pull request #40:
URL:
https://github.com/apache/maven-compiler-plugin/pull/40#discussion_r669565324
##
File path:
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java
##
@@ -1660,26 +1660,27 @@ private boolean hasNewFile( File classPathEntry, Date
buildStartTime )
requiredArtifacts.add( artifact );
}
-ArtifactResolutionRequest request = new ArtifactResolutionRequest()
-.setArtifact( requiredArtifacts.iterator().next() )
-.setResolveRoot( true )
-.setResolveTransitively( true )
-.setArtifactDependencies( requiredArtifacts )
-.setLocalRepository( session.getLocalRepository() )
-.setRemoteRepositories(
project.getRemoteArtifactRepositories() );
+Set elements = new HashSet<>( );
-ArtifactResolutionResult resolutionResult =
repositorySystem.resolve( request );
+for ( Artifact artifact : requiredArtifacts )
+{
+ArtifactResolutionRequest request = new
ArtifactResolutionRequest()
+.setArtifact( artifact )
+.setResolveRoot( true )
+.setResolveTransitively( true )
+.setLocalRepository(
session.getLocalRepository() )
+.setRemoteRepositories(
project.getRemoteArtifactRepositories() );
-resolutionErrorHandler.throwErrors( request, resolutionResult );
+ArtifactResolutionResult resolutionResult =
repositorySystem.resolve( request );
Review comment:
@khmarbaise, @olamy or @rfscholte, can you help me with my question? Any
example would be great...thank you.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7185) Describe explicit and recommended version for VersionRange.createFromVersionSpec()
[
https://issues.apache.org/jira/browse/MNG-7185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380541#comment-17380541
]
Hudson commented on MNG-7185:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » maven-3.8.x #50
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.8.x/50/
> Describe explicit and recommended version for
> VersionRange.createFromVersionSpec()
> --
>
> Key: MNG-7185
> URL: https://issues.apache.org/jira/browse/MNG-7185
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Nils Breunese
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.8.2, 4.0.0, 4.0.0-alpha-1
>
>
> I would expect a version range for a single version to not contain any other
> versions, but it seems this is not the case, because this test fails on the
> second assertion:
> {code}
> @Test
> void range_with_single_version_should_not_contain_other_version() {
> VersionRange singleVersionRange =
> VersionRange.createFromVersionSpec("1.0.0");
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("1.0.0"))).isTrue();
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("2.0.0"))).isFalse();
> }
> {code}
> Is this a bug, or do I misinterpret what a single version range is? Does
> {{maven-artifact}} have a concept for a version range that only contains a
> single version?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6754) Set the same timestamp in multi module builds
[ https://issues.apache.org/jira/browse/MNG-6754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380528#comment-17380528 ] Hudson commented on MNG-6754: - Build succeeded in Jenkins: Maven » Maven TLP » maven » master #184 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/184/ > Set the same timestamp in multi module builds > - > > Key: MNG-6754 > URL: https://issues.apache.org/jira/browse/MNG-6754 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories, Deployment >Affects Versions: 3.6.3 >Reporter: Michael Angstadt >Assignee: Michael Osipov >Priority: Minor > Fix For: 3.8.2, 4.0.0, 4.0.0-alpha-1 > > > When multi module snapshots are built using Maven, the version timestamp may > be different for each module. This makes it difficult to quickly reference a > historical snapshot of a multi module project, which is something we might do > when determining when a bug was introduced. > [This Stack Overflow question|https://stackoverflow.com/q/45629816/2048802] > provides a good example of the problem. [The accepted > answer|https://stackoverflow.com/a/45715820/2048802] seems like a reasonable > solution, but does not appear to work. [Looking at the > code|https://github.com/apache/maven/blob/d9a0eee7fe2e2b1d77e59cf5bc772e758d29e47d/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RemoteSnapshotMetadata.java#L85], > there does not appear to be a way to override the timestamp. > Please add a way to use a consistent timestamp for all modules in a build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7185) Describe explicit and recommended version for VersionRange.createFromVersionSpec()
[
https://issues.apache.org/jira/browse/MNG-7185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380527#comment-17380527
]
Hudson commented on MNG-7185:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » master #184
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/184/
> Describe explicit and recommended version for
> VersionRange.createFromVersionSpec()
> --
>
> Key: MNG-7185
> URL: https://issues.apache.org/jira/browse/MNG-7185
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Nils Breunese
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.8.2, 4.0.0, 4.0.0-alpha-1
>
>
> I would expect a version range for a single version to not contain any other
> versions, but it seems this is not the case, because this test fails on the
> second assertion:
> {code}
> @Test
> void range_with_single_version_should_not_contain_other_version() {
> VersionRange singleVersionRange =
> VersionRange.createFromVersionSpec("1.0.0");
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("1.0.0"))).isTrue();
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("2.0.0"))).isFalse();
> }
> {code}
> Is this a bug, or do I misinterpret what a single version range is? Does
> {{maven-artifact}} have a concept for a version range that only contains a
> single version?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHADE-373) Source transformation on source jar can break OSGi resolution due to duplicated bundle name
[ https://issues.apache.org/jira/browse/MSHADE-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSHADE-373: -- Summary: Source transformation on source jar can break OSGi resolution due to duplicated bundle name (was: Source transformation on source jar can break OSGi resolution due to duplicated bundle name.) > Source transformation on source jar can break OSGi resolution due to > duplicated bundle name > --- > > Key: MSHADE-373 > URL: https://issues.apache.org/jira/browse/MSHADE-373 > Project: Maven Shade Plugin > Issue Type: Improvement >Affects Versions: 3.2.4 >Reporter: Rafael Winterhalter >Assignee: Romain Manni-Bucau >Priority: Critical > Fix For: 3.3.0 > > > Manifest transformers in the shade plugin are often used to add meta-data for > OSGi use since the shade and OSGi plugins are not overly compatible. If the > same transformer is applied to the source plugin's manifest, the resolution > will fail due to a duplicate bundle id. > It is therefore necessary to being able to opt-out of the manifest > transformer when shading a source file. > Pull request: [https://github.com/apache/maven-shade-plugin/pull/59] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOLVER-189) Using semaphore-redisson followed by rwlock-redisson on many parallel build of the same project triggers redisson error
[
https://issues.apache.org/jira/browse/MRESOLVER-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380503#comment-17380503
]
Michael Osipov commented on MRESOLVER-189:
--
Thanks for the files, just went through:
{noformat}
data-rwlock-gav2_15.db
data-rwlock-gav2_23.db
data-rwlock-gav2_26.db
data-rwlock-gav3_14.db
data-rwlock-gav4_14.db
{noformat}
Same behavior, lock up in Redisson.
Please provide also at least two thread dumps for these.
> Using semaphore-redisson followed by rwlock-redisson on many parallel build
> of the same project triggers redisson error
> ---
>
> Key: MRESOLVER-189
> URL: https://issues.apache.org/jira/browse/MRESOLVER-189
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Jacques-Etienne Beaudet
>Assignee: Michael Osipov
>Priority: Major
> Attachments: create_lock_events.sql, etl.sql, logs-data.zip,
> schema.sql
>
>
> While testing performance for in
> [https://github.com/apache/maven-resolver/pull/68|https://github.com/apache/maven-resolver/pull/68]
> , I ran into an error using rwlock-redisson. Here are the steps to reproduce
> (hopefully it's easily reproducible on your end) and the logs of the run
> (trace enabled on org.eclipse.aether) at the end :
> * `redis-cli flushall` to get a clean slate
> * Clone a repository with a fair size
> * Make 4 copy of this repository (I ran my test with 4 copies, but 2 might
> be enough?)
> * `mvn clean` on all repositories
> * run a parallel build with semaphore-redis (`mvn compile -T1C
> -Daether.syncContext.named.factory=semaphore-redisson`) on all repositories
> * `mvn clean` all repositories
> * run a parallel build with rwlock-redis (`mvn compile -T1C
> -Daether.syncContext.named.factory=rwlock-redisson`) on all repositories
> By doing this, I ran into this and the only way out was running a `redis-cli
> flushall`.
>
> The way I ran my parallel build was really dumb and simple, something like
> that :
>
> {code:java}
> cd repo1 ; mvn clean > /tmp/log1 2>&1 & cd ../repo2 ; mvn clean > /tmp/log2
> 2>&1 & cd ../repo3 ; mvn clean > /tmp/log3 2>&1 & cd ../repo4 ; mvn clean >
> /tmp/log4 2>&1 & cd .. ;
> {code}
>
>
> Let me know if you can't reproduce, I might be able to provide you with
> traces logs of the semaphore build as well.
> {code:java}
> [INFO] Redisson 3.15.6
> [INFO] 1 connections initialized for localhost/127.0.0.1:6379
> [INFO] 24 connections initialized for localhost/127.0.0.1:6379
> [TRACE] Created Redisson client with id '42934566-3759-4f73-9fbc-a2d0a8368e1f'
> [DEBUG] Using manager EnhancedLocalRepositoryManager with priority 10.0 for
> /root/.m2/repository
> [INFO] Scanning for projects...
> [TRACE] Need 1 write lock(s) for
> [artifact:com.coveo:coveo-cloud-base-service-pom:40.123.0]
> [TRACE] Acquiring write lock for
> 'artifact:com.coveo:coveo-cloud-base-service-pom:40.123.0'
> [ERROR] Internal error: org.redisson.client.RedisException: ERR Error running
> script (call to f_6306ba3bf1f563b284bed52d305fce615c6664d9): @user_script:1:
> WRONGTYPE Operation against a key holding the wrong kind of value. channel:
> [id: 0x69ea1187, L:/127.0.0.1:60800 - R:localhost/127.0.0.1:6379] command:
> (EVAL), params: [local mode = redis.call('hget', KEYS[1], 'mode'); if (mode
> == false) then redis.call('hset', KEYS[1]..., 1,
> maven:resolver:artifact:com.coveo:coveo-cloud-base-service-pom:40.123.0,
> 3, 42934566-3759-4f73-9fbc-a2d0a8368e1f:1:write] -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> org.redisson.client.RedisException: ERR Error running script (call to
> f_6306ba3bf1f563b284bed52d305fce615c6664d9): @user_script:1: WRONGTYPE
> Operation against a key holding the wrong kind of value. channel: [id:
> 0x69ea1187, L:/127.0.0.1:60800 - R:localhost/127.0.0.1:6379] command: (EVAL),
> params: [local mode = redis.call('hget', KEYS[1], 'mode'); if (mode == false)
> then redis.call('hset', KEYS[1]..., 1,
> maven:resolver:artifact:com.coveo:coveo-cloud-base-service-pom:40.123.0,
> 3, 42934566-3759-4f73-9fbc-a2d0a8368e1f:1:write]
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:120)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at
[jira] [Closed] (MNG-7185) Describe explicit and recommended version for VersionRange.createFromVersionSpec()
[
https://issues.apache.org/jira/browse/MNG-7185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-7185.
---
Fix Version/s: (was: 3.8.x-candidate)
(was: 4.0.x-candidate)
4.0.0-alpha-1
4.0.0
3.8.2
Resolution: Fixed
Fixed with
[e29a6610865f674f6d9b856c03d156074d0d2df8|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=e29a6610865f674f6d9b856c03d156074d0d2df8]
and
[176b272f30c4fbd62013b4702ab28518c21628ac|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=176b272f30c4fbd62013b4702ab28518c21628ac]
for {{maven-3.8.x}} branch.
> Describe explicit and recommended version for
> VersionRange.createFromVersionSpec()
> --
>
> Key: MNG-7185
> URL: https://issues.apache.org/jira/browse/MNG-7185
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Nils Breunese
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.8.2, 4.0.0, 4.0.0-alpha-1
>
>
> I would expect a version range for a single version to not contain any other
> versions, but it seems this is not the case, because this test fails on the
> second assertion:
> {code}
> @Test
> void range_with_single_version_should_not_contain_other_version() {
> VersionRange singleVersionRange =
> VersionRange.createFromVersionSpec("1.0.0");
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("1.0.0"))).isTrue();
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("2.0.0"))).isFalse();
> }
> {code}
> Is this a bug, or do I misinterpret what a single version range is? Does
> {{maven-artifact}} have a concept for a version range that only contains a
> single version?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] asfgit closed pull request #487: [MNG-7185] - Describe explicit and recommended version for VersionRange.createFromVersionSpec
asfgit closed pull request #487: URL: https://github.com/apache/maven/pull/487 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7185) Describe explicit and recommended version for VersionRange.createFromVersionSpec()
[
https://issues.apache.org/jira/browse/MNG-7185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7185:
Summary: Describe explicit and recommended version for
VersionRange.createFromVersionSpec() (was: Describe explicit and recommended
version for VersionRange.createFromVersionSpec)
> Describe explicit and recommended version for
> VersionRange.createFromVersionSpec()
> --
>
> Key: MNG-7185
> URL: https://issues.apache.org/jira/browse/MNG-7185
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Nils Breunese
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 4.0.x-candidate, 3.8.x-candidate
>
>
> I would expect a version range for a single version to not contain any other
> versions, but it seems this is not the case, because this test fails on the
> second assertion:
> {code}
> @Test
> void range_with_single_version_should_not_contain_other_version() {
> VersionRange singleVersionRange =
> VersionRange.createFromVersionSpec("1.0.0");
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("1.0.0"))).isTrue();
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("2.0.0"))).isFalse();
> }
> {code}
> Is this a bug, or do I misinterpret what a single version range is? Does
> {{maven-artifact}} have a concept for a version range that only contains a
> single version?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5750) Sporadic failures in concurrent build
[
https://issues.apache.org/jira/browse/MNG-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380490#comment-17380490
]
Michael Osipov commented on MNG-5750:
-
I have received build logs private where this still happens even with MNG-6843.
[~loginatnine], rwlock-gav2_19, rwlock-gav1_19, rwlock-gav1_33 are subject to
this.
> Sporadic failures in concurrent build
> -
>
> Key: MNG-5750
> URL: https://issues.apache.org/jira/browse/MNG-5750
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.1.1, 3.2.1, 3.2.2, 3.2.5
> Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux Oracle
> HotSpot JDK 7u25
> windows server 2008 x64 Oracle HotSpot JDK 7u65/8u25
>Reporter: Alexander Ashitkin
>Priority: Critical
> Fix For: waiting-for-feedback, 4.x / Backlog
>
>
> We have a large project of 300+ modules which regularly fails with different
> kind of errors in different places. The issue is reliably reproduced with
> parallel build and is not happens in single threaded. The optimal concurrency
> level for our project ~10 threads. At this level ~%20 of builds fail. To
> workaround the issue we reduced concurrency to 4 in development builds and
> reverted production build to 1 thread.
> Main point of failures:
> # Surefire ClassNotFound. Reported and investigated in SUREFIRE-1132. Points
> to a problem with MavenProject#getArtifacts - empty set unexpectedly returned.
> # Compiler - unexpected failure because of incorrect classpath (literally all
> dependencies are not on the classpath), like: {code}
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[3,30] package ...
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[4,30] package ...
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[8,25] package ...
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[9,21] package
> org.joda.time does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,37] package
> com.google.common.base does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,1] static
> import only from classes and interfaces
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,37] package
> com.google.common.base does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,1] static
> import only from classes and interfaces
> {code}
> # Jar - unexpected NPE. Reported with stack traces in MJAR-192. (assembly
> plusgin seems to be also affected)
> At this point the issue looks like problem with MavenProject#getArtifacts in
> concurrent builds.
> To help with the issue im happy to implement or evaluate any custom assembly
> to trace this down. Unfortunately i cannot submit my project - it is
> proprietary.
> Thanks in advance, Alexander
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-7185) Describe explicit and recommended version for VersionRange.createFromVersionSpec
[
https://issues.apache.org/jira/browse/MNG-7185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7185:
Fix Version/s: 3.8.x-candidate
4.0.x-candidate
> Describe explicit and recommended version for
> VersionRange.createFromVersionSpec
>
>
> Key: MNG-7185
> URL: https://issues.apache.org/jira/browse/MNG-7185
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Nils Breunese
>Priority: Minor
> Fix For: 4.0.x-candidate, 3.8.x-candidate
>
>
> I would expect a version range for a single version to not contain any other
> versions, but it seems this is not the case, because this test fails on the
> second assertion:
> {code}
> @Test
> void range_with_single_version_should_not_contain_other_version() {
> VersionRange singleVersionRange =
> VersionRange.createFromVersionSpec("1.0.0");
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("1.0.0"))).isTrue();
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("2.0.0"))).isFalse();
> }
> {code}
> Is this a bug, or do I misinterpret what a single version range is? Does
> {{maven-artifact}} have a concept for a version range that only contains a
> single version?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MNG-7185) Describe explicit and recommended version for VersionRange.createFromVersionSpec
[
https://issues.apache.org/jira/browse/MNG-7185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-7185:
---
Assignee: Michael Osipov
> Describe explicit and recommended version for
> VersionRange.createFromVersionSpec
>
>
> Key: MNG-7185
> URL: https://issues.apache.org/jira/browse/MNG-7185
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.8.1
>Reporter: Nils Breunese
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 4.0.x-candidate, 3.8.x-candidate
>
>
> I would expect a version range for a single version to not contain any other
> versions, but it seems this is not the case, because this test fails on the
> second assertion:
> {code}
> @Test
> void range_with_single_version_should_not_contain_other_version() {
> VersionRange singleVersionRange =
> VersionRange.createFromVersionSpec("1.0.0");
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("1.0.0"))).isTrue();
> assertThat(singleVersionRange.containsVersion(new
> DefaultArtifactVersion("2.0.0"))).isFalse();
> }
> {code}
> Is this a bug, or do I misinterpret what a single version range is? Does
> {{maven-artifact}} have a concept for a version range that only contains a
> single version?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6241) Load -Dstyle.color from system properties also
[
https://issues.apache.org/jira/browse/MNG-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6241:
Fix Version/s: (was: wontfix-candidate)
waiting-for-feedback
> Load -Dstyle.color from system properties also
> --
>
> Key: MNG-6241
> URL: https://issues.apache.org/jira/browse/MNG-6241
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Thorsten Glaser
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Coloured output does not look very nice in a Jenkins logfile *and* breaks
> some plugins we use, therefore I wish to disable it programmatically.
> However, looking at the source, I find it can only be disabled by passing the
> command-line options -B or -l, but not from settings.xml or via MAVEN_OPTS in
> the environment.
> I’ve worked around this by using dpkg-divert to move the mvn binary away and
> placing this…
> {{{
> # cat /usr/share/maven/bin/mvn
> #!/bin/mksh-static
> exec /usr/share/maven/bin/mvn.dpkg-dist -B "$@"
> }}}
> … in its stead, but that’s creepy at best. Please implement a setting,
> ideally for settings.xml *and* MAVEN_OPTS, to disable colour.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6241) Load -Dstyle.color from system properties also
[
https://issues.apache.org/jira/browse/MNG-6241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380487#comment-17380487
]
Michael Osipov commented on MNG-6241:
-
Would it help if Maven would respect this https://no-color.org/?
> Load -Dstyle.color from system properties also
> --
>
> Key: MNG-6241
> URL: https://issues.apache.org/jira/browse/MNG-6241
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.0
>Reporter: Thorsten Glaser
>Priority: Major
> Fix For: wontfix-candidate
>
>
> Coloured output does not look very nice in a Jenkins logfile *and* breaks
> some plugins we use, therefore I wish to disable it programmatically.
> However, looking at the source, I find it can only be disabled by passing the
> command-line options -B or -l, but not from settings.xml or via MAVEN_OPTS in
> the environment.
> I’ve worked around this by using dpkg-divert to move the mvn binary away and
> placing this…
> {{{
> # cat /usr/share/maven/bin/mvn
> #!/bin/mksh-static
> exec /usr/share/maven/bin/mvn.dpkg-dist -B "$@"
> }}}
> … in its stead, but that’s creepy at best. Please implement a setting,
> ideally for settings.xml *and* MAVEN_OPTS, to disable colour.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-enforcer] rfscholte closed pull request #90: [MENFORCER-365] - A naive way to ignore test scope
rfscholte closed pull request #90: URL: https://github.com/apache/maven-enforcer/pull/90 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] rfscholte commented on pull request #90: [MENFORCER-365] - A naive way to ignore test scope
rfscholte commented on pull request #90: URL: https://github.com/apache/maven-enforcer/pull/90#issuecomment-879757607 I'm going to close this PR as there are conflicts, most likely related to the upgrade of maven-dependency-tree. With the new conflict resolver the filtering of test-scoped dependencies will me more reliable. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] rfscholte commented on pull request #78: [MENFORCER-360] - requireUpperBoundDeps should have option to check for same major version
rfscholte commented on pull request #78: URL: https://github.com/apache/maven-enforcer/pull/78#issuecomment-879755427 I'm going to close this PR because there are conflicts and there are missing tests. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] rfscholte closed pull request #78: [MENFORCER-360] - requireUpperBoundDeps should have option to check for same major version
rfscholte closed pull request #78: URL: https://github.com/apache/maven-enforcer/pull/78 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-shared-utils] rfscholte commented on pull request #93: [MSHARED-993] Make uninstall resilient to Jansi errors
rfscholte commented on pull request #93: URL: https://github.com/apache/maven-shared-utils/pull/93#issuecomment-879665376 > > We're still trying to fix this at JAnsi. This should only be accepted if JAnsi explcitly states they won't fix it. > > There are still no reactions to [fusesource/jansi#214](https://github.com/fusesource/jansi/issues/214). Not sure what the timeline is for the proper fix. Do you maybe have any other insights @rfscholte ? We're working on it as we have more ways to get direct contact with the maintainer(s). But I agree, it takes more time, must be the summer ;) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-1932) Periodic parallel execution of tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17380378#comment-17380378
]
EVGENII STRATOVICH commented on SUREFIRE-1932:
--
[~tibordigana], good day! I've just answered!
Thank you!
> Periodic parallel execution of tests
>
>
> Key: SUREFIRE-1932
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1932
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Surefire Plugin, process forking
>Affects Versions: 3.0.0-M2, 3.0.0-M1, 3.0.0-M3, 3.0.0-M4, 3.0.0-M5
>Reporter: EVGENII STRATOVICH
>Priority: Trivial
>
> For parallel testing is used next stack of technologies: java 8 (openjdk
> version "1.8.0_292", OpenJDK Runtime Environment (build 1.8.0_292-b10),
> OpenJDK 64-Bit Server VM (build 25.292-b10, mixed mode)), Jenkins, Selenium,
> Selenide, Selenoid etc.
> From time to time during execution I encounter different problem associated
> with maven surefire. I perform parallel testing using Jenkins and jenkins
> file:
>
> {code:java}
> stage('First suite'){
> parallel {
> stage('1 test'){
> }
> stage('2 test'){
> }
> }
> }
> {code}
> but periodically got error and failed stage due to failed test. Fragment of
> trace with error:
> {code:java}
> ExecutionException Error creating properties files for forking
> org.apache.maven.surefire.booter.SurefireBooterForkException:
> ExecutionException Error creating properties files for forking at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:532)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnceMultiple(ForkStarter.java:405)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:321)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:266)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1314)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1159)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:932)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305) at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192) at
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105) at
> org.apache.maven.cli.MavenCli.execute(MavenCli.java:957) at
> org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289) at
> org.apache.maven.cli.MavenCli.main(MavenCli.java:193) at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498) at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException:
> Error creating properties files for forking at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:604)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.access$700(ForkStarter.java:121)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter$1.call(ForkStarter.java:393)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter$1.call(ForkStarter.java:370)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) at
>
[jira] [Updated] (SUREFIRE-1932) Periodic parallel execution of tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
EVGENII STRATOVICH updated SUREFIRE-1932:
-
Description:
For parallel testing is used next stack of technologies: java 8 (openjdk
version "1.8.0_292", OpenJDK Runtime Environment (build 1.8.0_292-b10), OpenJDK
64-Bit Server VM (build 25.292-b10, mixed mode)), Jenkins, Selenium, Selenide,
Selenoid etc.
>From time to time during execution I encounter different problem associated
>with maven surefire. I perform parallel testing using Jenkins and jenkins file:
{code:java}
stage('First suite'){
parallel {
stage('1 test'){
}
stage('2 test'){
}
}
}
{code}
but periodically got error and failed stage due to failed test. Fragment of
trace with error:
{code:java}
ExecutionException Error creating properties files for forking
org.apache.maven.surefire.booter.SurefireBooterForkException:
ExecutionException Error creating properties files for forking at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:532)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnceMultiple(ForkStarter.java:405)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:321)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:266)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1314)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1159)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:932)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305) at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192) at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105) at
org.apache.maven.cli.MavenCli.execute(MavenCli.java:957) at
org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289) at
org.apache.maven.cli.MavenCli.main(MavenCli.java:193) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498) at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException: Error
creating properties files for forking at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:604)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.access$700(ForkStarter.java:121)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter$1.call(ForkStarter.java:393)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter$1.call(ForkStarter.java:370)
at java.util.concurrent.FutureTask.run(FutureTask.java:266) at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748) Caused by: java.io.IOException: No
such file or directory at java.io.UnixFileSystem.createFileExclusively(Native
Method) at java.io.File.createTempFile(File.java:2063) at
org.apache.maven.surefire.booter.SystemPropertyManager.writePropertiesFile(SystemPropertyManager.java:77)
at
org.apache.maven.plugin.surefire.booterclient.BooterSerializer.serialize(BooterSerializer.java:187)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:585)
... 7 more
{code}
As well I described my problem here in stackoverflow but with another trace
(URL is attached).
