[jira] [Updated] (SUREFIRE-1808) OutOfMemoryError running with TestNG
[
https://issues.apache.org/jira/browse/SUREFIRE-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jingfei Hu updated SUREFIRE-1808:
-
Description:
Hi team,
We've been suffering OutOfMemory intermittently in our test labs recently. The
call stack is below
{noformat}
[ERROR] Java heap space -> [Help 1]
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3332)
at
java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)
at java.lang.StringBuilder.append(StringBuilder.java:136)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter$CloseableCloser.run(ForkStarter.java:200)
at
org.apache.maven.surefire.shade.common.org.apache.maven.shared.utils.cli.CommandLineUtils$1.call(CommandLineUtils.java:301)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:615)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1161)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1002)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:848)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
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:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
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:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229){noformat}
Our test case count is +4k and still increasing, and pass rate is around 95%
for each execution. The OOM error is not always reproducible. And we set memory
dump parameters, but there is no dump file generated when it occurs.
The line of code throwing the exception is below.
!image-2020-12-29-15-16-28-566.png|width=763,height=460!
More version information:
maven-surefire-plugin: 3.0.0-M3
testng: 6.4
maven: 3.2.5
was:
Hi team,
We've been suffering OutOfMemory intermittently in our test labs recently. The
call stack is below
{noformat}
[ERROR] Java heap space -> [Help 1]
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3332)
at
java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)
at java.lang.StringBuilder.append(StringBuilder.java:136)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter$CloseableCloser.run(ForkStarter.java:204)
at
org.apache.maven.surefire.shade.common.org.apache.maven.shared.utils.cli.CommandLineUtils$1.call(CommandLineUtils.java:301)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:615)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1161)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1002)
at
[jira] [Updated] (SUREFIRE-1808) OutOfMemoryError running with TestNG
[
https://issues.apache.org/jira/browse/SUREFIRE-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jingfei Hu updated SUREFIRE-1808:
-
Attachment: image-2020-12-29-15-16-28-566.png
> OutOfMemoryError running with TestNG
>
>
> Key: SUREFIRE-1808
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1808
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, TestNG support
>Affects Versions: 3.0.0-M3
> Environment: OS: Linux
>Reporter: Jingfei Hu
>Priority: Major
> Labels: OOM, TestNG, surefire
> Attachments: image-2020-12-29-13-31-31-539.png,
> image-2020-12-29-13-58-44-076.png, image-2020-12-29-15-16-28-566.png
>
>
> Hi team,
> We've been suffering OutOfMemory intermittently in our test labs recently.
> The call stack is below
> {noformat}
> [ERROR] Java heap space -> [Help 1]
> java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:3332)
> at
> java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)
> at java.lang.StringBuilder.append(StringBuilder.java:136)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter$CloseableCloser.run(ForkStarter.java:204)
> at
> org.apache.maven.surefire.shade.common.org.apache.maven.shared.utils.cli.CommandLineUtils$1.call(CommandLineUtils.java:301)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:615)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1161)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1002)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:848)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> 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:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> 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:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229){noformat}
>
> Our test case count is +4k and still increasing, and pass rate is around 95%
> for each execution. The OOM error is not always reproducible. And we set
> memory dump parameters, but there is no dump file generated when it occurs.
> The line of code throwing the exception is below.
> !image-2020-12-29-13-58-44-076.png|width=681,height=331!
>
> More version information:
> maven-surefire-plugin: 3.0.0-M3
> testng: 6.4
> maven: 3.2.5
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1808) OutOfMemoryError running with TestNG
[
https://issues.apache.org/jira/browse/SUREFIRE-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jingfei Hu updated SUREFIRE-1808:
-
Attachment: (was: image-2020-06-24-14-37-45-038.png)
> OutOfMemoryError running with TestNG
>
>
> Key: SUREFIRE-1808
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1808
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, TestNG support
>Affects Versions: 3.0.0-M3
> Environment: OS: Linux
>Reporter: Jingfei Hu
>Priority: Major
> Labels: OOM, TestNG, surefire
> Attachments: image-2020-12-29-13-31-31-539.png,
> image-2020-12-29-13-58-44-076.png, image-2020-12-29-15-16-28-566.png
>
>
> Hi team,
> We've been suffering OutOfMemory intermittently in our test labs recently.
> The call stack is below
> {noformat}
> [ERROR] Java heap space -> [Help 1]
> java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:3332)
> at
> java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)
> at java.lang.StringBuilder.append(StringBuilder.java:136)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter$CloseableCloser.run(ForkStarter.java:200)
> at
> org.apache.maven.surefire.shade.common.org.apache.maven.shared.utils.cli.CommandLineUtils$1.call(CommandLineUtils.java:301)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:615)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1161)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1002)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:848)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> 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:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> 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:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229){noformat}
>
> Our test case count is +4k and still increasing, and pass rate is around 95%
> for each execution. The OOM error is not always reproducible. And we set
> memory dump parameters, but there is no dump file generated when it occurs.
> The line of code throwing the exception is below.
> !image-2020-12-29-15-16-28-566.png|width=763,height=460!
>
> More version information:
> maven-surefire-plugin: 3.0.0-M3
> testng: 6.4
> maven: 3.2.5
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1808) OutOfMemoryError running with TestNG
[
https://issues.apache.org/jira/browse/SUREFIRE-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255829#comment-17255829
]
Jingfei Hu commented on SUREFIRE-1808:
--
[~tibordigana] Thanks a lot for your reply, but i still think the call stack
should provide me some trace to root cause. And we are finally able to get a
dump of the parent process and locate where the heap is occupied. See below
screenshot.
!image-2020-12-29-13-31-31-539.png|width=533,height=134!
We can see it's an object of
org.apache.maven.plugin.surefire.booterclient.output.MultipleFailureException
which is a subclass of IOException consumes a lot of memory. And we keep
looking into what is inside of the object and find out the content is all the
logs printed out by test execution in the form of thousands of RuntimeException
objects residing the in the linked queue of MultipleFailureException. Below is
the method getLocalizedMessage of MultipleFailureException which I think
contributes to OOM though the call stack says it's line of code 204.
{code:java}
@Override
public String getLocalizedMessage()
{
StringBuilder messages = new StringBuilder();
for ( Throwable exception : exceptions )
{
if ( messages.length() != 0 )
{
messages.append( '\n' );
}
String message = exception.getLocalizedMessage();
messages.append( message == null ? exception.toString() : message );
}
return messages.toString();
}
{code}
So my question becomes
# Why do the logs printed out by tests end up with RuntimeException and
finally all being put in the linked queue of MultipleFailureException? Is it a
behavior of the forked process of TestNG or maven-surefire-plugin?
# How to workaround this? 3.0.0-M5 still has this issue.
> OutOfMemoryError running with TestNG
>
>
> Key: SUREFIRE-1808
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1808
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, TestNG support
>Affects Versions: 3.0.0-M3
> Environment: OS: Linux
>Reporter: Jingfei Hu
>Priority: Major
> Labels: OOM, TestNG, surefire
> Attachments: image-2020-06-24-14-37-45-038.png,
> image-2020-12-29-13-31-31-539.png, image-2020-12-29-13-58-44-076.png
>
>
> Hi team,
> We've been suffering OutOfMemory intermittently in our test labs recently.
> The call stack is below
> {noformat}
> [ERROR] Java heap space -> [Help 1]
> java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:3332)
> at
> java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)
> at java.lang.StringBuilder.append(StringBuilder.java:136)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter$CloseableCloser.run(ForkStarter.java:204)
> at
> org.apache.maven.surefire.shade.common.org.apache.maven.shared.utils.cli.CommandLineUtils$1.call(CommandLineUtils.java:301)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:615)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1161)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1002)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:848)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> 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:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> at
[jira] [Updated] (SUREFIRE-1808) OutOfMemoryError running with TestNG
[
https://issues.apache.org/jira/browse/SUREFIRE-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jingfei Hu updated SUREFIRE-1808:
-
Description:
Hi team,
We've been suffering OutOfMemory intermittently in our test labs recently. The
call stack is below
{noformat}
[ERROR] Java heap space -> [Help 1]
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3332)
at
java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)
at java.lang.StringBuilder.append(StringBuilder.java:136)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter$CloseableCloser.run(ForkStarter.java:204)
at
org.apache.maven.surefire.shade.common.org.apache.maven.shared.utils.cli.CommandLineUtils$1.call(CommandLineUtils.java:301)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:615)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1161)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1002)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:848)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
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:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
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:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229){noformat}
Our test case count is +4k and still increasing, and pass rate is around 95%
for each execution. The OOM error is not always reproducible. And we set memory
dump parameters, but there is no dump file generated when it occurs.
The line of code throwing the exception is below.
!image-2020-12-29-13-58-44-076.png|width=681,height=331!
More version information:
maven-surefire-plugin: 3.0.0-M3
testng: 6.4
maven: 3.2.5
was:
Hi team,
We've been suffering OutOfMemory intermittently in our test labs recently. The
call stack is below
{noformat}
[ERROR] Java heap space -> [Help 1]
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3332)
at
java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)
at java.lang.StringBuilder.append(StringBuilder.java:136)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter$CloseableCloser.run(ForkStarter.java:204)
at
org.apache.maven.surefire.shade.common.org.apache.maven.shared.utils.cli.CommandLineUtils$1.call(CommandLineUtils.java:301)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:615)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1161)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1002)
at
[jira] [Updated] (SUREFIRE-1808) OutOfMemoryError running with TestNG
[
https://issues.apache.org/jira/browse/SUREFIRE-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jingfei Hu updated SUREFIRE-1808:
-
Attachment: image-2020-12-29-13-58-44-076.png
> OutOfMemoryError running with TestNG
>
>
> Key: SUREFIRE-1808
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1808
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, TestNG support
>Affects Versions: 3.0.0-M3
> Environment: OS: Linux
>Reporter: Jingfei Hu
>Priority: Major
> Labels: OOM, TestNG, surefire
> Attachments: image-2020-06-24-14-37-45-038.png,
> image-2020-12-29-13-31-31-539.png, image-2020-12-29-13-58-44-076.png
>
>
> Hi team,
> We've been suffering OutOfMemory intermittently in our test labs recently.
> The call stack is below
> {noformat}
> [ERROR] Java heap space -> [Help 1]
> java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:3332)
> at
> java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)
> at java.lang.StringBuilder.append(StringBuilder.java:136)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter$CloseableCloser.run(ForkStarter.java:204)
> at
> org.apache.maven.surefire.shade.common.org.apache.maven.shared.utils.cli.CommandLineUtils$1.call(CommandLineUtils.java:301)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:615)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1161)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1002)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:848)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> 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:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> 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:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229){noformat}
>
> Our test case count is +4k and still increasing, and pass rate is around 95%
> for each execution. The OOM error is not always reproducible. And we set
> memory dump parameters, but there is no dump file generated when it occurs.
> The line of code throwing the exception is below.
> !image-2020-06-24-14-37-45-038.png|width=599,height=313!
>
> More version information:
> maven-surefire-plugin: 3.0.0-M3
> testng: 6.4
> maven: 3.2.5
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1808) OutOfMemoryError running with TestNG
[
https://issues.apache.org/jira/browse/SUREFIRE-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jingfei Hu updated SUREFIRE-1808:
-
Attachment: image-2020-12-29-13-31-31-539.png
> OutOfMemoryError running with TestNG
>
>
> Key: SUREFIRE-1808
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1808
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, TestNG support
>Affects Versions: 3.0.0-M3
> Environment: OS: Linux
>Reporter: Jingfei Hu
>Priority: Major
> Labels: OOM, TestNG, surefire
> Attachments: image-2020-06-24-14-37-45-038.png,
> image-2020-12-29-13-31-31-539.png
>
>
> Hi team,
> We've been suffering OutOfMemory intermittently in our test labs recently.
> The call stack is below
> {noformat}
> [ERROR] Java heap space -> [Help 1]
> java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:3332)
> at
> java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)
> at java.lang.StringBuilder.append(StringBuilder.java:136)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter$CloseableCloser.run(ForkStarter.java:204)
> at
> org.apache.maven.surefire.shade.common.org.apache.maven.shared.utils.cli.CommandLineUtils$1.call(CommandLineUtils.java:301)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:615)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1161)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1002)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:848)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> 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:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> 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:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229){noformat}
>
> Our test case count is +4k and still increasing, and pass rate is around 95%
> for each execution. The OOM error is not always reproducible. And we set
> memory dump parameters, but there is no dump file generated when it occurs.
> The line of code throwing the exception is below.
> !image-2020-06-24-14-37-45-038.png|width=599,height=313!
>
> More version information:
> maven-surefire-plugin: 3.0.0-M3
> testng: 6.4
> maven: 3.2.5
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1808) OutOfMemoryError running with TestNG
[
https://issues.apache.org/jira/browse/SUREFIRE-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jingfei Hu updated SUREFIRE-1808:
-
Description:
Hi team,
We've been suffering OutOfMemory intermittently in our test labs recently. The
call stack is below
{noformat}
[ERROR] Java heap space -> [Help 1]
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3332)
at
java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)
at java.lang.StringBuilder.append(StringBuilder.java:136)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter$CloseableCloser.run(ForkStarter.java:204)
at
org.apache.maven.surefire.shade.common.org.apache.maven.shared.utils.cli.CommandLineUtils$1.call(CommandLineUtils.java:301)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:615)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1161)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1002)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:848)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
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:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
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:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229){noformat}
Our test case count is +4k and still increasing, and pass rate is around 95%
for each execution. The OOM error is not always reproducible. And we set memory
dump parameters, but there is no dump file generated when it occurs.
The line of code throwing the exception is below.
!image-2020-06-24-14-37-45-038.png|width=599,height=313!
More version information:
maven-surefire-plugin: 3.0.0-M3
testng: 6.4
maven: 3.2.5
was:
Hi team,
We've been suffering OutOfMemory intermittently in our test labs recently. The
call stack is below
[ERROR] Java heap space -> [Help 1][ERROR] Java heap space -> [Help
1]java.lang.OutOfMemoryError: Java heap space at
java.util.Arrays.copyOf(Arrays.java:3332) at
java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448) at
java.lang.StringBuilder.append(StringBuilder.java:136) at
org.apache.maven.plugin.surefire.booterclient.ForkStarter$CloseableCloser.run(ForkStarter.java:204)
at
org.apache.maven.surefire.shade.common.org.apache.maven.shared.utils.cli.CommandLineUtils$1.call(CommandLineUtils.java:301)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:615)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283)
at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1161)
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1002)
at
[jira] [Created] (MNGSITE-438) Add guide for Large Scale Centralized Deployments
Phil Clay created MNGSITE-438: - Summary: Add guide for Large Scale Centralized Deployments Key: MNGSITE-438 URL: https://issues.apache.org/jira/browse/MNGSITE-438 Project: Maven Project Web Site Issue Type: Improvement Reporter: Phil Clay As recommended by https://github.com/apache/maven-deploy-plugin/pull/15#issuecomment-750933613, add a guide for large scale centralized deployments. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARCHETYPE-612) Required property interactive prompt ordering incorrect when reassigning default for a "core" property
[
https://issues.apache.org/jira/browse/ARCHETYPE-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255762#comment-17255762
]
David Hutchison commented on ARCHETYPE-612:
---
PR now created: https://github.com/apache/maven-archetype/pull/61
> Required property interactive prompt ordering incorrect when reassigning
> default for a "core" property
> --
>
> Key: ARCHETYPE-612
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-612
> Project: Maven Archetype
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.2.0
>Reporter: David Hutchison
>Priority: Minor
>
> The interactive archetype project generation attempts to be smart in ordering
> required properties so that when a default value for one property includes a
> reference to another, they are asked for in the correct order. This also
> however tries to ask the "core" properties (groupId, archetypeId, version,
> and package) in a fixed order, and any others in alphabetical order, if they
> do not have dependencies.
>
> I was trying to setup an archetype with a couple of prompts which would be
> referenced in the default values for groupId, archetypeId and package.
> Basically attempting to standardise the setup for these based on the
> "application" and "database" the repository was for, so we would have:
> * groupId: {{com.example.${application}.data}}
> * archetypeId: {{${database}}}
> * package: {{com.example.${application}.data.${database}}}
>
> When doing this however, the package is prompted for before the value it's
> default depends on.
>
> This snippet from archetype-metadata.xml will trigger the issue as a test
> {code:java}
>
>
>
> com.devwithimagination
>
>
> test-${a-prop}
>
>
> ${groupId}.${artifactId}.${z-prop}
>
>
>
> {code}
> Running this archetype interactively will output something like this:
> {code:java}
> $ mvn archetype:generate -DarchetypeArtifactId=archetype-test
> -DarchetypeGroupId=com.devwithimagination.archetypes
> [INFO] Generating project in Interactive mode
> [INFO] Archetype
> [com.devwithimagination.archetypes:archetype-test:1.0-SNAPSHOT] found in
> catalog local
> [INFO] Using property: groupId = com.devwithimagination
> Define value for property 'version' 1.0-SNAPSHOT: :
> Define value for property 'package'
> com.devwithimagination.archetypes.archetype-test.${z-prop}: :
> Define value for property 'a-prop': 123
> Define value for property 'artifactId' test-123: :
> Define value for property 'z-prop':
> {code}
> So {{package}} was prompted for before {{artifactId}} and {{z-prop}} which it
> needed for the default value. In typing this up I just noticed it used the
> {{archetypeArtifactId}} in the default value instead.
> I have got a failing test case for {{RequiredPropertyComparatorTest}} which
> shows the comparator isn't performing the sort correctly.
> A possible solution for this could be what ARCHETYPE-443 proposed, and
> respect the property order defined in the archetype metadata file. Any "core"
> required properties could still be prompted for in their default order,
> unless the archetype author had also included them in
> {{archetype-metadata.xml}}. With that change, it would be up to the archetype
> author to ensure that properties are correctly ordered. ARCHETYPE-562 points
> to other issues with this sort.
> I have been having a look at making the sort smarter, but so far I've not
> been able to keep the name based ordering working while fixing the property
> dependency based sort.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-archetype] dhutchison opened a new pull request #61: [ARCHETYPE-612] Fixes to required property sort approach
dhutchison opened a new pull request #61: URL: https://github.com/apache/maven-archetype/pull/61 Fix for [ARCHETYPE-612](https://issues.apache.org/jira/browse/ARCHETYPE-612). This implementation will now respect the required property order defined by the archetype author, unless they have interdependencies which are not ordered correctly. If properties are detected to be in the wrong order, it will use a (slightly simplistic) graph traversal approach to find a working sort order. This removes the previous behaviour where it would try to sort based on dependencies, while aiming for alphabetic property order with fixed core property order. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (ARCHETYPE-612) Required property interactive prompt ordering incorrect when reassigning default for a "core" property
[
https://issues.apache.org/jira/browse/ARCHETYPE-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255760#comment-17255760
]
David Hutchison commented on ARCHETYPE-612:
---
Thinking about this more, this feature to sort was clearly added for some
reason so removing it would be a breaking change now (as much as that would be
simpler).
I've got a (hopefully) better solution in [this
branch|https://github.com/dhutchison/maven-archetype/tree/bug/archetype-612-sort-required-properties]
(I'll create a PR for it later on). This will use the order defined by the
archetype order, unless it detects that there are dependencies which are in the
wrong order. If there are properties in the wrong order, it will perform a sort
using some graph traversal to find one that works. It is a bit of a simplistic
implementation but it passes tests for my problem case and the original sort
tests which were already in the project.
> Required property interactive prompt ordering incorrect when reassigning
> default for a "core" property
> --
>
> Key: ARCHETYPE-612
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-612
> Project: Maven Archetype
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.2.0
>Reporter: David Hutchison
>Priority: Minor
>
> The interactive archetype project generation attempts to be smart in ordering
> required properties so that when a default value for one property includes a
> reference to another, they are asked for in the correct order. This also
> however tries to ask the "core" properties (groupId, archetypeId, version,
> and package) in a fixed order, and any others in alphabetical order, if they
> do not have dependencies.
>
> I was trying to setup an archetype with a couple of prompts which would be
> referenced in the default values for groupId, archetypeId and package.
> Basically attempting to standardise the setup for these based on the
> "application" and "database" the repository was for, so we would have:
> * groupId: {{com.example.${application}.data}}
> * archetypeId: {{${database}}}
> * package: {{com.example.${application}.data.${database}}}
>
> When doing this however, the package is prompted for before the value it's
> default depends on.
>
> This snippet from archetype-metadata.xml will trigger the issue as a test
> {code:java}
>
>
>
> com.devwithimagination
>
>
> test-${a-prop}
>
>
> ${groupId}.${artifactId}.${z-prop}
>
>
>
> {code}
> Running this archetype interactively will output something like this:
> {code:java}
> $ mvn archetype:generate -DarchetypeArtifactId=archetype-test
> -DarchetypeGroupId=com.devwithimagination.archetypes
> [INFO] Generating project in Interactive mode
> [INFO] Archetype
> [com.devwithimagination.archetypes:archetype-test:1.0-SNAPSHOT] found in
> catalog local
> [INFO] Using property: groupId = com.devwithimagination
> Define value for property 'version' 1.0-SNAPSHOT: :
> Define value for property 'package'
> com.devwithimagination.archetypes.archetype-test.${z-prop}: :
> Define value for property 'a-prop': 123
> Define value for property 'artifactId' test-123: :
> Define value for property 'z-prop':
> {code}
> So {{package}} was prompted for before {{artifactId}} and {{z-prop}} which it
> needed for the default value. In typing this up I just noticed it used the
> {{archetypeArtifactId}} in the default value instead.
> I have got a failing test case for {{RequiredPropertyComparatorTest}} which
> shows the comparator isn't performing the sort correctly.
> A possible solution for this could be what ARCHETYPE-443 proposed, and
> respect the property order defined in the archetype metadata file. Any "core"
> required properties could still be prompted for in their default order,
> unless the archetype author had also included them in
> {{archetype-metadata.xml}}. With that change, it would be up to the archetype
> author to ensure that properties are correctly ordered. ARCHETYPE-562 points
> to other issues with this sort.
> I have been having a look at making the sort smarter, but so far I've not
> been able to keep the name based ordering working while fixing the property
> dependency based sort.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DOXIA-616) Markdown: Properly expose the language specified in fenced code blocks
[
https://issues.apache.org/jira/browse/DOXIA-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255753#comment-17255753
]
ASF GitHub Bot commented on DOXIA-616:
--
bertysentry commented on a change in pull request #49:
URL: https://github.com/apache/maven-doxia/pull/49#discussion_r549525703
##
File path:
doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java
##
@@ -24,27 +24,33 @@
import com.vladsch.flexmark.util.ast.Node;
import com.vladsch.flexmark.ast.util.TextCollectingVisitor;
import com.vladsch.flexmark.html.HtmlRenderer;
-import com.vladsch.flexmark.profiles.pegdown.Extensions;
-import com.vladsch.flexmark.profiles.pegdown.PegdownOptionsAdapter;
-import com.vladsch.flexmark.util.builder.Extension;
-import com.vladsch.flexmark.util.options.MutableDataHolder;
-import org.apache.commons.lang3.StringEscapeUtils;
-import org.apache.commons.lang3.StringUtils;
+import com.vladsch.flexmark.parser.ParserEmulationProfile;
+import com.vladsch.flexmark.util.options.MutableDataSet;
+import com.vladsch.flexmark.ext.escaped.character.EscapedCharacterExtension;
+import com.vladsch.flexmark.ext.abbreviation.AbbreviationExtension;
+import com.vladsch.flexmark.ext.autolink.AutolinkExtension;
+import com.vladsch.flexmark.ext.definition.DefinitionExtension;
+import com.vladsch.flexmark.ext.typographic.TypographicExtension;
+import com.vladsch.flexmark.ext.tables.TablesExtension;
+import com.vladsch.flexmark.ext.wikilink.WikiLinkExtension;
+import com.vladsch.flexmark.ext.gfm.strikethrough.StrikethroughExtension;
+
+import org.apache.commons.io.input.CharSequenceReader;
Review comment:
I took the liberty to include Commons IO to convert a *StringBuilder* to
a *Reader* without going through a *String*. Let me know if that is overkill
and you prefer to not to use Commons IO. Thanks!
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Markdown: Properly expose the language specified in fenced code blocks
> --
>
> Key: DOXIA-616
> URL: https://issues.apache.org/jira/browse/DOXIA-616
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.8, 1.9, 1.9.1
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> Writers can specify the language used in a fenced code block (typically for
> syntax highlighting), as in the example below:
> {code}
> ```java
> System.out.println("Beautiful\n");
> ```
> {code}
> Currently, the Doxia module for Markdown does not expose this information
> ("java") in the produced HTML, so a Maven skin (or frontend renderer) cannot
> leverage it.
> Produced HTML:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> Wanted result:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> h1. Specification
> Un-comment this block:
> https://github.com/apache/maven-doxia/blob/c439714e8f4a9e86f9962ac6be9a0077ae9b4d30/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer.java#L103
> This should do the trick.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-doxia] bertysentry commented on a change in pull request #49: [DOXIA-616]
bertysentry commented on a change in pull request #49: URL: https://github.com/apache/maven-doxia/pull/49#discussion_r549525703 ## File path: doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/MarkdownParser.java ## @@ -24,27 +24,33 @@ import com.vladsch.flexmark.util.ast.Node; import com.vladsch.flexmark.ast.util.TextCollectingVisitor; import com.vladsch.flexmark.html.HtmlRenderer; -import com.vladsch.flexmark.profiles.pegdown.Extensions; -import com.vladsch.flexmark.profiles.pegdown.PegdownOptionsAdapter; -import com.vladsch.flexmark.util.builder.Extension; -import com.vladsch.flexmark.util.options.MutableDataHolder; -import org.apache.commons.lang3.StringEscapeUtils; -import org.apache.commons.lang3.StringUtils; +import com.vladsch.flexmark.parser.ParserEmulationProfile; +import com.vladsch.flexmark.util.options.MutableDataSet; +import com.vladsch.flexmark.ext.escaped.character.EscapedCharacterExtension; +import com.vladsch.flexmark.ext.abbreviation.AbbreviationExtension; +import com.vladsch.flexmark.ext.autolink.AutolinkExtension; +import com.vladsch.flexmark.ext.definition.DefinitionExtension; +import com.vladsch.flexmark.ext.typographic.TypographicExtension; +import com.vladsch.flexmark.ext.tables.TablesExtension; +import com.vladsch.flexmark.ext.wikilink.WikiLinkExtension; +import com.vladsch.flexmark.ext.gfm.strikethrough.StrikethroughExtension; + +import org.apache.commons.io.input.CharSequenceReader; Review comment: I took the liberty to include Commons IO to convert a *StringBuilder* to a *Reader* without going through a *String*. Let me know if that is overkill and you prefer to not to use Commons IO. Thanks! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (DOXIA-616) Markdown: Properly expose the language specified in fenced code blocks
[
https://issues.apache.org/jira/browse/DOXIA-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255752#comment-17255752
]
ASF GitHub Bot commented on DOXIA-616:
--
bertysentry opened a new pull request #49:
URL: https://github.com/apache/maven-doxia/pull/49
Broad update to **doxia-module-markdown**
* Properly exposed language class in fenced code blocks
* Re-implemented metadata processing
* Added unit tests
* Added integration tests (with maven-site-plugin)
* Fixed *XhtmlBaseParser* and *XhtmlBaseSink* to properly expose attributes
of the PRE and CODE elements
* Fixed *AbstractModuleTest* to use UTF-8 for input files
* Bonus: Fixed DOXIA-542
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Markdown: Properly expose the language specified in fenced code blocks
> --
>
> Key: DOXIA-616
> URL: https://issues.apache.org/jira/browse/DOXIA-616
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.8, 1.9, 1.9.1
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> Writers can specify the language used in a fenced code block (typically for
> syntax highlighting), as in the example below:
> {code}
> ```java
> System.out.println("Beautiful\n");
> ```
> {code}
> Currently, the Doxia module for Markdown does not expose this information
> ("java") in the produced HTML, so a Maven skin (or frontend renderer) cannot
> leverage it.
> Produced HTML:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> Wanted result:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> h1. Specification
> Un-comment this block:
> https://github.com/apache/maven-doxia/blob/c439714e8f4a9e86f9962ac6be9a0077ae9b4d30/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer.java#L103
> This should do the trick.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-ejb-plugin] elharo merged pull request #14: remove deprecation warnings by not stubbing value class
elharo merged pull request #14: URL: https://github.com/apache/maven-ejb-plugin/pull/14 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MEAR-295) Require Maven 3.1.1
[ https://issues.apache.org/jira/browse/MEAR-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MEAR-295. - Resolution: Fixed > Require Maven 3.1.1 > --- > > Key: MEAR-295 > URL: https://issues.apache.org/jira/browse/MEAR-295 > Project: Maven EAR Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.2.0 > > > Upgrade prerequisites for the plugin to Maven 3.1.1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-ejb-plugin] elharo merged pull request #13: remove dependency on AssertJ
elharo merged pull request #13: URL: https://github.com/apache/maven-ejb-plugin/pull/13 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ejb-plugin] elharo merged pull request #12: ignore versions backup files
elharo merged pull request #12: URL: https://github.com/apache/maven-ejb-plugin/pull/12 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MEAR-295) Require Maven 3.1.1
[ https://issues.apache.org/jira/browse/MEAR-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255721#comment-17255721 ] Hudson commented on MEAR-295: - Build succeeded in Jenkins: Maven » Maven TLP » maven-ear-plugin » master #58 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/master/58/ > Require Maven 3.1.1 > --- > > Key: MEAR-295 > URL: https://issues.apache.org/jira/browse/MEAR-295 > Project: Maven EAR Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.2.0 > > > Upgrade prerequisites for the plugin to Maven 3.1.1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-resolver] cstamas commented on a change in pull request #77: [MRESOLVER-145] SyncContext implementations
cstamas commented on a change in pull request #77:
URL: https://github.com/apache/maven-resolver/pull/77#discussion_r549481196
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/synccontext/SyncContextFactoryAdapter.java
##
@@ -0,0 +1,272 @@
+package org.eclipse.aether.internal.impl.synccontext;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.SyncContext;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.metadata.Metadata;
+import org.eclipse.aether.named.NamedLock;
+import org.eclipse.aether.named.NamedLockFactory;
+import org.eclipse.aether.util.ChecksumUtils;
+import org.eclipse.aether.util.ConfigUtils;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import java.io.File;
+import java.net.InetAddress;
+import java.net.UnknownHostException;
+import java.nio.charset.StandardCharsets;
+import java.util.ArrayDeque;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.Map;
+import java.util.TreeSet;
+import java.util.concurrent.TimeUnit;
+
+/**
+ * Adapter to adapt {@link NamedLockFactory} and {@link NamedLock} to {@link
SyncContext}.
+ */
+public final class SyncContextFactoryAdapter
+{
+private static final String DEFAULT_DISCRIMINATOR_DIGEST =
"da39a3ee5e6b4b0d3255bfef95601890afd80709";
+
+private static final String DEFAULT_HOSTNAME = "localhost";
+
+private static final Logger LOGGER = LoggerFactory.getLogger(
SyncContextFactoryAdapter.class );
+
+private final NamedLockFactory namedLockFactory;
+
+private final long time;
+
+private final TimeUnit timeUnit;
+
+private final String hostname;
+
+public SyncContextFactoryAdapter( final NamedLockFactory namedLockFactory,
+ final long time,
+ final TimeUnit timeUnit )
+{
+this.namedLockFactory = namedLockFactory;
+this.time = time;
+this.timeUnit = timeUnit;
+this.hostname = getHostname();
+}
+
+private String getHostname()
+{
+try
+{
+return InetAddress.getLocalHost().getHostName();
+}
+catch ( UnknownHostException e )
+{
+LOGGER.warn( "Failed to get hostname, using '{}'",
DEFAULT_HOSTNAME, e );
+return DEFAULT_HOSTNAME;
+}
+}
+
+public SyncContext newInstance( final RepositorySystemSession session,
final boolean shared )
+{
+return new AdaptedLockSyncContext( session, hostname,
namedLockFactory, time, timeUnit, shared );
+}
+
+public void shutdown()
+{
+namedLockFactory.shutdown();
+}
+
+private static class AdaptedLockSyncContext
+implements SyncContext
+{
+private static final String CONFIG_PROP_DISCRIMINATOR =
"aether.syncContext.named.discriminator";
+
+private static final String KEY_PREFIX = "mvn:resolver:";
+
+private static final Logger LOGGER = LoggerFactory.getLogger(
AdaptedLockSyncContext.class );
+
+private final RepositorySystemSession session;
+
+private final String hostname;
+
+private final NamedLockFactory namedLockFactory;
+
+private final long time;
+
+private final TimeUnit timeUnit;
+
+private final boolean shared;
+
+private final ArrayDeque locks;
+
+private AdaptedLockSyncContext( final RepositorySystemSession session,
+final String hostname,
+final NamedLockFactory
namedLockFactory,
+final long time,
+final TimeUnit timeUnit,
+final boolean shared )
+{
+this.session = session;
+this.hostname = hostname;
+this.namedLockFactory = namedLockFactory;
+this.time = time;
+this.timeUnit = timeUnit;
+this.shared = shared;
+this.locks = new ArrayDeque<>();
+}
+
+@Override
+public
[jira] [Commented] (MEAR-295) Require Maven 3.1.1
[ https://issues.apache.org/jira/browse/MEAR-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255718#comment-17255718 ] Sylwester Lachiewicz commented on MEAR-295: --- Done in [c5724c6f35b5e9c862564f39178497126bbf9694|https://gitbox.apache.org/repos/asf?p=maven-ear-plugin.git;a=commit;h=c5724c6f35b5e9c862564f39178497126bbf9694] > Require Maven 3.1.1 > --- > > Key: MEAR-295 > URL: https://issues.apache.org/jira/browse/MEAR-295 > Project: Maven EAR Plugin > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.2.0 > > > Upgrade prerequisites for the plugin to Maven 3.1.1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-resolver] cstamas commented on a change in pull request #77: [MRESOLVER-145] SyncContext implementations
cstamas commented on a change in pull request #77:
URL: https://github.com/apache/maven-resolver/pull/77#discussion_r549475294
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/synccontext/SyncContextFactoryAdapter.java
##
@@ -0,0 +1,272 @@
+package org.eclipse.aether.internal.impl.synccontext;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.SyncContext;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.metadata.Metadata;
+import org.eclipse.aether.named.NamedLock;
+import org.eclipse.aether.named.NamedLockFactory;
+import org.eclipse.aether.util.ChecksumUtils;
+import org.eclipse.aether.util.ConfigUtils;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import java.io.File;
+import java.net.InetAddress;
+import java.net.UnknownHostException;
+import java.nio.charset.StandardCharsets;
+import java.util.ArrayDeque;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.Map;
+import java.util.TreeSet;
+import java.util.concurrent.TimeUnit;
+
+/**
+ * Adapter to adapt {@link NamedLockFactory} and {@link NamedLock} to {@link
SyncContext}.
+ */
+public final class SyncContextFactoryAdapter
+{
+private static final String DEFAULT_DISCRIMINATOR_DIGEST =
"da39a3ee5e6b4b0d3255bfef95601890afd80709";
+
+private static final String DEFAULT_HOSTNAME = "localhost";
+
+private static final Logger LOGGER = LoggerFactory.getLogger(
SyncContextFactoryAdapter.class );
+
+private final NamedLockFactory namedLockFactory;
+
+private final long time;
+
+private final TimeUnit timeUnit;
+
+private final String hostname;
+
+public SyncContextFactoryAdapter( final NamedLockFactory namedLockFactory,
+ final long time,
+ final TimeUnit timeUnit )
+{
+this.namedLockFactory = namedLockFactory;
+this.time = time;
+this.timeUnit = timeUnit;
+this.hostname = getHostname();
+}
+
+private String getHostname()
+{
+try
+{
+return InetAddress.getLocalHost().getHostName();
+}
+catch ( UnknownHostException e )
+{
+LOGGER.warn( "Failed to get hostname, using '{}'",
DEFAULT_HOSTNAME, e );
+return DEFAULT_HOSTNAME;
+}
+}
+
+public SyncContext newInstance( final RepositorySystemSession session,
final boolean shared )
+{
+return new AdaptedLockSyncContext( session, hostname,
namedLockFactory, time, timeUnit, shared );
+}
+
+public void shutdown()
+{
+namedLockFactory.shutdown();
+}
+
+private static class AdaptedLockSyncContext
+implements SyncContext
+{
+private static final String CONFIG_PROP_DISCRIMINATOR =
"aether.syncContext.named.discriminator";
+
+private static final String KEY_PREFIX = "mvn:resolver:";
+
+private static final Logger LOGGER = LoggerFactory.getLogger(
AdaptedLockSyncContext.class );
+
+private final RepositorySystemSession session;
+
+private final String hostname;
+
+private final NamedLockFactory namedLockFactory;
+
+private final long time;
+
+private final TimeUnit timeUnit;
+
+private final boolean shared;
+
+private final ArrayDeque locks;
+
+private AdaptedLockSyncContext( final RepositorySystemSession session,
+final String hostname,
+final NamedLockFactory
namedLockFactory,
+final long time,
+final TimeUnit timeUnit,
+final boolean shared )
+{
+this.session = session;
+this.hostname = hostname;
+this.namedLockFactory = namedLockFactory;
+this.time = time;
+this.timeUnit = timeUnit;
+this.shared = shared;
+this.locks = new ArrayDeque<>();
+}
+
+@Override
+public
[GitHub] [maven-resolver] cstamas commented on a change in pull request #77: [MRESOLVER-145] SyncContext implementations
cstamas commented on a change in pull request #77:
URL: https://github.com/apache/maven-resolver/pull/77#discussion_r549467158
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/synccontext/SyncContextFactoryAdapter.java
##
@@ -0,0 +1,272 @@
+package org.eclipse.aether.internal.impl.synccontext;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.SyncContext;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.metadata.Metadata;
+import org.eclipse.aether.named.NamedLock;
+import org.eclipse.aether.named.NamedLockFactory;
+import org.eclipse.aether.util.ChecksumUtils;
+import org.eclipse.aether.util.ConfigUtils;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import java.io.File;
+import java.net.InetAddress;
+import java.net.UnknownHostException;
+import java.nio.charset.StandardCharsets;
+import java.util.ArrayDeque;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.Map;
+import java.util.TreeSet;
+import java.util.concurrent.TimeUnit;
+
+/**
+ * Adapter to adapt {@link NamedLockFactory} and {@link NamedLock} to {@link
SyncContext}.
+ */
+public final class SyncContextFactoryAdapter
+{
+private static final String DEFAULT_DISCRIMINATOR_DIGEST =
"da39a3ee5e6b4b0d3255bfef95601890afd80709";
+
+private static final String DEFAULT_HOSTNAME = "localhost";
+
+private static final Logger LOGGER = LoggerFactory.getLogger(
SyncContextFactoryAdapter.class );
+
+private final NamedLockFactory namedLockFactory;
+
+private final long time;
+
+private final TimeUnit timeUnit;
+
+private final String hostname;
+
+public SyncContextFactoryAdapter( final NamedLockFactory namedLockFactory,
+ final long time,
+ final TimeUnit timeUnit )
+{
+this.namedLockFactory = namedLockFactory;
+this.time = time;
+this.timeUnit = timeUnit;
+this.hostname = getHostname();
+}
+
+private String getHostname()
+{
+try
+{
+return InetAddress.getLocalHost().getHostName();
+}
+catch ( UnknownHostException e )
+{
+LOGGER.warn( "Failed to get hostname, using '{}'",
DEFAULT_HOSTNAME, e );
+return DEFAULT_HOSTNAME;
+}
+}
+
+public SyncContext newInstance( final RepositorySystemSession session,
final boolean shared )
+{
+return new AdaptedLockSyncContext( session, hostname,
namedLockFactory, time, timeUnit, shared );
+}
+
+public void shutdown()
+{
+namedLockFactory.shutdown();
+}
+
+private static class AdaptedLockSyncContext
+implements SyncContext
+{
+private static final String CONFIG_PROP_DISCRIMINATOR =
"aether.syncContext.named.discriminator";
+
+private static final String KEY_PREFIX = "mvn:resolver:";
+
+private static final Logger LOGGER = LoggerFactory.getLogger(
AdaptedLockSyncContext.class );
+
+private final RepositorySystemSession session;
+
+private final String hostname;
+
+private final NamedLockFactory namedLockFactory;
+
+private final long time;
+
+private final TimeUnit timeUnit;
+
+private final boolean shared;
+
+private final ArrayDeque locks;
+
+private AdaptedLockSyncContext( final RepositorySystemSession session,
+final String hostname,
+final NamedLockFactory
namedLockFactory,
+final long time,
+final TimeUnit timeUnit,
+final boolean shared )
+{
+this.session = session;
+this.hostname = hostname;
+this.namedLockFactory = namedLockFactory;
+this.time = time;
+this.timeUnit = timeUnit;
+this.shared = shared;
+this.locks = new ArrayDeque<>();
+}
+
+@Override
+public
[jira] [Created] (MEAR-295) Require Maven 3.1.1
Sylwester Lachiewicz created MEAR-295: - Summary: Require Maven 3.1.1 Key: MEAR-295 URL: https://issues.apache.org/jira/browse/MEAR-295 Project: Maven EAR Plugin Issue Type: Dependency upgrade Reporter: Sylwester Lachiewicz Assignee: Sylwester Lachiewicz Fix For: 3.2.0 Upgrade prerequisites for the plugin to Maven 3.1.1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MEAR-269) Generate Websphere Deployment Descriptors
[
https://issues.apache.org/jira/browse/MEAR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255704#comment-17255704
]
Benjamin Marwell commented on MEAR-269:
---
[~dgautier] are you referring to the files {{ibm-web-bnd.xml}} and
{{ibm-web-ext.xml}}? If so, what would be the benefits of providing them? What
should be generated? Is there a reference documentation?
> Generate Websphere Deployment Descriptors
> -
>
> Key: MEAR-269
> URL: https://issues.apache.org/jira/browse/MEAR-269
> Project: Maven EAR Plugin
> Issue Type: New Feature
>Reporter: David Gautier
>Priority: Minor
>
> Websphere deployment descriptors could be generated based on application.xml
> and web.xml
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-resolver] cstamas commented on a change in pull request #77: [MRESOLVER-145] SyncContext implementations
cstamas commented on a change in pull request #77:
URL: https://github.com/apache/maven-resolver/pull/77#discussion_r549461637
##
File path:
maven-resolver-named/src/main/java/org/eclipse/aether/named/NamedLock.java
##
@@ -0,0 +1,71 @@
+package org.eclipse.aether.named;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.util.concurrent.TimeUnit;
+
+/**
+ * A named lock, functionally similar to existing JVM and other
implementations. Does support boxing, but no
+ * lock upgrade is supported. Usual pattern to use this lock:
+ *
+ * try (NamedLock lock = factory.getLock("resourceName")) {
+ * if (lock.lockExclusively(10L, Timeunit.SECONDS)) {
+ * try {
+ * ... exclusive access to "resourceName" resource gained here
+ * }
+ * finally {
+ * lock.unlock();
+ * }
+ * }
+ * else {
+ * ... failed to gain access within specified time, handle it
+ * }
+ * }
+ *
+ */
+public interface NamedLock
Review comment:
That was already stated by "boxing". Reworded and added MUST and
clarification, as it sounds clearer.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a change in pull request #77: [MRESOLVER-145] SyncContext implementations
cstamas commented on a change in pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#discussion_r549461341 ## File path: maven-resolver-named-hazelcast/src/test/resources/hazelcast.xml ## @@ -0,0 +1,42 @@ + + + + +http://www.hazelcast.com/schema/config; + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; + xsi:schemaLocation="http://www.hazelcast.com/schema/config + http://www.hazelcast.com/schema/config/hazelcast-config-3.12.xsd;> + + +maven-resolved-named + +server + +slf4j + + + + + +127.0.0.1 Review comment: Fixed This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a change in pull request #77: [MRESOLVER-145] SyncContext implementations
cstamas commented on a change in pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#discussion_r549461325 ## File path: maven-resolver-named-hazelcast/src/test/resources/hazelcast-client.xml ## @@ -0,0 +1,39 @@ + + + + +http://www.hazelcast.com/schema/client-config; + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; + xsi:schemaLocation="http://www.hazelcast.com/schema/client-config + http://www.hazelcast.com/schema/client-config/hazelcast-client-config-3.12.xsd;> + + +maven-resolved-named + +client + +slf4j + + + +127.0.0.1 Review comment: Fixed This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a change in pull request #77: [MRESOLVER-145] SyncContext implementations
cstamas commented on a change in pull request #77:
URL: https://github.com/apache/maven-resolver/pull/77#discussion_r549461252
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/synccontext/SyncContextFactoryAdapter.java
##
@@ -0,0 +1,272 @@
+package org.eclipse.aether.internal.impl.synccontext;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.SyncContext;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.metadata.Metadata;
+import org.eclipse.aether.named.NamedLock;
+import org.eclipse.aether.named.NamedLockFactory;
+import org.eclipse.aether.util.ChecksumUtils;
+import org.eclipse.aether.util.ConfigUtils;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import java.io.File;
+import java.net.InetAddress;
+import java.net.UnknownHostException;
+import java.nio.charset.StandardCharsets;
+import java.util.ArrayDeque;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.Map;
+import java.util.TreeSet;
+import java.util.concurrent.TimeUnit;
+
+/**
+ * Adapter to adapt {@link NamedLockFactory} and {@link NamedLock} to {@link
SyncContext}.
+ */
+public final class SyncContextFactoryAdapter
+{
+private static final String DEFAULT_DISCRIMINATOR_DIGEST =
"da39a3ee5e6b4b0d3255bfef95601890afd80709";
+
+private static final String DEFAULT_HOSTNAME = "localhost";
+
+private static final Logger LOGGER = LoggerFactory.getLogger(
SyncContextFactoryAdapter.class );
+
+private final NamedLockFactory namedLockFactory;
+
+private final long time;
+
+private final TimeUnit timeUnit;
+
+private final String hostname;
+
+public SyncContextFactoryAdapter( final NamedLockFactory namedLockFactory,
+ final long time,
+ final TimeUnit timeUnit )
+{
+this.namedLockFactory = namedLockFactory;
+this.time = time;
+this.timeUnit = timeUnit;
+this.hostname = getHostname();
+}
+
+private String getHostname()
+{
+try
+{
+return InetAddress.getLocalHost().getHostName();
+}
+catch ( UnknownHostException e )
+{
+LOGGER.warn( "Failed to get hostname, using '{}'",
DEFAULT_HOSTNAME, e );
+return DEFAULT_HOSTNAME;
+}
+}
+
+public SyncContext newInstance( final RepositorySystemSession session,
final boolean shared )
+{
+return new AdaptedLockSyncContext( session, hostname,
namedLockFactory, time, timeUnit, shared );
+}
+
+public void shutdown()
+{
+namedLockFactory.shutdown();
+}
+
+private static class AdaptedLockSyncContext
+implements SyncContext
+{
+private static final String CONFIG_PROP_DISCRIMINATOR =
"aether.syncContext.named.discriminator";
+
+private static final String KEY_PREFIX = "mvn:resolver:";
+
+private static final Logger LOGGER = LoggerFactory.getLogger(
AdaptedLockSyncContext.class );
+
+private final RepositorySystemSession session;
+
+private final String hostname;
+
+private final NamedLockFactory namedLockFactory;
+
+private final long time;
+
+private final TimeUnit timeUnit;
+
+private final boolean shared;
+
+private final ArrayDeque locks;
+
+private AdaptedLockSyncContext( final RepositorySystemSession session,
+final String hostname,
+final NamedLockFactory
namedLockFactory,
+final long time,
+final TimeUnit timeUnit,
+final boolean shared )
+{
+this.session = session;
+this.hostname = hostname;
+this.namedLockFactory = namedLockFactory;
+this.time = time;
+this.timeUnit = timeUnit;
+this.shared = shared;
+this.locks = new ArrayDeque<>();
+}
+
+@Override
+public
[GitHub] [maven-resolver] cstamas commented on a change in pull request #77: [MRESOLVER-145] SyncContext implementations
cstamas commented on a change in pull request #77:
URL: https://github.com/apache/maven-resolver/pull/77#discussion_r549460800
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/synccontext/SyncContextFactoryAdapter.java
##
@@ -0,0 +1,272 @@
+package org.eclipse.aether.internal.impl.synccontext;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.SyncContext;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.metadata.Metadata;
+import org.eclipse.aether.named.NamedLock;
+import org.eclipse.aether.named.NamedLockFactory;
+import org.eclipse.aether.util.ChecksumUtils;
+import org.eclipse.aether.util.ConfigUtils;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import java.io.File;
+import java.net.InetAddress;
+import java.net.UnknownHostException;
+import java.nio.charset.StandardCharsets;
+import java.util.ArrayDeque;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.Map;
+import java.util.TreeSet;
+import java.util.concurrent.TimeUnit;
+
+/**
+ * Adapter to adapt {@link NamedLockFactory} and {@link NamedLock} to {@link
SyncContext}.
+ */
+public final class SyncContextFactoryAdapter
+{
+private static final String DEFAULT_DISCRIMINATOR_DIGEST =
"da39a3ee5e6b4b0d3255bfef95601890afd80709";
+
+private static final String DEFAULT_HOSTNAME = "localhost";
+
+private static final Logger LOGGER = LoggerFactory.getLogger(
SyncContextFactoryAdapter.class );
+
+private final NamedLockFactory namedLockFactory;
+
+private final long time;
+
+private final TimeUnit timeUnit;
+
+private final String hostname;
+
+public SyncContextFactoryAdapter( final NamedLockFactory namedLockFactory,
+ final long time,
+ final TimeUnit timeUnit )
+{
+this.namedLockFactory = namedLockFactory;
+this.time = time;
+this.timeUnit = timeUnit;
+this.hostname = getHostname();
+}
+
+private String getHostname()
+{
+try
+{
+return InetAddress.getLocalHost().getHostName();
+}
+catch ( UnknownHostException e )
+{
+LOGGER.warn( "Failed to get hostname, using '{}'",
DEFAULT_HOSTNAME, e );
+return DEFAULT_HOSTNAME;
+}
+}
+
+public SyncContext newInstance( final RepositorySystemSession session,
final boolean shared )
+{
+return new AdaptedLockSyncContext( session, hostname,
namedLockFactory, time, timeUnit, shared );
+}
+
+public void shutdown()
+{
+namedLockFactory.shutdown();
+}
+
+private static class AdaptedLockSyncContext
+implements SyncContext
+{
+private static final String CONFIG_PROP_DISCRIMINATOR =
"aether.syncContext.named.discriminator";
+
+private static final String KEY_PREFIX = "mvn:resolver:";
+
+private static final Logger LOGGER = LoggerFactory.getLogger(
AdaptedLockSyncContext.class );
+
+private final RepositorySystemSession session;
+
+private final String hostname;
+
+private final NamedLockFactory namedLockFactory;
+
+private final long time;
+
+private final TimeUnit timeUnit;
+
+private final boolean shared;
+
+private final ArrayDeque locks;
+
+private AdaptedLockSyncContext( final RepositorySystemSession session,
+final String hostname,
+final NamedLockFactory
namedLockFactory,
+final long time,
+final TimeUnit timeUnit,
+final boolean shared )
+{
+this.session = session;
+this.hostname = hostname;
+this.namedLockFactory = namedLockFactory;
+this.time = time;
+this.timeUnit = timeUnit;
+this.shared = shared;
+this.locks = new ArrayDeque<>();
+}
+
+@Override
+public
[GitHub] [maven-resolver] cstamas commented on a change in pull request #77: [MRESOLVER-145] SyncContext implementations
cstamas commented on a change in pull request #77:
URL: https://github.com/apache/maven-resolver/pull/77#discussion_r549460708
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/synccontext/SyncContextFactoryAdapter.java
##
@@ -0,0 +1,272 @@
+package org.eclipse.aether.internal.impl.synccontext;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.SyncContext;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.metadata.Metadata;
+import org.eclipse.aether.named.NamedLock;
+import org.eclipse.aether.named.NamedLockFactory;
+import org.eclipse.aether.util.ChecksumUtils;
+import org.eclipse.aether.util.ConfigUtils;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import java.io.File;
+import java.net.InetAddress;
+import java.net.UnknownHostException;
+import java.nio.charset.StandardCharsets;
+import java.util.ArrayDeque;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.Map;
+import java.util.TreeSet;
+import java.util.concurrent.TimeUnit;
+
+/**
+ * Adapter to adapt {@link NamedLockFactory} and {@link NamedLock} to {@link
SyncContext}.
+ */
+public final class SyncContextFactoryAdapter
+{
+private static final String DEFAULT_DISCRIMINATOR_DIGEST =
"da39a3ee5e6b4b0d3255bfef95601890afd80709";
+
+private static final String DEFAULT_HOSTNAME = "localhost";
+
+private static final Logger LOGGER = LoggerFactory.getLogger(
SyncContextFactoryAdapter.class );
+
+private final NamedLockFactory namedLockFactory;
+
+private final long time;
+
+private final TimeUnit timeUnit;
+
+private final String hostname;
+
+public SyncContextFactoryAdapter( final NamedLockFactory namedLockFactory,
+ final long time,
+ final TimeUnit timeUnit )
+{
+this.namedLockFactory = namedLockFactory;
+this.time = time;
+this.timeUnit = timeUnit;
+this.hostname = getHostname();
+}
+
+private String getHostname()
+{
+try
+{
+return InetAddress.getLocalHost().getHostName();
+}
+catch ( UnknownHostException e )
+{
+LOGGER.warn( "Failed to get hostname, using '{}'",
DEFAULT_HOSTNAME, e );
+return DEFAULT_HOSTNAME;
+}
+}
+
+public SyncContext newInstance( final RepositorySystemSession session,
final boolean shared )
+{
+return new AdaptedLockSyncContext( session, hostname,
namedLockFactory, time, timeUnit, shared );
+}
+
+public void shutdown()
+{
+namedLockFactory.shutdown();
+}
+
+private static class AdaptedLockSyncContext
+implements SyncContext
+{
+private static final String CONFIG_PROP_DISCRIMINATOR =
"aether.syncContext.named.discriminator";
+
+private static final String KEY_PREFIX = "mvn:resolver:";
Review comment:
Fixed
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/synccontext/NamedSyncContextFactory.java
##
@@ -0,0 +1,91 @@
+package org.eclipse.aether.internal.impl.synccontext;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.SyncContext;
+import
[GitHub] [maven-resolver] cstamas commented on a change in pull request #77: [MRESOLVER-145] SyncContext implementations
cstamas commented on a change in pull request #77:
URL: https://github.com/apache/maven-resolver/pull/77#discussion_r549460660
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/synccontext/NamedSyncContextFactory.java
##
@@ -0,0 +1,91 @@
+package org.eclipse.aether.internal.impl.synccontext;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.SyncContext;
+import org.eclipse.aether.named.NamedLockFactory;
+import org.eclipse.aether.named.providers.LocalReadWriteLockProvider;
+import org.eclipse.aether.spi.synccontext.SyncContextFactory;
+
+import javax.annotation.PreDestroy;
+import javax.inject.Inject;
+import javax.inject.Named;
+import javax.inject.Provider;
+import javax.inject.Singleton;
+import java.util.Map;
+import java.util.concurrent.TimeUnit;
+
+/**
+ * Named {@link SyncContextFactory} implementation that selects underlying
{@link NamedLockFactory} implementation
+ * at creation.
+ */
+@Named
+@Singleton
+public final class NamedSyncContextFactory
Review comment:
Fixed
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] rmannibucau commented on pull request #421: Artifact.getPath() and .setPath()
rmannibucau commented on pull request #421: URL: https://github.com/apache/maven/pull/421#issuecomment-751833740 Path is slower than File, it is only interesting when the filesystem can be abstracted IIRC. Also changing the internal will not help much in regards of what is done or we need to change it everywhere at the same time (to benefit from the abstraction). That said I understand Markus "caller need" very much so guess we should tackle that at some point. An alternative is to provide another resolver method which returns NioArtifacts. Here nothing would be ambiguous probably and a plugin could even test if it exists or not. Lastly we must start somewhere to provide a more user friendly API, if we stick to current prerequisites it will never happen ;). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a change in pull request #77: [MRESOLVER-145] SyncContext implementations
cstamas commented on a change in pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#discussion_r549457200 ## File path: maven-resolver-impl/pom.xml ## @@ -49,6 +49,10 @@ org.apache.maven.resolver maven-resolver-spi + + org.apache.maven.resolver + maven-resolver-named Review comment: "synccontext" exists in resolver-api (SyncContext) and resolver-spi (SyncContextFactory). While I agree that name maven-resolver-named is misleading, it has none of those two contained. What about maven-resolver-named-locks? It was my initial idea, but abstained as then maven-resolver-named-locks-redisson would be unusually long artifact ID... This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] mkarg commented on pull request #421: Artifact.getPath() and .setPath()
mkarg commented on pull request #421: URL: https://github.com/apache/maven/pull/421#issuecomment-751821795 Well, in the first place it means more work for me while it is unclear how many proxies exist for `Artifact`. ;-) But if the majority wants me to change my solution to that more complex one just for the sake of proxies, I would be happy to do that. So please vote. :-) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] rmannibucau commented on pull request #421: Artifact.getPath() and .setPath()
rmannibucau commented on pull request #421: URL: https://github.com/apache/maven/pull/421#issuecomment-751817795 From a quick review it sounds hurting less to add it and enforce impl to have it (for impl using proxies it will be hurtless) and others likely use our artifact impl so sounds a bit better even if still not 100%. Just requires to add it in maven-artifact-resolver too probably. Wdyt? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] bmarwell commented on pull request #415: [MNG-7032] do not print colours for --version when in batch mode.
bmarwell commented on pull request #415: URL: https://github.com/apache/maven/pull/415#issuecomment-751812135 > My bad, I did not notice that you have moved the code. But still, The property needs to be in the new method now for consistency reasons. I see. I could just move that block into the new method `applyColorMode( CliRequest cliRequest )` and update its Javadoc. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ejb-plugin] pzygielo commented on a change in pull request #11: [MEJB-130] Accept ejbVersion 4.x
pzygielo commented on a change in pull request #11:
URL: https://github.com/apache/maven-ejb-plugin/pull/11#discussion_r549431440
##
File path: src/main/java/org/apache/maven/plugins/ejb/EjbMojo.java
##
@@ -465,10 +465,10 @@ private File generateEjbClient()
private void checkEJBVersionCompliance( File deploymentDescriptor )
throws MojoExecutionException
{
-if ( !ejbVersion.matches( "\\A[2-3]\\.[0-9]\\z" ) )
+if ( !ejbVersion.matches( "\\A[2-4]\\.[0-9]\\z" ) )
Review comment:
> a unit test would be easier to manage than an integration test
IT replaced with UTs.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MPOM-259) Upgrade maven-scm-plugin from 3.0.0 to 3.1.0
[ https://issues.apache.org/jira/browse/MPOM-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255666#comment-17255666 ] Sylwester Lachiewicz commented on MPOM-259: --- Done in [01d812b4e78c1661ad61b1d1befcccbed2cc3e3f|https://gitbox.apache.org/repos/asf?p=maven-apache-parent.git;a=commit;h=01d812b4e78c1661ad61b1d1befcccbed2cc3e3f] > Upgrade maven-scm-plugin from 3.0.0 to 3.1.0 > > > Key: MPOM-259 > URL: https://issues.apache.org/jira/browse/MPOM-259 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: ASF-24 > > > Release Notes - Apache Maven SCM Publish Plugin - Version 3.1.0 > Bug > * [MSCMPUB-42] Can't publish to file:// URL containing an @ > * [MSCMPUB-13] automaticRemotePathCreation does not create parent directories > Improvement > * [MSCMPUB-47] use Files.createTempDirectory(...) instead of custom code > around File.createTempFile(...) > * [MSCMPUB-45] make build Reproducible > New Feature > * [MSCMPUB-41] Publish in repository sub-folder > * [MSCMPUB-40] Ability to skip this plugin execution via a config property > Task > * [MSCMPUB-46] drop custom scmpublish lifecycle with its scmpublish goal > * [MSCMPUB-39] Upgrade maven-plugins parent to 33. > * [MSCMPUB-37] Upgrade to SCM 1.11.2 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MPOM-259) Upgrade maven-scm-plugin from 3.0.0 to 3.1.0
[ https://issues.apache.org/jira/browse/MPOM-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MPOM-259. - Resolution: Fixed > Upgrade maven-scm-plugin from 3.0.0 to 3.1.0 > > > Key: MPOM-259 > URL: https://issues.apache.org/jira/browse/MPOM-259 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: ASF-24 > > > Release Notes - Apache Maven SCM Publish Plugin - Version 3.1.0 > Bug > * [MSCMPUB-42] Can't publish to file:// URL containing an @ > * [MSCMPUB-13] automaticRemotePathCreation does not create parent directories > Improvement > * [MSCMPUB-47] use Files.createTempDirectory(...) instead of custom code > around File.createTempFile(...) > * [MSCMPUB-45] make build Reproducible > New Feature > * [MSCMPUB-41] Publish in repository sub-folder > * [MSCMPUB-40] Ability to skip this plugin execution via a config property > Task > * [MSCMPUB-46] drop custom scmpublish lifecycle with its scmpublish goal > * [MSCMPUB-39] Upgrade maven-plugins parent to 33. > * [MSCMPUB-37] Upgrade to SCM 1.11.2 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MPOM-259) Upgrade maven-scm-plugin from 3.0.0 to 3.1.0
[ https://issues.apache.org/jira/browse/MPOM-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MPOM-259: - Assignee: Sylwester Lachiewicz > Upgrade maven-scm-plugin from 3.0.0 to 3.1.0 > > > Key: MPOM-259 > URL: https://issues.apache.org/jira/browse/MPOM-259 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: ASF-24 > > > Release Notes - Apache Maven SCM Publish Plugin - Version 3.1.0 > Bug > * [MSCMPUB-42] Can't publish to file:// URL containing an @ > * [MSCMPUB-13] automaticRemotePathCreation does not create parent directories > Improvement > * [MSCMPUB-47] use Files.createTempDirectory(...) instead of custom code > around File.createTempFile(...) > * [MSCMPUB-45] make build Reproducible > New Feature > * [MSCMPUB-41] Publish in repository sub-folder > * [MSCMPUB-40] Ability to skip this plugin execution via a config property > Task > * [MSCMPUB-46] drop custom scmpublish lifecycle with its scmpublish goal > * [MSCMPUB-39] Upgrade maven-plugins parent to 33. > * [MSCMPUB-37] Upgrade to SCM 1.11.2 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MPOM-259) Upgrade maven-scm-plugin from 3.0.0 to 3.1.0
[ https://issues.apache.org/jira/browse/MPOM-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255665#comment-17255665 ] Hudson commented on MPOM-259: - Build succeeded in Jenkins: Maven » Maven TLP » maven-apache-parent » master #21 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-apache-parent/job/master/21/ > Upgrade maven-scm-plugin from 3.0.0 to 3.1.0 > > > Key: MPOM-259 > URL: https://issues.apache.org/jira/browse/MPOM-259 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: ASF-24 > > > Release Notes - Apache Maven SCM Publish Plugin - Version 3.1.0 > Bug > * [MSCMPUB-42] Can't publish to file:// URL containing an @ > * [MSCMPUB-13] automaticRemotePathCreation does not create parent directories > Improvement > * [MSCMPUB-47] use Files.createTempDirectory(...) instead of custom code > around File.createTempFile(...) > * [MSCMPUB-45] make build Reproducible > New Feature > * [MSCMPUB-41] Publish in repository sub-folder > * [MSCMPUB-40] Ability to skip this plugin execution via a config property > Task > * [MSCMPUB-46] drop custom scmpublish lifecycle with its scmpublish goal > * [MSCMPUB-39] Upgrade maven-plugins parent to 33. > * [MSCMPUB-37] Upgrade to SCM 1.11.2 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MPOM-259) Upgrade maven-scm-plugin from 3.0.0 to 3.1.0
[ https://issues.apache.org/jira/browse/MPOM-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MPOM-259: -- Fix Version/s: ASF-24 > Upgrade maven-scm-plugin from 3.0.0 to 3.1.0 > > > Key: MPOM-259 > URL: https://issues.apache.org/jira/browse/MPOM-259 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: ASF-24 > > > Release Notes - Apache Maven SCM Publish Plugin - Version 3.1.0 > Bug > * [MSCMPUB-42] Can't publish to file:// URL containing an @ > * [MSCMPUB-13] automaticRemotePathCreation does not create parent directories > Improvement > * [MSCMPUB-47] use Files.createTempDirectory(...) instead of custom code > around File.createTempFile(...) > * [MSCMPUB-45] make build Reproducible > New Feature > * [MSCMPUB-41] Publish in repository sub-folder > * [MSCMPUB-40] Ability to skip this plugin execution via a config property > Task > * [MSCMPUB-46] drop custom scmpublish lifecycle with its scmpublish goal > * [MSCMPUB-39] Upgrade maven-plugins parent to 33. > * [MSCMPUB-37] Upgrade to SCM 1.11.2 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-apache-parent] dependabot[bot] commented on pull request #28: Bump maven-scm-publish-plugin from 3.0.0 to 3.1.0
dependabot[bot] commented on pull request #28: URL: https://github.com/apache/maven-apache-parent/pull/28#issuecomment-751796780 Looks like org.apache.maven.plugins:maven-scm-publish-plugin 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-apache-parent] dependabot[bot] closed pull request #28: Bump maven-scm-publish-plugin from 3.0.0 to 3.1.0
dependabot[bot] closed pull request #28: URL: https://github.com/apache/maven-apache-parent/pull/28 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] mkarg commented on pull request #421: Artifact.getPath() and .setPath()
mkarg commented on pull request #421: URL: https://github.com/apache/maven/pull/421#issuecomment-751779644 I have no strong feelings whether we should keep it as `default` methods or whether to force all implementations to adopt it on their own. Somebody has to decide. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] rmannibucau commented on pull request #421: Artifact.getPath() and .setPath()
rmannibucau commented on pull request #421: URL: https://github.com/apache/maven/pull/421#issuecomment-751766701 @mkarg java lang proxies don't know how to invoke the default method so you will not get the expected behavior. This is a common breaking change since default methods were introduced. Some workaround for 2 java versions can look like https://github.com/Talend/component-runtime/blob/master/component-runtime-impl/src/main/java/org/talend/sdk/component/runtime/reflect/Defaults.java#L34 but this is really a workaround. jsonp got this breakage BTW even if it had been warned :(. > Isn't master only be used for Maven >= 4 ? Yes, point is more that if kept, it must not be backported and that if for maven 4 it can be added as a not default method too ;). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7032) Option -B still showing formatting when used with --version
[
https://issues.apache.org/jira/browse/MNG-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255633#comment-17255633
]
Hudson commented on MNG-7032:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-7032_versioncolours
#4
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7032_versioncolours/4/
> Option -B still showing formatting when used with --version
> ---
>
> Key: MNG-7032
> URL: https://issues.apache.org/jira/browse/MNG-7032
> Project: Maven
> Issue Type: Bug
> Components: Command Line, Logging
>Affects Versions: 3.6.3
> Environment: Running Ubuntu 20.04.1 LTS (Focal Fossa)
> Apache Maven 3.6.3
> Maven home: /usr/share/maven
> Java version: 11.0.8, vendor: AdoptOpenJDK, runtime: /opt/java/jdk-11.0.8+10
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "linux", version: "5.4.0-54-generic", arch: "amd64", family: "unix"
>Reporter: Christian Koop
>Priority: Major
> Labels: easyfix
> Fix For: 4.0.x-candidate
>
>
> When running {{mvn -B --version}} the first line ({{'Apache Maven 3.6.3'}})
> is written in bold although the option {{-B}} should have stripped that as it
> does with color in combination with other options.
> This causes an issue when logging to a file as the ASCII escape sequence is
> written to it in plain text (causing confusion).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MNGSITE-437) Intellij IDEA code style setting file is outdated
Sandra Parsick created MNGSITE-437: -- Summary: Intellij IDEA code style setting file is outdated Key: MNGSITE-437 URL: https://issues.apache.org/jira/browse/MNGSITE-437 Project: Maven Project Web Site Issue Type: Improvement Reporter: Sandra Parsick The code style setting file for Intellij IDEA that is linked on the [Code Convention page|http://maven.apache.org/developers/conventions/code.html] does not match the current code convention -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] mkarg edited a comment on pull request #421: Artifact.getPath() and .setPath()
mkarg edited a comment on pull request #421: URL: https://github.com/apache/maven/pull/421#issuecomment-751758976 > Quick side note: using a default method is a breaking change so should likely happen only in maven >= 4 (it breaks java lang proxies). What can break here? Isn't master *only* be used for Maven >= 4 ? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] mkarg commented on pull request #421: Artifact.getPath() and .setPath()
mkarg commented on pull request #421: URL: https://github.com/apache/maven/pull/421#issuecomment-751758976 > Quick side note: using a default method is a breaking change so should likely happen only in maven >= 4 (it breaks java lang proxies). What can break here? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] michael-o commented on pull request #415: [MNG-7032] do not print colours for --version when in batch mode.
michael-o commented on pull request #415: URL: https://github.com/apache/maven/pull/415#issuecomment-751758529 My bad, I did not notice that you have moved the code. But still, The property needs to be in the new method now for consistency reasons. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ejb-plugin] elharo opened a new pull request #14: remove deprecation warnings by not stubbing value class
elharo opened a new pull request #14: URL: https://github.com/apache/maven-ejb-plugin/pull/14 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6830) Warn on missing namespace
[
https://issues.apache.org/jira/browse/MNG-6830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255628#comment-17255628
]
Michael Osipov commented on MNG-6830:
-
The Modello model allows to define versions on element, but one cannot say that
element came to existence in schema version 1.1.0 and and is backward
compatible. Consider the following in settings which is a real usecase we are
discussion at the moment:
{code:xml}
http://maven.apache.org/SETTINGS/1.1.0;
xmlns:settings-1.2.0="http://maven.apache.org/SETTINGS/1.2.0;>
{code}
This is the only proper way to do this in XML. With this approach pre-4.0.0
Maven clients can safely ignore new settings while new ones can read, but this
would also mean that the parser tries to read elements with every compatible
schema version. Alternatively, it is all or nothing. Everything 1.1.0 or 1.2.0,
no mixed case, but still when 1.3.0 or 2.0.0 comes you will fail again
[~elharo] is the expert, I leared from him.
> Warn on missing namespace
> -
>
> Key: MNG-6830
> URL: https://issues.apache.org/jira/browse/MNG-6830
> Project: Maven
> Issue Type: Improvement
>Reporter: Elliotte Rusty Harold
>Priority: Minor
>
> We allow pom.xml files with no namespace and reject pom.xml files that use
> prefixed local names that are correctly namespaced.
> As step 1 to getting to a release where we can fix this, emit a warning when
> we encounter a non-namespaced pom.xml such as this:
>
> 4.0.0
> war
> 0.1.0-SNAPSHOT
> c.g
> mvn25
>
> 2.2.0
> UTF-8
> UTF-8
> 1.8
> 1.8
> true
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] rmannibucau commented on pull request #421: Artifact.getPath() and .setPath()
rmannibucau commented on pull request #421: URL: https://github.com/apache/maven/pull/421#issuecomment-751756543 Quick side note: using a default method is a breaking change so should likely happen only in maven >= 4 (it breaks java lang proxies). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] mkarg commented on a change in pull request #421: Artifact.getPath() and .setPath()
mkarg commented on a change in pull request #421:
URL: https://github.com/apache/maven/pull/421#discussion_r549391327
##
File path: maven-artifact/src/main/java/org/apache/maven/artifact/Artifact.java
##
@@ -86,6 +87,16 @@
void setFile( File destination );
+default Path getPath()
+{
+return this.getFile().toPath();
Review comment:
Good catch! Just fixed it using force-push. If you prefer, I can replace
by `Optional`.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-ejb-plugin] elharo opened a new pull request #13: remove dependency on AssertJ
elharo opened a new pull request #13: URL: https://github.com/apache/maven-ejb-plugin/pull/13 @michael-o also update JUnit This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] bmarwell edited a comment on pull request #415: [MNG-7032] do not print colours for --version when in batch mode.
bmarwell edited a comment on pull request #415: URL: https://github.com/apache/maven/pull/415#issuecomment-751754398 > This looks OK, but incomplete. When if you at `org.apache.maven.cli.MavenCli.logging(CliRequest)` in the block marked with `// LOG COLOR` you see duplicate code now. It is probably time to move that code out of `logging()` into `cli()`. Which one? This? https://github.com/apache/maven/blob/496b9bd65d0ddd0fb19c8c9f89058555f458790e/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L508-L522 I do not see this code duplicated somewhere else. There are other duplicated parts, however.  This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] bmarwell commented on pull request #415: [MNG-7032] do not print colours for --version when in batch mode.
bmarwell commented on pull request #415: URL: https://github.com/apache/maven/pull/415#issuecomment-751754398 > This looks OK, but incomplete. When if you at `org.apache.maven.cli.MavenCli.logging(CliRequest)` in the block marked with `// LOG COLOR` you see duplicate code now. It is probably time to move that code out of `logging()` into `cli()`. > > I wonder what will happen when one does the following: > > ``` > mvn -v -Dstyle.color=always | less -R > ``` > > I would expect to see colors here also stdout is not attached to a tty. I think we need to move the use property to a CLI option to make it more obvious. > > I am quite used to: `grep --color=always ... | less -R` Which one? This? https://github.com/apache/maven/blob/496b9bd65d0ddd0fb19c8c9f89058555f458790e/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L508-L522 I do not see this code duplicated somewhere else. There are other duplicated parts, however.  This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6830) Warn on missing namespace
[ https://issues.apache.org/jira/browse/MNG-6830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255625#comment-17255625 ] Michael Osipov commented on MNG-6830: - Correct, so we should say we do not care about namespaces and provide the XSD solely for autocompletion or we say we want to enforce this. > Warn on missing namespace > - > > Key: MNG-6830 > URL: https://issues.apache.org/jira/browse/MNG-6830 > Project: Maven > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Minor > > We allow pom.xml files with no namespace and reject pom.xml files that use > prefixed local names that are correctly namespaced. > As step 1 to getting to a release where we can fix this, emit a warning when > we encounter a non-namespaced pom.xml such as this: > > 4.0.0 > war > 0.1.0-SNAPSHOT > c.g > mvn25 > > 2.2.0 > UTF-8 > UTF-8 > 1.8 > 1.8 > true > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6830) Warn on missing namespace
[ https://issues.apache.org/jira/browse/MNG-6830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255622#comment-17255622 ] Brian E Fox commented on MNG-6830: -- After chatting in slack to find some good examples: "This one is bad: [https://github.com/apache/maven/blob/master/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml], this one is good: [https://github.com/apache/maven/blob/2caed6218a5ec0a0b7fce2975743331e5ec76c89/pom.xml#L22]; I'll say that in central hardly any are going to have the namespace correctly set. If someone has the xsd references, they are better than most, but it's hard to find any like the good example. Warning on no namespace seems pointless because EVERYTHING is going to generate a warn. > Warn on missing namespace > - > > Key: MNG-6830 > URL: https://issues.apache.org/jira/browse/MNG-6830 > Project: Maven > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Minor > > We allow pom.xml files with no namespace and reject pom.xml files that use > prefixed local names that are correctly namespaced. > As step 1 to getting to a release where we can fix this, emit a warning when > we encounter a non-namespaced pom.xml such as this: > > 4.0.0 > war > 0.1.0-SNAPSHOT > c.g > mvn25 > > 2.2.0 > UTF-8 > UTF-8 > 1.8 > 1.8 > true > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-ejb-plugin] elharo commented on a change in pull request #11: [MEJB-130] Accept ejbVersion 4.x
elharo commented on a change in pull request #11:
URL: https://github.com/apache/maven-ejb-plugin/pull/11#discussion_r549387107
##
File path: src/main/java/org/apache/maven/plugins/ejb/EjbMojo.java
##
@@ -465,10 +465,10 @@ private File generateEjbClient()
private void checkEJBVersionCompliance( File deploymentDescriptor )
throws MojoExecutionException
{
-if ( !ejbVersion.matches( "\\A[2-3]\\.[0-9]\\z" ) )
+if ( !ejbVersion.matches( "\\A[2-4]\\.[0-9]\\z" ) )
Review comment:
a unit test would be easier to manage than an integration test
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-ejb-plugin] elharo closed pull request #9: add travic-ci; add travis badge to README.md
elharo closed pull request #9: URL: https://github.com/apache/maven-ejb-plugin/pull/9 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ejb-plugin] elharo commented on pull request #9: add travic-ci; add travis badge to README.md
elharo commented on pull request #9: URL: https://github.com/apache/maven-ejb-plugin/pull/9#issuecomment-751749847 https://www.r-bloggers.com/2020/11/moving-away-from-travis-ci/ This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ejb-plugin] elharo opened a new pull request #12: ignore versions backup files
elharo opened a new pull request #12: URL: https://github.com/apache/maven-ejb-plugin/pull/12 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] rfscholte commented on a change in pull request #421: Artifact.getPath() and .setPath()
rfscholte commented on a change in pull request #421:
URL: https://github.com/apache/maven/pull/421#discussion_r549377500
##
File path: maven-artifact/src/main/java/org/apache/maven/artifact/Artifact.java
##
@@ -86,6 +87,16 @@
void setFile( File destination );
+default Path getPath()
+{
+return this.getFile().toPath();
Review comment:
If `getFile()` is `null`, it should not throw an NPE
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven] mkarg opened a new pull request #421: Artifact.getPath() and .setPath()
mkarg opened a new pull request #421: URL: https://github.com/apache/maven/pull/421 Simplifying usage of Java NIO API (since Java 7), so the *calling* code does not need to convert to / from Path ON ITS OWN again and again. By using `default` interface methods, this should not imply any side effects to any existing code. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] elharo merged pull request #34: update ejb plugin
elharo merged pull request #34: URL: https://github.com/apache/maven-ear-plugin/pull/34 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] elharo merged pull request #35: compareTo should throw NullPointerException per spec
elharo merged pull request #35: URL: https://github.com/apache/maven-ear-plugin/pull/35 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] elharo commented on a change in pull request #34: update ejb plugin
elharo commented on a change in pull request #34: URL: https://github.com/apache/maven-ear-plugin/pull/34#discussion_r549357981 ## File path: pom.xml ## @@ -88,7 +88,7 @@ 2020-09-26T20:10:30Z 3.3.1 2.5.1 -2.3 +3.1.0 Review comment: I prefer to leave the tests as is to verify and indicate that nothing was broken by this change. Unless of course something was broken, in which case a changed test shows exactly what changed. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] michael-o commented on a change in pull request #419: [MNG-4645] Move Central repo definition out of Maven's core so it can…
michael-o commented on a change in pull request #419: URL: https://github.com/apache/maven/pull/419#discussion_r549356949 ## File path: apache-maven/src/assembly/maven/conf/settings.xml ## @@ -244,14 +244,43 @@ under the License. --> + + maven:core:central-repo + + + central + Central Repository + https://repo.maven.apache.org/maven2 + +false + + + + + + + central + Central Repository + https://repo.maven.apache.org/maven2 + +false + + +never + + + + -alwaysActiveProfile -anotherAlwaysActiveProfile +maven:core:central-repo Review comment: I can't offer anything better until settings don't change. Take your time and let me know. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on a change in pull request #77: [MRESOLVER-145] SyncContext implementations
michael-o commented on a change in pull request #77:
URL: https://github.com/apache/maven-resolver/pull/77#discussion_r549341209
##
File path: maven-resolver-impl/pom.xml
##
@@ -49,6 +49,10 @@
org.apache.maven.resolver
maven-resolver-spi
+
+ org.apache.maven.resolver
+ maven-resolver-named
Review comment:
I think this is a bad name for an artifact id. It says that the Resolver
is named. `maven-resolver-synccontext-named`?
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/synccontext/NamedSyncContextFactory.java
##
@@ -0,0 +1,91 @@
+package org.eclipse.aether.internal.impl.synccontext;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.SyncContext;
+import org.eclipse.aether.named.NamedLockFactory;
+import org.eclipse.aether.named.providers.LocalReadWriteLockProvider;
+import org.eclipse.aether.spi.synccontext.SyncContextFactory;
+
+import javax.annotation.PreDestroy;
+import javax.inject.Inject;
+import javax.inject.Named;
+import javax.inject.Provider;
+import javax.inject.Singleton;
+import java.util.Map;
+import java.util.concurrent.TimeUnit;
+
+/**
+ * Named {@link SyncContextFactory} implementation that selects underlying
{@link NamedLockFactory} implementation
+ * at creation.
+ */
+@Named
+@Singleton
+public final class NamedSyncContextFactory
+implements SyncContextFactory
+{
+private static final long TIME = Long.getLong(
Review comment:
Isn't this rather a timeout?
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/synccontext/SyncContextFactoryAdapter.java
##
@@ -0,0 +1,272 @@
+package org.eclipse.aether.internal.impl.synccontext;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.SyncContext;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.metadata.Metadata;
+import org.eclipse.aether.named.NamedLock;
+import org.eclipse.aether.named.NamedLockFactory;
+import org.eclipse.aether.util.ChecksumUtils;
+import org.eclipse.aether.util.ConfigUtils;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import java.io.File;
+import java.net.InetAddress;
+import java.net.UnknownHostException;
+import java.nio.charset.StandardCharsets;
+import java.util.ArrayDeque;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.Map;
+import java.util.TreeSet;
+import java.util.concurrent.TimeUnit;
+
+/**
+ * Adapter to adapt {@link NamedLockFactory} and {@link NamedLock} to {@link
SyncContext}.
+ */
+public final class SyncContextFactoryAdapter
+{
+private static final String DEFAULT_DISCRIMINATOR_DIGEST =
"da39a3ee5e6b4b0d3255bfef95601890afd80709";
+
+private static final String DEFAULT_HOSTNAME = "localhost";
+
+private static final Logger LOGGER = LoggerFactory.getLogger(
SyncContextFactoryAdapter.class );
+
+private final NamedLockFactory namedLockFactory;
+
+private final long time;
+
+private final TimeUnit timeUnit;
+
+private final String hostname;
+
+public SyncContextFactoryAdapter( final NamedLockFactory namedLockFactory,
+ final long time,
+ final TimeUnit timeUnit )
+{
+
[GitHub] [maven] rfscholte commented on a change in pull request #419: [MNG-4645] Move Central repo definition out of Maven's core so it can…
rfscholte commented on a change in pull request #419: URL: https://github.com/apache/maven/pull/419#discussion_r549349372 ## File path: apache-maven/src/assembly/maven/conf/settings.xml ## @@ -244,14 +244,43 @@ under the License. --> + + maven:core:central-repo + + + central + Central Repository + https://repo.maven.apache.org/maven2 + +false + + + + + + + central + Central Repository + https://repo.maven.apache.org/maven2 + +false + + +never + + + + -alwaysActiveProfile -anotherAlwaysActiveProfile +maven:core:central-repo Review comment: I don't like this approach. Let's invest time to do it correct, i.e. without profiles This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (DOXIA-616) Markdown: Properly expose the language specified in fenced code blocks
[
https://issues.apache.org/jira/browse/DOXIA-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255565#comment-17255565
]
Michael Osipov commented on DOXIA-616:
--
Agreed.
> Markdown: Properly expose the language specified in fenced code blocks
> --
>
> Key: DOXIA-616
> URL: https://issues.apache.org/jira/browse/DOXIA-616
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.8, 1.9, 1.9.1
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> Writers can specify the language used in a fenced code block (typically for
> syntax highlighting), as in the example below:
> {code}
> ```java
> System.out.println("Beautiful\n");
> ```
> {code}
> Currently, the Doxia module for Markdown does not expose this information
> ("java") in the produced HTML, so a Maven skin (or frontend renderer) cannot
> leverage it.
> Produced HTML:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> Wanted result:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> h1. Specification
> Un-comment this block:
> https://github.com/apache/maven-doxia/blob/c439714e8f4a9e86f9962ac6be9a0077ae9b4d30/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer.java#L103
> This should do the trick.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (MNG-7032) Option -B still showing formatting when used with --version
[
https://issues.apache.org/jira/browse/MNG-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7032:
Comment: was deleted
(was: Build unstable in Jenkins: Maven » Maven TLP » maven »
MNG-7032_versioncolours #3
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7032_versioncolours/3/)
> Option -B still showing formatting when used with --version
> ---
>
> Key: MNG-7032
> URL: https://issues.apache.org/jira/browse/MNG-7032
> Project: Maven
> Issue Type: Bug
> Components: Command Line, Logging
>Affects Versions: 3.6.3
> Environment: Running Ubuntu 20.04.1 LTS (Focal Fossa)
> Apache Maven 3.6.3
> Maven home: /usr/share/maven
> Java version: 11.0.8, vendor: AdoptOpenJDK, runtime: /opt/java/jdk-11.0.8+10
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "linux", version: "5.4.0-54-generic", arch: "amd64", family: "unix"
>Reporter: Christian Koop
>Priority: Major
> Labels: easyfix
> Fix For: 4.0.x-candidate
>
>
> When running {{mvn -B --version}} the first line ({{'Apache Maven 3.6.3'}})
> is written in bold although the option {{-B}} should have stripped that as it
> does with color in combination with other options.
> This causes an issue when logging to a file as the ASCII escape sequence is
> written to it in plain text (causing confusion).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DOXIA-616) Markdown: Properly expose the language specified in fenced code blocks
[
https://issues.apache.org/jira/browse/DOXIA-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255563#comment-17255563
]
Bertrand Martin commented on DOXIA-616:
---
I found my way with clirr. I guess we'll remove it from Doxia in a separate
issue.
> Markdown: Properly expose the language specified in fenced code blocks
> --
>
> Key: DOXIA-616
> URL: https://issues.apache.org/jira/browse/DOXIA-616
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.8, 1.9, 1.9.1
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> Writers can specify the language used in a fenced code block (typically for
> syntax highlighting), as in the example below:
> {code}
> ```java
> System.out.println("Beautiful\n");
> ```
> {code}
> Currently, the Doxia module for Markdown does not expose this information
> ("java") in the produced HTML, so a Maven skin (or frontend renderer) cannot
> leverage it.
> Produced HTML:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> Wanted result:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> h1. Specification
> Un-comment this block:
> https://github.com/apache/maven-doxia/blob/c439714e8f4a9e86f9962ac6be9a0077ae9b4d30/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer.java#L103
> This should do the trick.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DOXIA-616) Markdown: Properly expose the language specified in fenced code blocks
[
https://issues.apache.org/jira/browse/DOXIA-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255560#comment-17255560
]
Michael Osipov commented on DOXIA-616:
--
Drop clirr, on hc.apache.org we have decided to replace it. It does not fully
support Java 8.
> Markdown: Properly expose the language specified in fenced code blocks
> --
>
> Key: DOXIA-616
> URL: https://issues.apache.org/jira/browse/DOXIA-616
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Markdown
>Affects Versions: 1.8, 1.9, 1.9.1
>Reporter: Bertrand Martin
>Priority: Major
>
> h1. Use Case
> Writers can specify the language used in a fenced code block (typically for
> syntax highlighting), as in the example below:
> {code}
> ```java
> System.out.println("Beautiful\n");
> ```
> {code}
> Currently, the Doxia module for Markdown does not expose this information
> ("java") in the produced HTML, so a Maven skin (or frontend renderer) cannot
> leverage it.
> Produced HTML:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> Wanted result:
> {code:html}
>
>
> System.out.println("Beautiful\n");
>
>
> {code}
> h1. Specification
> Un-comment this block:
> https://github.com/apache/maven-doxia/blob/c439714e8f4a9e86f9962ac6be9a0077ae9b4d30/doxia-modules/doxia-module-markdown/src/main/java/org/apache/maven/doxia/module/markdown/FlexmarkDoxiaNodeRenderer.java#L103
> This should do the trick.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7032) Option -B still showing formatting when used with --version
[
https://issues.apache.org/jira/browse/MNG-7032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1720#comment-1720
]
Hudson commented on MNG-7032:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-7032_versioncolours
#3
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7032_versioncolours/3/
> Option -B still showing formatting when used with --version
> ---
>
> Key: MNG-7032
> URL: https://issues.apache.org/jira/browse/MNG-7032
> Project: Maven
> Issue Type: Bug
> Components: Command Line, Logging
>Affects Versions: 3.6.3
> Environment: Running Ubuntu 20.04.1 LTS (Focal Fossa)
> Apache Maven 3.6.3
> Maven home: /usr/share/maven
> Java version: 11.0.8, vendor: AdoptOpenJDK, runtime: /opt/java/jdk-11.0.8+10
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "linux", version: "5.4.0-54-generic", arch: "amd64", family: "unix"
>Reporter: Christian Koop
>Priority: Major
> Labels: easyfix
> Fix For: 4.0.x-candidate
>
>
> When running {{mvn -B --version}} the first line ({{'Apache Maven 3.6.3'}})
> is written in bold although the option {{-B}} should have stripped that as it
> does with color in combination with other options.
> This causes an issue when logging to a file as the ASCII escape sequence is
> written to it in plain text (causing confusion).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-4660) Use of --resume-from in multi-module project fails with missing inter-module dependencies
[ https://issues.apache.org/jira/browse/MNG-4660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1724#comment-1724 ] Hudson commented on MNG-4660: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-7032_versioncolours #3 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7032_versioncolours/3/ > Use of --resume-from in multi-module project fails with missing inter-module > dependencies > - > > Key: MNG-4660 > URL: https://issues.apache.org/jira/browse/MNG-4660 > Project: Maven > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 2.2.1, 3.0-beta-1 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700) > Java version: 1.6.0_17 > Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x" version: "10.6.3" arch: "x86_64" Family: "mac" >Reporter: Brian Ferris >Assignee: Robert Scholte >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > Attachments: modules-parent.tar.gz > > Time Spent: 1h 20m > Remaining Estimate: 0h > > In a simple multi-module project with a parent pom "modules-parent", two sub > modules "module-a" and "module-b", where B depends on A, I've not been able > to get the Maven "--resume-from" feature to work. > Specifically, I expect: > > mvn --resume-from module-b test > would resume execution of the "test" goal in "module-b". Instead it fails > with a missing artifact error: > > [INFO] Failed to resolve artifact. > > > > Missing: > > -- > > 1) org.test:module-a:jar:0.0.1-SNAPSHOT > Why isn't Maven resolving the within-multi-module dependency? I've attached > a simple project that reproduces the problem with Maven 2.2.1 and Maven > 3.0-beta-1. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7046) Revert MNG-5639 and make repo config static only
[ https://issues.apache.org/jira/browse/MNG-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1722#comment-1722 ] Hudson commented on MNG-7046: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-7032_versioncolours #3 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7032_versioncolours/3/ > Revert MNG-5639 and make repo config static only > > > Key: MNG-7046 > URL: https://issues.apache.org/jira/browse/MNG-7046 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories, Dependencies >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > As discussed in MNG-5639 repositories should always be known upfront, they > have to be static to avoid chicken and egg situations, a project should not > influence settings. It should be the way around. > In subsequent ticket it will be verified that repo configuration does not > contain any expression: > https://github.com/apache/maven/commit/d411c3fa98832e7d86d901fe86ff63ba907cf868#commitcomment-44782281. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5639) Support resolution of Import Scope POMs from Repo that contains a ${parameter}
[
https://issues.apache.org/jira/browse/MNG-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1723#comment-1723
]
Hudson commented on MNG-5639:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-7032_versioncolours
#3
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7032_versioncolours/3/
> Support resolution of Import Scope POMs from Repo that contains a ${parameter}
> --
>
> Key: MNG-5639
> URL: https://issues.apache.org/jira/browse/MNG-5639
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.2.1
>Reporter: Mark Ingram
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 3.2.2
>
> Attachments: pom.xml
>
>
> Running mvn help:effective-pom on the attached POM:
> {noformat}[ERROR] The project
> com.ming:maven-failing-import-pom-example:1.0.0-SNAPSHOT
> (C:\wip\scratch-dev\maven-import-dependency-management\pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not transfer artifact
> org.springframework:spring-framework-bom:pom:4.0.0.R2 from/to
> spring-milestones (${spring.url}): No connector available to access
> repository spring-milestones (${spring.url}) of type default using the
> available factories WagonRepositoryConnectorFactory @ line 20, column 25 ->
> Help 2]{noformat}
> mvn help:effective-pom -Prepo-will-succeed works as expected.
> Note that prior to attempting the failing resolution, the full project POM
> model has successfully been resolved. So the correct value for the property
> is known and could in theory be substituted into the repository URL before
> the failing import pom resolve attempt.
> Will create a Github pull request with one possible solution to this - it
> includes a JUnit test case.
> Note: agreed this is a contrived example. To try and give an idea of the
> actual use case - several development streams are setup with individual
> sandboxed Nexus repository holding specific version of several shared
> components. The repository configuration uses the pattern
> $\{nexus.baseurl}/content/groups/$\{stream.name} with the properties set in
> settings.xml file.
> One workaround would be to create profiles for every work stream that
> explicitly list the full repository URL, even then the above feature would be
> nice to allow the $\{nexus.baseurl} to avoid repeating that part.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7022) Remove o.a.m.lifecycle.mapping.Lifecycle optional mojos backward compat code
[
https://issues.apache.org/jira/browse/MNG-7022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1721#comment-1721
]
Hudson commented on MNG-7022:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-7032_versioncolours
#3
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7032_versioncolours/3/
> Remove o.a.m.lifecycle.mapping.Lifecycle optional mojos backward compat code
>
>
> Key: MNG-7022
> URL: https://issues.apache.org/jira/browse/MNG-7022
> Project: Maven
> Issue Type: Task
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> The handing of optional mojos was dropped long ago in
> ac8db28f3b8cd64192c3d038ee5557354ffb7a30, but the injection remained intact
> for backward compat reasons on legacy {{components.xml}}. Newer setups are
> encouraged to move to
> [{{lifecycle.xml}}|https://maven.apache.org/ref/3.6.3/maven-plugin-api/lifecycle-mappings.html].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MJLINK-39) Add support for choosing vm
[
https://issues.apache.org/jira/browse/MJLINK-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255547#comment-17255547
]
Michael Osipov commented on MJLINK-39:
--
As long as jlink does the right thing when invoked with that option, I see no
reason to not support this.
> Add support for choosing vm
> ---
>
> Key: MJLINK-39
> URL: https://issues.apache.org/jira/browse/MJLINK-39
> Project: Maven JLink Plugin
> Issue Type: New Feature
>Affects Versions: 3.0.0-alpha-1, 3.0.0, 3.1.0
>Reporter: Nicolai Ehemann
>Assignee: Benjamin Marwell
>Priority: Major
>
> With jlink it is possible to select which vm will be bundled:
> {code:java}
> --vm={client|server|minimal|all}
> Selects the HotSpot VM in the output image. Default is all{code}
> This should also be possible with the plugin.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-resolver] michael-o commented on pull request #77: [MRESOLVER-145] SyncContext implementations
michael-o commented on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-751690622 @rmannibucau I would not exclude them from the delivery, but mark as experimental. I want people to test them. If we don't make it publically available it won't be usable for most. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] rfscholte commented on a change in pull request #415: [MNG-7032] do not print colours for --version when in batch mode.
rfscholte commented on a change in pull request #415: URL: https://github.com/apache/maven/pull/415#discussion_r549321675 ## File path: maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java ## @@ -518,10 +520,9 @@ else if ( !"auto".equals( styleColor ) ) throw new IllegalArgumentException( "Invalid color configuration option [" + styleColor + "]. Supported values are (auto|always|never)." ); } -else if ( cliRequest.commandLine.hasOption( CLIManager.BATCH_MODE ) -|| cliRequest.commandLine.hasOption( CLIManager.LOG_FILE ) ) +else Review comment: this else-statement can now be removed, because the color mode has already been applied This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] rmannibucau commented on pull request #77: [MRESOLVER-145] SyncContext implementations
rmannibucau commented on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-751685353 @michael-o everything can be shaded but a few can be "hard". For properties what about supporting in the resolver.properties something like "configuration.external=path-to-conf-in-maven-base" (ex: configuration.external=conf/redisson.yaml) + if not set a minimal set of properties (host, port, ...). Kind of default simple mode and advanced mode through an external file. On the shading point, I would avoid it to keep the pluggability capabilities of external libs but I would isolate it from maven classpath (requires minimum reflection if well split, just a factory which returns a maven spi). @cstamas guess for hz we can focus on v4, nobody uses the v3 so let's not make it more complicated than needed to start as you mentionned. For redisson we can have testcontainers tests (with a flag to enable them in run-its probably since it requires docker locally and we don't want to force all dev to have it even if it is common these days). Will be easier than using a ProcessBuilder for redis and stay portable (the test can assume the OS env which is good for such simple cases). I also agree we have to focus on nolock/jvmlock/locallock (file) cases but if we consider hz/redisson as experimental then we should not put them in this repo (or enable the module for releases) IMHO. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on pull request #77: [MRESOLVER-145] SyncContext implementations
michael-o commented on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-751685099 As for testing Redis, I would not rely on tools like Docker because it is too OS specific. One could probe whether the redis daemon is in `PATH`. If yes, start it. Run tests, shut it down. This won't work on Windows of course, because Redis requires a POSIX-like OS. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] michael-o commented on pull request #415: [MNG-7032] do not print colours for --version when in batch mode.
michael-o commented on pull request #415: URL: https://github.com/apache/maven/pull/415#issuecomment-751684726 I will happily go through. I was never really happy that Jansi is installed by default even if batch or file mode were activated. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] cstamas edited a comment on pull request #77: [MRESOLVER-145] SyncContext implementations
cstamas edited a comment on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-751683148 Howdy @rmannibucau For now I consider both HZ and Redisson as "lab" implementation still, due these: * for HZ to work we either must use deprecated HZ 3.x call (HazelcastInstance#getSemaphore), or have a remote CP cluster set up (here, setup is somewhat similar to Redisson: you must have some remote "thing", server, cluster set up beforehand) * for Redisson, no clue how to set up tests (any ideas? can we use docker on Jenkins?) So for start, I'd focus on local (JVM local) locks and the two "extra" (again, for testing purposes: global and nolock) implementations. As they are pretty much in place. Given this PR does not include any of HZ or Redisson code into resolver (they are separate modules, it leaves it to integrator), I think we still have time to solve both questions, that IMO are valid and actually sounds useful (generic props for configuration). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] cstamas edited a comment on pull request #77: [MRESOLVER-145] SyncContext implementations
cstamas edited a comment on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-751683148 Howdy @rmannibucau For now I consider both HZ and Redisson as "lab" implementation still, due these: * for HZ to work we either must use deprecated HZ 3.x call (HazelcastInstance#getSemaphore), or have a remote CP cluster set up (here, setup is somewhat similar to Redisson: you must have some remote "thing", server, cluster set up beforehand) * for Redisson, no clue how to set up tests (any ideas?) So for start, I'd focus on local (JVM local) locks and the two "extra" (again, for testing purposes: global and nolock) implementations. As they are pretty much in place. Given this PR does not include any of HZ or Redisson code into resolver (they are separate modules, it leaves it to integrator), I think we still have time to solve both questions, that IMO are valid and actually sounds useful (generic props for configuration). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (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=17255537#comment-17255537
]
Michael Osipov edited comment on MRESOLVER-153 at 12/28/20, 11:40 AM:
--
[~Brand],
thanks for the update. The flag use makes sense.
You are right, of course, about the synchronization. That's the way it was for
years and it was faulty. We had numerous tickets about that. As [~cstamas]
said, we are working on it. My Redisson-based implementation does quite well,
more to come from Tamás. You are cordially invited to review and test the PR.
Let me make this clear, I think that synchronization in the
{{TrackingFileManager}} is the wrong place to be. So I am grateful for your
report and it happily proves the lack of proper synchronization.
Run this on Maven Core ITs and you see {{maven-metadata.xml}} fail quite quick:
{{rm -rf /tmp/repo* ; ~/apache-maven-4.0.0-alpha-1-SNAPSHOT/bin/mvn
-Dmaven.repo.local=/tmp/repo4 clean install -T4C -DskipTests
-Dorg.slf4j.simpleLogger.showThreadName=true -U -B}}.
was (Author: michael-o):
[~Brand],
thanks for the update. The flag use makes sense.
You are right, of course, about the synchronization. That's the way it was for
years and it was faulty. We had numerous tickets about that. As [~cstamas]
said, we are working on it. My Redisson-based implementation does quite well,
more to come from Tamás. You are cordially invited to review and test the PR.
Let me make this clear, I think that synchronization in the
{{TrackingFileManager}} is the wrong place to be. So I am grateful for your
report and it happily proves the lack of proper synchronization.
Run this on Maven Core ITs and you see {{maven-metadata.xml}} fail quite quick:
{{ rm -rf /tmp/repo* ; ~/apache-maven-4.0.0-alpha-1-SNAPSHOT/bin/mvn
-Dmaven.repo.local=/tmp/repo4 clean install -T4C -DskipTests
-Dorg.slf4j.simpleLogger.showThreadName=true -U -B}}.
> 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
> Attachments: screenshot-1.png
>
>
> 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)
>
[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=17255537#comment-17255537
]
Michael Osipov edited comment on MRESOLVER-153 at 12/28/20, 11:39 AM:
--
[~Brand],
thanks for the update. The flag use makes sense.
You are right, of course, about the synchronization. That's the way it was for
years and it was faulty. We had numerous tickets about that. As [~cstamas]
said, we are working on it. My Redisson-based implementation does quite well,
more to come from Tamás. You are cordially invited to review and test the PR.
Let me make this clear, I think that synchronization in the
{{TrackingFileManager}} is the wrong place to be. So I am grateful for your
report and it happily proves the lack of proper synchronization.
Run this on Maven Core ITs and you see {{maven-metadata.xml}} fail quite quick:
{{ rm -rf /tmp/repo* ; ~/apache-maven-4.0.0-alpha-1-SNAPSHOT/bin/mvn
-Dmaven.repo.local=/tmp/repo4 clean install -T4C -DskipTests
-Dorg.slf4j.simpleLogger.showThreadName=true -U -B}}.
was (Author: michael-o):
[~Brand],
thanks for the update. The flag use makes sense.
You are right, of course, about the synchronization. That's the way it was for
years and it was faulty. We had numerous tickets about that. As [~cstamas]
said, we are working on it. My Redisson-based implementation does quite well,
more to come from Tamás. You are cordially invited to review and test the PR.
> 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
> Attachments: screenshot-1.png
>
>
> 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)
>
[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=17255537#comment-17255537
]
Michael Osipov commented on MRESOLVER-153:
--
[~Brand],
thanks for the update. The flag use makes sense.
You are right, of course, about the synchronization. That's the way it was for
years and it was faulty. We had numerous tickets about that. As [~cstamas]
said, we are working on it. My Redisson-based implementation does quite well,
more to come form Tamás.
> 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
> Attachments: screenshot-1.png
>
>
> 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
>
[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=17255537#comment-17255537
]
Michael Osipov edited comment on MRESOLVER-153 at 12/28/20, 11:36 AM:
--
[~Brand],
thanks for the update. The flag use makes sense.
You are right, of course, about the synchronization. That's the way it was for
years and it was faulty. We had numerous tickets about that. As [~cstamas]
said, we are working on it. My Redisson-based implementation does quite well,
more to come from Tamás. You are cordially invited to review and test the PR.
was (Author: michael-o):
[~Brand],
thanks for the update. The flag use makes sense.
You are right, of course, about the synchronization. That's the way it was for
years and it was faulty. We had numerous tickets about that. As [~cstamas]
said, we are working on it. My Redisson-based implementation does quite well,
more to come form Tamás.
> 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
> Attachments: screenshot-1.png
>
>
> 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
>
[GitHub] [maven] bmarwell commented on a change in pull request #415: [MNG-7032] do not print colours for --version when in batch mode.
bmarwell commented on a change in pull request #415:
URL: https://github.com/apache/maven/pull/415#discussion_r549316323
##
File path: maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java
##
@@ -433,6 +433,8 @@ void cli( CliRequest cliRequest )
if ( cliRequest.commandLine.hasOption( CLIManager.VERSION ) )
{
+// MNG-7032: Also disable colours if in batch mode
Review comment:
Thanks, that is helpful insight. I now see why the comment is redundant.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on pull request #77: [MRESOLVER-145] SyncContext implementations
cstamas commented on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-751683148 Howdy @rmannibucau For now I consider both HZ and Redisson as "lab" implementation still, due these: * for HZ to work we either must use deprecated HZ 3.x call (HazelcastInstance#getSemaphore), or have a remote CP cluster set up (here, setup is somewhat similar to Redisson: you must have some remote "thing", server, cluster set up beforehand) * for Redisson, no clue how to test (any ideas?) So for start, I'd focus on local (JVM local) locks and the two "extra" (again, for testing purposes: global and nolock) implementations. As they are pretty much in place. Given this PR does not include any of HZ or Redisson code into resolver (they are separate modules, it leaves it to integrator), I think we still have time to solve both questions, that IMO are valid and actually sounds useful (generic props for configuration). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (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=17255522#comment-17255522
]
Michael Osipov edited comment on MRESOLVER-153 at 12/28/20, 11:34 AM:
--
[~michael-o] Regarding
> Why do you pass {{-Daether.updateCheckManager.sessionState=false}}? What
> happens when you leave this out?
With this flag set, the problem is reproducible more often as it will check the
dependencies every time and doesn't store it in the session.
> Can you try {{-Daether.metadataResolver.threads=1}} for testing purposes?
I executed a run of all our integration tests and they passed. We'll then keep
this flag set until this is fixed in a future Maven nightly version.
Regarding the synchronization: There you already discussed on how to restore
it. My two cents on that topic are the following:
There is the concept of a {{SyncContext}} and components as the
{{TrackingFileManager}} rely on this to implement proper synchronization. Why
having a {{DefaultSyncContext}} in place that does no synchronization at all?
Having this noop {{SyncContext}} could produce other errors like the one I
reported. Therefore instead of checking if the {{DefaultSyncContext}} is used
in the {{TrackingFileManager}}, why not just implement basic synchronization in
the {{DefaultSyncContext}, }rely on it and on top prevent similar errors on the
other usages of {{SyncContext}}?
was (Author: brand):
[~michael-o] Regarding
> Why do you pass {{-Daether.updateCheckManager.sessionState=false}}? What
> happens when you leave this out?
With this flag set, the problem is reproducible more often as it will check the
dependencies every time and doesn't store it in the session.
> Can you try {{-Daether.metadataResolver.threads=1}} for testing purposes?
I executed a run of all our integration tests and they passed. We'll then keep
this flag set until this is fixed in a future Maven nightly version.
Regarding the synchronization: There you already discussed on how to restore
it. My two cents on that topic are the following:
There is the concept of a {{SyncContext}} and components as the
{{TrackingFileManager}} rely on this to implement proper synchronization. Why
having a {{DefaultSyncContext}} in place that does no synchronization at all?
Having this noop {{SyncContext}} could produce other errors like the one I
reported. Therefore instead of checking if the {{DefaultSyncContext}} is used
in the {{TrackingFileManager}}, why not just implement basic synchronization in
the {{DefaultSyncContext, }}rely on it and on top prevent similar errors on the
other usages of {{SyncContext}}?
> 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
> Attachments: screenshot-1.png
>
>
> 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
>
[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=17255522#comment-17255522
]
Michael Osipov edited comment on MRESOLVER-153 at 12/28/20, 11:34 AM:
--
[~michael-o] Regarding
> Why do you pass {{-Daether.updateCheckManager.sessionState=false}}? What
> happens when you leave this out?
With this flag set, the problem is reproducible more often as it will check the
dependencies every time and doesn't store it in the session.
> Can you try {{-Daether.metadataResolver.threads=1}} for testing purposes?
I executed a run of all our integration tests and they passed. We'll then keep
this flag set until this is fixed in a future Maven nightly version.
Regarding the synchronization: There you already discussed on how to restore
it. My two cents on that topic are the following:
There is the concept of a {{SyncContext}} and components as the
{{TrackingFileManager}} rely on this to implement proper synchronization. Why
having a {{DefaultSyncContext}} in place that does no synchronization at all?
Having this noop {{SyncContext}} could produce other errors like the one I
reported. Therefore instead of checking if the {{DefaultSyncContext}} is used
in the {{TrackingFileManager}}, why not just implement basic synchronization in
the {{DefaultSyncContext}}, rely on it and on top prevent similar errors on the
other usages of {{SyncContext}}?
was (Author: brand):
[~michael-o] Regarding
> Why do you pass {{-Daether.updateCheckManager.sessionState=false}}? What
> happens when you leave this out?
With this flag set, the problem is reproducible more often as it will check the
dependencies every time and doesn't store it in the session.
> Can you try {{-Daether.metadataResolver.threads=1}} for testing purposes?
I executed a run of all our integration tests and they passed. We'll then keep
this flag set until this is fixed in a future Maven nightly version.
Regarding the synchronization: There you already discussed on how to restore
it. My two cents on that topic are the following:
There is the concept of a {{SyncContext}} and components as the
{{TrackingFileManager}} rely on this to implement proper synchronization. Why
having a {{DefaultSyncContext}} in place that does no synchronization at all?
Having this noop {{SyncContext}} could produce other errors like the one I
reported. Therefore instead of checking if the {{DefaultSyncContext}} is used
in the {{TrackingFileManager}}, why not just implement basic synchronization in
the {{DefaultSyncContext}, }rely on it and on top prevent similar errors on the
other usages of {{SyncContext}}?
> 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
> Attachments: screenshot-1.png
>
>
> 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
>
[GitHub] [maven-resolver] michael-o commented on pull request #77: [MRESOLVER-145] SyncContext implementations
michael-o commented on pull request #77: URL: https://github.com/apache/maven-resolver/pull/77#issuecomment-751682400 @rmannibucau 1) This makes sense, but I don't want to create a mapping from properties to the object ob Redisson. The YAML configuration is so vast that I want to leave it to the user. As you can see in my code I tried to keep it as simple as possible. 2) That's a good question. I thougt about providing a shaded über JAR for this, but don't know whether everything can be shaded or not. If you have ideas for 1), please provide. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
