[jira] [Updated] (MPH-160) add source location in comments to effective pom.xml
[ https://issues.apache.org/jira/browse/MPH-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MPH-160: -- Description: during in-memory effective pom building (by maven-model-builder), the source location of content is kept in memory: see [Modello documentation on location tracking|https://codehaus-plexus.github.io/modello/location-tracking.html] and MNG-1803 for its integration into Maven model adding this information as comment on every line of generated XML would ease tracking for end users (and not only m2e users, who get "Jump to location" hint when editing their pom.xml in Eclipse...) This will require a Modello enhancement (see [Modello #28|https://github.com/codehaus-plexus/modello/issues/28]) then integration (idea found during Devoxx 2018 Maven BoF, since users were missing ways to diagnose unexpected result in effective pom) was: during in-memory effective pom building (by maven-model-builder), the source location of content is kept in memory: see [Modello documentation on location tracking|https://codehaus-plexus.github.io/modello/location-tracking.html] and MNG-1803 for its integration into Maven model adding this information as comment on every line of generated XML would ease tracking for end users (and not only m2e users, who get "Jump to location" hint when editing their pom.xml in Eclipse...) This will probably require a Modello enhancement then integration (idea found during Devoxx 2018 Maven BoF, since users were missing ways to diagnose unexpected result in effective pom) > add source location in comments to effective pom.xml > > > Key: MPH-160 > URL: https://issues.apache.org/jira/browse/MPH-160 > Project: Maven Help Plugin > Issue Type: New Feature > Components: effective-pom >Affects Versions: 3.1.0 >Reporter: Hervé Boutemy >Priority: Major > > during in-memory effective pom building (by maven-model-builder), the source > location of content is kept in memory: see [Modello documentation on location > tracking|https://codehaus-plexus.github.io/modello/location-tracking.html] > and MNG-1803 for its integration into Maven model > adding this information as comment on every line of generated XML would ease > tracking for end users (and not only m2e users, who get "Jump to location" > hint when editing their pom.xml in Eclipse...) > This will require a Modello enhancement (see [Modello > #28|https://github.com/codehaus-plexus/modello/issues/28]) then integration > (idea found during Devoxx 2018 Maven BoF, since users were missing ways to > diagnose unexpected result in effective pom) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MPH-160) add source location in comments to effective pom.xml
[
https://issues.apache.org/jira/browse/MPH-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16766889#comment-16766889
]
Hervé Boutemy commented on MPH-160:
---
initial implementation of Modello {{xpp3-extended-writer}} in
https://github.com/codehaus-plexus/modello/tree/xpp3-extended-writer
> add source location in comments to effective pom.xml
>
>
> Key: MPH-160
> URL: https://issues.apache.org/jira/browse/MPH-160
> Project: Maven Help Plugin
> Issue Type: New Feature
> Components: effective-pom
>Affects Versions: 3.1.0
>Reporter: Hervé Boutemy
>Priority: Major
>
> during in-memory effective pom building (by maven-model-builder), the source
> location of content is kept in memory: see [Modello documentation on location
> tracking|https://codehaus-plexus.github.io/modello/location-tracking.html]
> and MNG-1803 for its integration into Maven model
> adding this information as comment on every line of generated XML would ease
> tracking for end users (and not only m2e users, who get "Jump to location"
> hint when editing their pom.xml in Eclipse...)
> This will probably require a Modello enhancement then integration
> (idea found during Devoxx 2018 Maven BoF, since users were missing ways to
> diagnose unexpected result in effective pom)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6590) java.lang.IllegalStateException: Duplicate artifact resolution result
[
https://issues.apache.org/jira/browse/MNG-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy (*$^¨%`£) updated MNG-6590:
Description:
{code:java}
[ERROR] Duplicate artifact resolution result for project
org.eclipse.jetty:jetty-project:9.4.15-SNAPSHOT
java.lang.IllegalStateException: Duplicate artifact resolution result for
project org.eclipse.jetty:jetty-project:9.4.15-SNAPSHOT
at
org.apache.maven.project.artifact.DefaultProjectArtifactsCache.assertUniqueKey
(DefaultProjectArtifactsCache.java:218)
at org.apache.maven.project.artifact.DefaultProjectArtifactsCache.put
(DefaultProjectArtifactsCache.java:204)
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
(LifecycleDependencyResolver.java:149)
at
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
(MojoExecutor.java:248)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:202)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.[INFO] Downloading from
build-master-nexus:
http://10.0.0.10:8081/repository/maven-public/org/codehaus/plexus/plexus-utils/3.1.0/plexus-utils-3.1.0.pom
MojoExecutor.execute (MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:200)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:196)
at java.util.concurrent.FutureTask.run (FutureTask.java:264)
at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
at java.util.concurrent.FutureTask.run (FutureTask.java:264)
at java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1128)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:628)
at java.lang.Thread.run (Thread.java:834)
[ERROR] java.lang.IllegalStateException: Duplicate artifact resolution result
for project org.eclipse.jetty:jetty-project:9.4.15-SNAPSHOT
java.util.concurrent.ExecutionException: java.lang.IllegalStateException:
Duplicate artifact resolution result for project
org.eclipse.jetty:jetty-project:9.4.15-SNAPSHOT
at java.util.concurrent.FutureTask.report (FutureTask.java:122)
at java.util.concurrent.FutureTask.get (FutureTask.java:191)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder.multiThreadedProjectTaskSegmentBuild
(MultiThrea[INFO] Downloaded from build-master-nexus:
http://10.0.0.10:8081/repository/maven-public/org/codehaus/plexus/plexus-utils/3.1.0/plexus-utils-3.1.0.pom
(4.7 kB at 1.2 MB/s)
dedBuilder.java:140)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder.build
(MultiThreadedBuilder.java:101)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.[INFO] Downloading from build-master-nexus:
http://10.0.0.10:8081/repository/maven-public/org/codehaus/plexus/plexus/4.0/plexus-4.0.pom
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:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
Caused by: java.lang.IllegalStateException: Duplicate artifact resolution
result for project org.eclipse.jetty:jetty-project:9.4.15-SNAPSHOT
at
org.apache.maven.project.artifact.DefaultProjectArtifactsCache.assertUniqueKey
(DefaultProjectArtifactsCache.java:218)
at org.apache.maven.project.artifact.DefaultProjectArtifactsCache.put
(DefaultProjectArtifactsCache.java:204)
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
(LifecycleDependencyResolver.java:149)
at
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
(MojoExecutor.java:248)
at
[jira] [Updated] (MNG-6590) DefaultProjectArtifactsCache java.lang.IllegalStateException: Duplicate artifact resolution result
[
https://issues.apache.org/jira/browse/MNG-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy (*$^¨%`£) updated MNG-6590:
Summary: DefaultProjectArtifactsCache java.lang.IllegalStateException:
Duplicate artifact resolution result (was: java.lang.IllegalStateException:
Duplicate artifact resolution result)
> DefaultProjectArtifactsCache java.lang.IllegalStateException: Duplicate
> artifact resolution result
> --
>
> Key: MNG-6590
> URL: https://issues.apache.org/jira/browse/MNG-6590
> Project: Maven
> Issue Type: Bug
>Reporter: Olivier Lamy (*$^¨%`£)
>Priority: Major
>
> {code:java}
> [ERROR] Duplicate artifact resolution result for project
> org.eclipse.jetty:jetty-project:9.4.15-SNAPSHOT
> java.lang.IllegalStateException: Duplicate artifact resolution result for
> project org.eclipse.jetty:jetty-project:9.4.15-SNAPSHOT
> at
> org.apache.maven.project.artifact.DefaultProjectArtifactsCache.assertUniqueKey
> (DefaultProjectArtifactsCache.java:218)
> at org.apache.maven.project.artifact.DefaultProjectArtifactsCache.put
> (DefaultProjectArtifactsCache.java:204)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:149)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.[INFO] Downloading from
> build-master-nexus:
> http://10.0.0.10:8081/repository/maven-public/org/codehaus/plexus/plexus-utils/3.1.0/plexus-utils-3.1.0.pom
> MojoExecutor.execute (MojoExecutor.java:148)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:200)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:196)
> at java.util.concurrent.FutureTask.run (FutureTask.java:264)
> at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
> at java.util.concurrent.FutureTask.run (FutureTask.java:264)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1128)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:628)
> at java.lang.Thread.run (Thread.java:834)
> [ERROR] java.lang.IllegalStateException: Duplicate artifact resolution result
> for project org.eclipse.jetty:jetty-project:9.4.15-SNAPSHOT
> java.util.concurrent.ExecutionException: java.lang.IllegalStateException:
> Duplicate artifact resolution result for project
> org.eclipse.jetty:jetty-project:9.4.15-SNAPSHOT
> at java.util.concurrent.FutureTask.report (FutureTask.java:122)
> at java.util.concurrent.FutureTask.get (FutureTask.java:191)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder.multiThreadedProjectTaskSegmentBuild
> (MultiThrea[INFO] Downloaded from build-master-nexus:
> http://10.0.0.10:8081/repository/maven-public/org/codehaus/plexus/plexus-utils/3.1.0/plexus-utils-3.1.0.pom
> (4.7 kB at 1.2 MB/s)
> dedBuilder.java:140)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder.build
> (MultiThreadedBuilder.java:101)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.[INFO] Downloading from build-master-nexus:
> http://10.0.0.10:8081/repository/maven-public/org/codehaus/plexus/plexus/4.0/plexus-4.0.pom
> 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:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:415)
> at
[jira] [Created] (MNG-6590) java.lang.IllegalStateException: Duplicate artifact resolution result
Olivier Lamy (*$^¨%`£) created MNG-6590:
---
Summary: java.lang.IllegalStateException: Duplicate artifact
resolution result
Key: MNG-6590
URL: https://issues.apache.org/jira/browse/MNG-6590
Project: Maven
Issue Type: Bug
Reporter: Olivier Lamy (*$^¨%`£)
{code:java}
[ERROR] java.lang.IllegalStateException: Duplicate artifact resolution result
for project org.eclipse.jetty:jetty-project:9.4.15-SNAPSHOT
java.util.concurrent.ExecutionException: java.lang.IllegalStateException:
Duplicate artifact resolution result for project
org.eclipse.jetty:jetty-project:9.4.15-SNAPSHOT
at java.util.concurrent.FutureTask.report (FutureTask.java:122)
at java.util.concurrent.FutureTask.get (FutureTask.java:191)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder.multiThreadedProjectTaskSegmentBuild
(MultiThrea[INFO] Downloaded from build-master-nexus:
http://10.0.0.10:8081/repository/maven-public/org/codehaus/plexus/plexus-utils/3.1.0/plexus-utils-3.1.0.pom
(4.7 kB at 1.2 MB/s)
dedBuilder.java:140)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder.build
(MultiThreadedBuilder.java:101)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
at jdk.[INFO] Downloading from build-master-nexus:
http://10.0.0.10:8081/repository/maven-public/org/codehaus/plexus/plexus/4.0/plexus-4.0.pom
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:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:356)
Caused by: java.lang.IllegalStateException: Duplicate artifact resolution
result for project org.eclipse.jetty:jetty-project:9.4.15-SNAPSHOT
at
org.apache.maven.project.artifact.DefaultProjectArtifactsCache.assertUniqueKey
(DefaultProjectArtifactsCache.java:218)
at org.apache.maven.project.artifact.DefaultProjectArtifactsCache.put
(DefaultProjectArtifactsCache.java:204)
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
(LifecycleDependencyResolver.java:149)
at
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
(MojoExecutor.java:248)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:202)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuil[INFO]
Downloaded from build-master-nexus:
http://10.0.0.10:8081/repository/maven-public/org/codehaus/plexus/plexus/4.0/plexus-4.0.pom
(22 kB at 5.4 MB/s)
der$1.call (MultiThreadedBuilder.java:200)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:196)
at java.util.concurrent.FutureTask.run (FutureTask.java:264)
at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
at java.util.concurrent.FutureTask.run (FutureTask.java:264)
at java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1128)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:628)
at java.lang.Thread.run (Thread.java:834)
[ERROR]
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-4996) Maven3 parallel build fails occasionally for classpath problems.
[
https://issues.apache.org/jira/browse/MNG-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16766718#comment-16766718
]
Kane Gong commented on MNG-4996:
I had the similar issue when use -T 6 in maven build command line.
One is related to compiler plugin:
{code:java}
18:51:02 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
(default-compile) on project module1: Compilation failure
18:51:02 error: error reading
/root/.m2/repository/com/fasterxml/jackson/core/jackson-databind/2.9.6/jackson-databind-2.9.6.jar;
zip file is empty
{code}
The other is related to assembly plugin:
{code:java}
09:55:42 Caused by:
org.apache.maven.plugin.assembly.archive.ArchiveCreationException: Error adding
file to archive:
/root/module1/${project.build.directory}/${project.build.finalName}.jar isn't a
file.
09:55:42at
org.apache.maven.plugin.assembly.archive.phase.FileItemAssemblyPhase.execute(FileItemAssemblyPhase.java:126)
09:55:42at
org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:187)
09:55:42at
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:354)
09:55:42... 13 more
09:55:42 Caused by: org.codehaus.plexus.archiver.ArchiverException:
09:55:42at
org.codehaus.plexus.archiver.AbstractArchiver.addFile(AbstractArchiver.java:292)
09:55:42at
org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.addFile(AssemblyProxyArchiver.java:448)
09:55:42at
org.apache.maven.plugin.assembly.archive.phase.FileItemAssemblyPhase.execute(FileItemAssemblyPhase.java:122)
09:55:42... 15 more
{code}
Not sure it was caused by Maven framework or the specific plugin.
Maven version: 3.3.9
Maven compiler version: maven-compiler-plugin:2.3.2
Maven assembly plugin version: maven-assembly-plugin:2.2-beta-3
> Maven3 parallel build fails occasionally for classpath problems.
>
>
> Key: MNG-4996
> URL: https://issues.apache.org/jira/browse/MNG-4996
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0.1
> Environment: maven 3.0.1, maven 3.0
>Reporter: Kari J. Niemi
>Assignee: Kristian Rosenvold
>Priority: Major
>
> In a multimodule (>120 modules) maven build, the compiler plug-in would seem
> to fail in creating a correct class-path every now and then.
> Instead of this entry in maven -X logs for a single module build:
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
> configurator -->
> ..
> [DEBUG] (f) classpathElements =
> [/home/karniemi/"mymodulepath"/target/classes,
> /home/karniemi/.m2/repository/org/apache/servicemix/servicemix-utils/1.2.0/servicemix-utils-1.2.0.jar,
>
> /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-stax-api_1.0_spec/1.0.1/geronimo-stax-api_1.0_spec-1.0.1.jar,
>
> /home/karniemi/.m2/repository/org/codehaus/woodstox/wstx-asl/3.2.6/wstx-asl-3.2.6.jar,
>
> /home/karniemi/.m2/repository/org/apache/servicemix/specs/org.apache.servicemix.specs.jbi-api-1.0/1.4.0/org.apache.servicemix.specs.jbi-api-1.0-1.4.0.jar,
>
> /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-activation_1.1_spec/1.0.2/geronimo-activation_1.1_spec-1.0.2.jar,
> /home/karniemi/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar]
>
> every now and then I get this in the parallel build:
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
> configurator -->
> ...
> [DEBUG] (f) classpathElements =
> [/home/karniemi/"mymodulepath"/target/classes]
>
> And of course the compilation fails because none of the dependencies are
> added to the classpath. Sometimes it goes fine in the multi-module build, but
> every now and then it fails for this.
> In both maven runs I can see that the dependencies are resolved fine:
> --
> [DEBUG] "mymodule":jar:DYNAMIC-SNAPSHOT
> [DEBUG]junit:junit:jar:4.7:test
> [DEBUG]org.apache.servicemix:servicemix-utils:jar:1.2.0:provided
> [DEBUG]
> org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:provided
> [DEBUG] org.codehaus.woodstox:wstx-asl:jar:3.2.6:provided
> [DEBUG]
> org.apache.servicemix.specs:org.apache.servicemix.specs.jbi-api-1.0:jar:1.4.0:provided
> (scope managed from compile) (version managed from 1.1.0)
> [DEBUG]
> org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:provided
> [DEBUG]log4j:log4j:jar:1.2.14:provided
> ---
>
> The pluginArtifactMap looks like this:
>
> [DEBUG]
[jira] [Commented] (MNG-6575) make Dependency immutable
[
https://issues.apache.org/jira/browse/MNG-6575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16766534#comment-16766534
]
Yann Dameron commented on MNG-6575:
---
Hi guys,
I'm new on Maven source code but make Dependency immutable looks like a massive
change and like Robert I don't get how we can do that without impacting
signatures, existing plugins, etc.
As I reported the memory issues, I tried to find a solution to evaluate the
memory gain using wrappers.
I added a class which is responsible of caching all the Dependency objects
I created a DependencyWrapper class which extends Dependency and takes a
Dependency object in the constructor (the original one, which comes from the
cache).
This class overrides all methods. As long as modifiers are not called, all the
getters redirect to the original dependency.
As soon as a setter is called, original dependency is nullified and the
DependencyWrapper class behaves like the Dependency one...
Finally, I modified the mdo to use this cache and wrappers.
* BaseModel.setDependencies
* DependencyManagement.setDependencies
* ModelMerger.mergeModelBase_Dependencies
* ModelMerger.mergeDependencyManagement_Dependencies
I know I missed some places, (for example if DependencyManagement.addDependency
is called, the cache and wrappers will not be used) but it was a basic attempt
to evaluate the memory gain and prevent API changes.
Doing that, the memory dump is reduced to 3.5Gb (8Gb with MNG-6571 fix, 12Gb
with maven 3.6.0).
Do you think it's worth creating a patch for review and improvements ? I
appreciate this approach could be a blocker so just let me know :)
> make Dependency immutable
> -
>
> Key: MNG-6575
> URL: https://issues.apache.org/jira/browse/MNG-6575
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies, Inheritance and Interpolation
>Affects Versions: 3.6.0
>Reporter: Hervé Boutemy
>Priority: Major
>
> while working on Maven memory consumption issue MNG-6571, once VersionRange
> is made immutable, memory used was divided by 2: the next big expected win is
> to make Dependency immutable, which would probably once again divide memory
> by 2 because the vast majority of time, dependencies (be it in
> dependencyManagement or base dependencies) are inherited without any
> modification
> this will require to change
> [ModelMerger|https://maven.apache.org/ref/3.6.0/maven-model/apidocs/org/apache/maven/model/merge/ModelMerger.html]
> 's {{mergeDependency(Dependency target, Dependency source, boolean
> sourceDominant, Map context)}} signature, since is not really
> an immutable friendly signature
> and also make [Dependency
> code|https://maven.apache.org/ref/3.6.0/maven-model/apidocs/org/apache/maven/model/Dependency.html]
> immutable (generated by Modello)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6589) Document property maven.multiModuleProjectDirectory
Arend v. Reinersdorff created MNG-6589: -- Summary: Document property maven.multiModuleProjectDirectory Key: MNG-6589 URL: https://issues.apache.org/jira/browse/MNG-6589 Project: Maven Issue Type: Improvement Components: Documentation: General Affects Versions: 3.6.0 Reporter: Arend v. Reinersdorff I found out about maven.multiModuleProjectDirectory [on Stackoverflow|https://stackoverflow.com/questions/29778262/what-is-maven-multimoduleprojectdirectory-used-for/29780763]. This looks useful, but unfortunately there seems to be no documentation. Could maybe be added in one of these locations: * [https://cwiki.apache.org/confluence/display/MAVEN/Maven+Properties+Guide] * [http://maven.apache.org/ref/3.6.0/maven-model-builder/#Model_Interpolation] Suggestion: maven.multiModuleProjectDirectory - "The root directory of the multi module build. Also set for single module builds. Since Maven 3.3.1" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MSHARED-803) CommandLineUtils should set names for Threads
[
https://issues.apache.org/jira/browse/MSHARED-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Turbanov updated MSHARED-803:
Description:
CommandLineUtils now creates Threads with default names, like Thread-1
I noticed it in one of thread-dump for hang maven build
{noformat}
Thread-109" #309 daemon prio=5 os_prio=0 tid=0x7f1ce0005000 nid=0x13b3c
runnable [0x7f1d3a3f6000]
java.lang.Thread.State: RUNNABLE
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:255)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
- locked <0xebdca730> (a java.lang.UNIXProcess$ProcessPipeInputStream)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
- locked <0xebdca718> (a java.io.InputStreamReader)
at java.io.InputStreamReader.read(InputStreamReader.java:184)
at java.io.BufferedReader.fill(BufferedReader.java:161)
at java.io.BufferedReader.readLine(BufferedReader.java:324)
- locked <0xebdca718> (a java.io.InputStreamReader)
at java.io.BufferedReader.readLine(BufferedReader.java:389)
at
org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamPumper.run(StreamPumper.java:76)
{noformat}
It would be nice to set names for threads created by CommandLineUtils
{code}
final StreamFeeder inputFeeder = systemIn != null ? new StreamFeeder(
systemIn, p.getOutputStream() ) : null;
inputFeeder.setName("StreamFeeder-systemIn-" + p);
final StreamPumper outputPumper = new StreamPumper( p.getInputStream(),
systemOut );
inputFeeder.setName("StreamPumper-systemOut-" + p);
final StreamPumper errorPumper = new StreamPumper( p.getErrorStream(),
systemErr );
errorPumper.setName("StreamPumper-systemErr-" + p);
{code}
was:
CommandLineUtils now creates Threads with default names, like Thread-1
I noticed it in one of thread-dump for hang maven build
{noformat}
Thread-109" #309 daemon prio=5 os_prio=0 tid=0x7f1ce0005000 nid=0x13b3c
runnable [0x7f1d3a3f6000]
java.lang.Thread.State: RUNNABLE
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:255)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
- locked <0xebdca730> (a java.lang.UNIXProcess$ProcessPipeInputStream)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
- locked <0xebdca718> (a java.io.InputStreamReader)
at java.io.InputStreamReader.read(InputStreamReader.java:184)
at java.io.BufferedReader.fill(BufferedReader.java:161)
at java.io.BufferedReader.readLine(BufferedReader.java:324)
- locked <0xebdca718> (a java.io.InputStreamReader)
at java.io.BufferedReader.readLine(BufferedReader.java:389)
at
org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamPumper.run(StreamPumper.java:76)
{noformat}
It would be nice to set names for threads created by CommandLineUtils
{code}
final StreamFeeder inputFeeder = systemIn != null ? new StreamFeeder(
systemIn, p.getOutputStream() ) : null;
inputFeeder.setName("StreamFeeder-systemIn-process-" + p);
final StreamPumper outputPumper = new StreamPumper( p.getInputStream(),
systemOut );
inputFeeder.setName("StreamPumper-systemOut-process-" + p);
final StreamPumper errorPumper = new StreamPumper( p.getErrorStream(),
systemErr );
errorPumper.setName("StreamPumper-systemOut-process-" + p);
{code}
> CommandLineUtils should set names for Threads
> -
>
> Key: MSHARED-803
> URL: https://issues.apache.org/jira/browse/MSHARED-803
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-shared-utils
>Reporter: Andrey Turbanov
>Priority: Minor
>
> CommandLineUtils now creates Threads with default names, like Thread-1
> I noticed it in one of thread-dump for hang maven build
> {noformat}
> Thread-109" #309 daemon prio=5 os_prio=0 tid=0x7f1ce0005000 nid=0x13b3c
> runnable [0x7f1d3a3f6000]
>java.lang.Thread.State: RUNNABLE
> at java.io.FileInputStream.readBytes(Native Method)
> at java.io.FileInputStream.read(FileInputStream.java:255)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> - locked <0xebdca730> (a
>
[jira] [Created] (MSHARED-803) CommandLineUtils should set names for Threads
Andrey Turbanov created MSHARED-803:
---
Summary: CommandLineUtils should set names for Threads
Key: MSHARED-803
URL: https://issues.apache.org/jira/browse/MSHARED-803
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-shared-utils
Reporter: Andrey Turbanov
CommandLineUtils now creates Threads with default names, like Thread-1
I noticed it in one of thread-dump for hang maven build
{noformat}
Thread-109" #309 daemon prio=5 os_prio=0 tid=0x7f1ce0005000 nid=0x13b3c
runnable [0x7f1d3a3f6000]
java.lang.Thread.State: RUNNABLE
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:255)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
- locked <0xebdca730> (a java.lang.UNIXProcess$ProcessPipeInputStream)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
- locked <0xebdca718> (a java.io.InputStreamReader)
at java.io.InputStreamReader.read(InputStreamReader.java:184)
at java.io.BufferedReader.fill(BufferedReader.java:161)
at java.io.BufferedReader.readLine(BufferedReader.java:324)
- locked <0xebdca718> (a java.io.InputStreamReader)
at java.io.BufferedReader.readLine(BufferedReader.java:389)
at
org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamPumper.run(StreamPumper.java:76)
{noformat}
It would be nice to set names for threads created by CommandLineUtils
{code}
final StreamFeeder inputFeeder = systemIn != null ? new StreamFeeder(
systemIn, p.getOutputStream() ) : null;
inputFeeder.setName("StreamFeeder-systemIn-process-" + p);
final StreamPumper outputPumper = new StreamPumper( p.getInputStream(),
systemOut );
inputFeeder.setName("StreamPumper-systemOut-process-" + p);
final StreamPumper errorPumper = new StreamPumper( p.getErrorStream(),
systemErr );
errorPumper.setName("StreamPumper-systemOut-process-" + p);
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] cquoss commented on issue #88: SCM-917 add untag for svn
cquoss commented on issue #88: SCM-917 add untag for svn URL: https://github.com/apache/maven-scm/pull/88#issuecomment-462885808 Ping? This is an automated message from the Apache Git Service. To respond to the message, please log on 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 With regards, Apache Git Services
[jira] [Commented] (MNG-6588) Naming conventions should be more technical
[ https://issues.apache.org/jira/browse/MNG-6588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16766283#comment-16766283 ] Elliotte Rusty Harold commented on MNG-6588: Probably just a reference to the relevant Java name rules. I recall that these are the same. > Naming conventions should be more technical > --- > > Key: MNG-6588 > URL: https://issues.apache.org/jira/browse/MNG-6588 > Project: Maven > Issue Type: Improvement > Components: Documentation: General >Affects Versions: 3.6.0 >Reporter: Elliotte Rusty Harold >Priority: Minor > Labels: documentation > > We should give a precise grammar for group IDs, artifact IDs and versions on > https://maven.apache.org/guides/mini/guide-naming-conventions.html > rather than fuzzy language like "you can choose whatever name you want with > lowercase letters and no strange symbols" > This can probably be done by reference to the Java naming rules rather than > spelling it out. > The version section should mention semantic versioning and Snapshots. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6588) Naming conventions should be more technical
[ https://issues.apache.org/jira/browse/MNG-6588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16766232#comment-16766232 ] Michael Osipov commented on MNG-6588: - Are you thinking about regexp EBNF like in RFCs? > Naming conventions should be more technical > --- > > Key: MNG-6588 > URL: https://issues.apache.org/jira/browse/MNG-6588 > Project: Maven > Issue Type: Improvement > Components: Documentation: General >Affects Versions: 3.6.0 >Reporter: Elliotte Rusty Harold >Priority: Minor > Labels: documentation > > We should give a precise grammar for group IDs, artifact IDs and versions on > https://maven.apache.org/guides/mini/guide-naming-conventions.html > rather than fuzzy language like "you can choose whatever name you want with > lowercase letters and no strange symbols" > This can probably be done by reference to the Java naming rules rather than > spelling it out. > The version section should mention semantic versioning and Snapshots. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (WAGON-537) Maven transfer speed of large artifacts is slow due to unsuitable buffer strategy
[ https://issues.apache.org/jira/browse/WAGON-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16766228#comment-16766228 ] Michael Osipov commented on WAGON-537: -- Awesome, thank you very much for retesting. Funnily, this changed revealed a serious bug in JSch. > Maven transfer speed of large artifacts is slow due to unsuitable buffer > strategy > - > > Key: WAGON-537 > URL: https://issues.apache.org/jira/browse/WAGON-537 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-provider-api >Affects Versions: 3.2.0 > Environment: Windows 10, JDK 1.8, Nexus Artifact store > 100MB/s > network connection. >Reporter: Olaf Otto >Assignee: Michael Osipov >Priority: Major > Labels: perfomance > Fix For: 3.3.0, 3.3.1 > > Attachments: wagon-issue.png > > > We are using maven for build process automation with docker. This sometimes > involves uploading and downloading artifacts with a few gigabytes in size. > Here, maven's transfer speed is consistently and reproducibly slow. For > instance, an artifact with 7,5 GB in size took almost two hours to transfer > in spite of a 100 MB/s connection with respective reproducible download speed > from the remote nexus artifact repository when using a browser to download. > The same is true when uploding such an artifact. > I have investigated the issue using JProfiler. The result shows an issue in > AbstractWagon's transfer( Resource resource, InputStream input, OutputStream > output, int requestType, long maxSize ) method used for remote artifacts and > the same issue in AbstractHttpClientWagon#writeTo(OutputStream). > Here, the input stream is read in a loop using a 4 Kb buffer. Whenever data > is received, the received data is pushed to downstream listeners via > fireTransferProgress. These listeners (or rather consumers) perform expensive > tasks. > Now, the underlying InputStream implementation used in transfer will return > calls to read(buffer, offset, length) as soon as *some* data is available. > That is, fireTransferProgress may well be invoked with an average number of > bytes less than half the buffer capacity (this varies with the underlying > network and hardware architecture). Consequently, fireTransferProgress is > invoked *millions of times* for large files. As this is a blocking operation, > the time spent in fireTransferProgress dominates and drastically slows down > the transfers by at least one order of magnitude. > !wagon-issue.png! > In our case, we found download speed reduced from a theoretical optimum of > ~80 seconds to to more than 3200 seconds. > From an architectural perspective, I would not want to make the consumers / > listeners invoked via fireTransferProgress aware of their potential impact on > download speed, but rather refactor the transfer method such that it uses a > buffer strategy reducing the the number of fireTransferProgress invocations. > This should be done with regard to the expected file size of the transfer, > such that fireTransferProgress is invoked often enough but not to frequent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1637) java.lang.NoSuchMethodError: org.junit.platform.commons.util.ReflectionUtils.tryToLoadClass Migrating to 5.4.0
[
https://issues.apache.org/jira/browse/SUREFIRE-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16766216#comment-16766216
]
Ahmed Yarub Hani Al Nuaimi commented on SUREFIRE-1637:
--
Fixed by replacing:
org.junit.jupiter
junit-jupiter-api
${junit.jupiter.version}
test
org.junit.jupiter
junit-jupiter-params
${junit.jupiter.version}
test
org.junit.jupiter
junit-jupiter-engine
${junit.jupiter.version}
test
org.junit.platform
junit-platform-launcher
1.4.0
test
with:
org.junit.jupiter
junit-jupiter
${junit.jupiter.version}
test
> java.lang.NoSuchMethodError:
> org.junit.platform.commons.util.ReflectionUtils.tryToLoadClass Migrating to
> 5.4.0
> --
>
> Key: SUREFIRE-1637
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1637
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M3
> Environment: Windows 10
>Reporter: Ahmed Yarub Hani Al Nuaimi
>Priority: Major
>
> JDK: 11
> Spring Boot: 2.1.2.RELEASE
> JUnit: 5.4.0
> Maven: 3.6.0
> Surefire: 3.0.0-M3
> At first, I got the following error running the tests on IntelliJ and using
> the command mvn clean install:
> ```
> [INFO] --- maven-surefire-plugin:3.0.0-M3:test (default-test) @ x ---
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> Feb 12, 2019 12:53:00 PM org.junit.platform.launcher.core.DefaultLauncher
> handleThrowable
> WARNING: TestEngine with ID 'junit-jupiter' failed to execute tests
> java.lang.NoSuchMethodError:
> org.junit.platform.commons.util.ReflectionUtils.tryToLoadClass(Ljava/lang/String;)Lorg/junit/platform/commons/function/Try;
> at
> org.junit.jupiter.engine.support.OpenTest4JAndJUnit4AwareThrowableCollector.createAbortedExecutionPredicate(OpenTest4JAndJUnit4AwareThrowableCollecto
> ```
> After adding this dependency, I could run the tests in IntelliJ but not using
> Maven:
> ```
>
> org.junit.platform
> junit-platform-launcher
> 1.4.0
> test
>
> ```
> Rolling back to version 5.3.2 solves the problem
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SUREFIRE-1637) java.lang.NoSuchMethodError: org.junit.platform.commons.util.ReflectionUtils.tryToLoadClass Migrating to 5.4.0
Ahmed Yarub Hani Al Nuaimi created SUREFIRE-1637: Summary: java.lang.NoSuchMethodError: org.junit.platform.commons.util.ReflectionUtils.tryToLoadClass Migrating to 5.4.0 Key: SUREFIRE-1637 URL: https://issues.apache.org/jira/browse/SUREFIRE-1637 Project: Maven Surefire Issue Type: Bug Components: JUnit 5.x support Affects Versions: 3.0.0-M3 Environment: Windows 10 Reporter: Ahmed Yarub Hani Al Nuaimi JDK: 11 Spring Boot: 2.1.2.RELEASE JUnit: 5.4.0 Maven: 3.6.0 Surefire: 3.0.0-M3 At first, I got the following error running the tests on IntelliJ and using the command mvn clean install: ``` [INFO] --- maven-surefire-plugin:3.0.0-M3:test (default-test) @ x --- [INFO] [INFO] --- [INFO] T E S T S [INFO] --- Feb 12, 2019 12:53:00 PM org.junit.platform.launcher.core.DefaultLauncher handleThrowable WARNING: TestEngine with ID 'junit-jupiter' failed to execute tests java.lang.NoSuchMethodError: org.junit.platform.commons.util.ReflectionUtils.tryToLoadClass(Ljava/lang/String;)Lorg/junit/platform/commons/function/Try; at org.junit.jupiter.engine.support.OpenTest4JAndJUnit4AwareThrowableCollector.createAbortedExecutionPredicate(OpenTest4JAndJUnit4AwareThrowableCollecto ``` After adding this dependency, I could run the tests in IntelliJ but not using Maven: ``` org.junit.platform junit-platform-launcher 1.4.0 test ``` Rolling back to version 5.3.2 solves the problem -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[
https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765910#comment-16765910
]
Dennis Lundberg edited comment on MRESOURCES-171 at 2/12/19 1:35 PM:
-
Hi,
We stumbled across this issue today for one of our projects that has
{{project.build.sourceEncoding=UTF-8}} and includes properties files that use
ISO-8859-1 encoding. The properties files are filtered. We have both regular
properties files and properties files that are used as ResourceBundles. There
are also non-properties files in the resources directory that needs to be
filtered.
Here is a proposal on how such a situation can be handled.
{code:xml}
org.apache.maven.plugins
maven-resources-plugin
default-resources
resources
UTF-8
src/main/resources
true
**/*.properties
resources-properties
resources
ISO-8859-1
src/main/resources
true
**/*.properties
{code}
was (Author: denn...@apache.org):
Hi,
We stumbled across this issue today for one of our projects that has
{{project.build.sourceEncoding=UTF-8}} and includes properties files that use
ISO-8859-1 encoding. The properties files are filtered. We have both regular
properties files and properties files that are used as ResourceBundles. There
are also non-properties files in the resources directory that needs to be
filtered.
Here is a proposal on how such a situation can be handled.
{code:xml}
org.apache.maven.plugins
maven-resources-plugin
resources-non-properties
resources
UTF-8
src/main/resources
true
**/*.properties
resources-properties
resources
ISO-8859-1
src/main/resources
true
**/*.properties
{code}
> ISO8859-1 properties files get changed into UTF-8 when filtered
> ---
>
> Key: MRESOURCES-171
> URL: https://issues.apache.org/jira/browse/MRESOURCES-171
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: filtering
>Reporter: Alex Collins
>Priority: Minor
> Attachments: filtering-bug.zip
>
>
> Create:
> src/main/resources/test.properties
> And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u
> formatting.
> When adding this line:
> src/main/resourcestrue
> Expected:
> ISO8859-1 encoded file in jar.
> Actual:
> UTF-8 encoded file in jar.
> ---
> If there are any property files (which can only be ISO8859-1) they appear to
> be converted into UTF-8 in the jar.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6588) Naming conventions should be more technical
Elliotte Rusty Harold created MNG-6588: -- Summary: Naming conventions should be more technical Key: MNG-6588 URL: https://issues.apache.org/jira/browse/MNG-6588 Project: Maven Issue Type: Improvement Components: Documentation: General Affects Versions: 3.6.0 Reporter: Elliotte Rusty Harold We should give a precise grammar for group IDs, artifact IDs and versions on https://maven.apache.org/guides/mini/guide-naming-conventions.html rather than fuzzy language like "you can choose whatever name you want with lowercase letters and no strange symbols" This can probably be done by reference to the Java naming rules rather than spelling it out. The version section should mention semantic versioning and Snapshots. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (WAGON-537) Maven transfer speed of large artifacts is slow due to unsuitable buffer strategy
[ https://issues.apache.org/jira/browse/WAGON-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765965#comment-16765965 ] Olaf Otto commented on WAGON-537: - [~michael-o] It is the exact same situation with uploading artifacts, i.e. this change - at least on Windows / linux via Docker for windows leads to a full utilization of the network capacity. > Maven transfer speed of large artifacts is slow due to unsuitable buffer > strategy > - > > Key: WAGON-537 > URL: https://issues.apache.org/jira/browse/WAGON-537 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-provider-api >Affects Versions: 3.2.0 > Environment: Windows 10, JDK 1.8, Nexus Artifact store > 100MB/s > network connection. >Reporter: Olaf Otto >Assignee: Michael Osipov >Priority: Major > Labels: perfomance > Fix For: 3.3.0, 3.3.1 > > Attachments: wagon-issue.png > > > We are using maven for build process automation with docker. This sometimes > involves uploading and downloading artifacts with a few gigabytes in size. > Here, maven's transfer speed is consistently and reproducibly slow. For > instance, an artifact with 7,5 GB in size took almost two hours to transfer > in spite of a 100 MB/s connection with respective reproducible download speed > from the remote nexus artifact repository when using a browser to download. > The same is true when uploding such an artifact. > I have investigated the issue using JProfiler. The result shows an issue in > AbstractWagon's transfer( Resource resource, InputStream input, OutputStream > output, int requestType, long maxSize ) method used for remote artifacts and > the same issue in AbstractHttpClientWagon#writeTo(OutputStream). > Here, the input stream is read in a loop using a 4 Kb buffer. Whenever data > is received, the received data is pushed to downstream listeners via > fireTransferProgress. These listeners (or rather consumers) perform expensive > tasks. > Now, the underlying InputStream implementation used in transfer will return > calls to read(buffer, offset, length) as soon as *some* data is available. > That is, fireTransferProgress may well be invoked with an average number of > bytes less than half the buffer capacity (this varies with the underlying > network and hardware architecture). Consequently, fireTransferProgress is > invoked *millions of times* for large files. As this is a blocking operation, > the time spent in fireTransferProgress dominates and drastically slows down > the transfers by at least one order of magnitude. > !wagon-issue.png! > In our case, we found download speed reduced from a theoretical optimum of > ~80 seconds to to more than 3200 seconds. > From an architectural perspective, I would not want to make the consumers / > listeners invoked via fireTransferProgress aware of their potential impact on > download speed, but rather refactor the transfer method such that it uses a > buffer strategy reducing the the number of fireTransferProgress invocations. > This should be done with regard to the expected file size of the transfer, > such that fireTransferProgress is invoked often enough but not to frequent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[
https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765910#comment-16765910
]
Dennis Lundberg commented on MRESOURCES-171:
Hi,
We stumbled across this issue today for one of our projects that has
{{project.build.sourceEncoding=UTF-8}} and includes properties files that use
ISO-8859-1 encoding. The properties files are filtered. We have both regular
properties files and properties files that are used as ResourceBundles. There
are also non-properties files in the resources directory that needs to be
filtered.
Here is a proposal on how such a situation can be handled.
{code:xml}
org.apache.maven.plugins
maven-resources-plugin
resources-non-properties
resources
UTF-8
src/main/resources
true
**/*.properties
resources-properties
resources
ISO-8859-1
src/main/resources
true
**/*.properties
{code}
> ISO8859-1 properties files get changed into UTF-8 when filtered
> ---
>
> Key: MRESOURCES-171
> URL: https://issues.apache.org/jira/browse/MRESOURCES-171
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: filtering
>Reporter: Alex Collins
>Priority: Minor
> Attachments: filtering-bug.zip
>
>
> Create:
> src/main/resources/test.properties
> And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u
> formatting.
> When adding this line:
> src/main/resourcestrue
> Expected:
> ISO8859-1 encoded file in jar.
> Actual:
> UTF-8 encoded file in jar.
> ---
> If there are any property files (which can only be ISO8859-1) they appear to
> be converted into UTF-8 in the jar.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MPH-160) add source location in comments to effective pom.xml
[ https://issues.apache.org/jira/browse/MPH-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MPH-160: -- Description: during in-memory effective pom building (by maven-model-builder), the source location of content is kept in memory: see [Modello documentation on location tracking|https://codehaus-plexus.github.io/modello/location-tracking.html] and MNG-1803 for its integration into Maven model adding this information as comment on every line of generated XML would ease tracking for end users (and not only m2e users, who get "Jump to location" hint when editing their pom.xml in Eclipse...) This will probably require a Modello enhancement then integration (idea found during Devoxx 2018 Maven BoF, since users were missing ways to diagnose unexpected result in effective pom) was: during in-memory effective pom building (by maven-model-builder), the source location of content is kept in memory: see [Modello documentation on location tracking|https://codehaus-plexus.github.io/modello/location-tracking.html] adding this information as comment on every line of generated XML would ease tracking for end users This will probably require a Modello enhancement then integration (idea found during Devoxx 2018 Maven BoF, since users were missing ways to diagnose unexpected result in effective pom) > add source location in comments to effective pom.xml > > > Key: MPH-160 > URL: https://issues.apache.org/jira/browse/MPH-160 > Project: Maven Help Plugin > Issue Type: New Feature > Components: effective-pom >Affects Versions: 3.1.0 >Reporter: Hervé Boutemy >Priority: Major > > during in-memory effective pom building (by maven-model-builder), the source > location of content is kept in memory: see [Modello documentation on location > tracking|https://codehaus-plexus.github.io/modello/location-tracking.html] > and MNG-1803 for its integration into Maven model > adding this information as comment on every line of generated XML would ease > tracking for end users (and not only m2e users, who get "Jump to location" > hint when editing their pom.xml in Eclipse...) > This will probably require a Modello enhancement then integration > (idea found during Devoxx 2018 Maven BoF, since users were missing ways to > diagnose unexpected result in effective pom) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
