[jira] (SUREFIRE-1147) Unbounded memory usage when running MANY tests
[ https://jira.codehaus.org/browse/SUREFIRE-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365113#comment-365113 ] Laurent Claisse commented on SUREFIRE-1147: --- I tried with both, doesn't change a thing. Not surprising because this issue is likely not due to a superficial regression, but to the way the pipeline was designed (guessing): store everything in memory in case it's needed, instead of streaming the output. Unbounded memory usage when running MANY tests -- Key: SUREFIRE-1147 URL: https://jira.codehaus.org/browse/SUREFIRE-1147 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.18.1 Environment: win7, jdk 8u25, mvn 3.2.5 Reporter: Laurent Claisse Attachments: surefire-allocation-traces.png, surefire-leak2.png, surefire-leak3.png, surefire-leak.png I'm writing concurrency tests, checking that this thing is reproducible, that other thing isn't, and so on. So i repeat tests MANY times like 100_000 (to reproduce the leak, the test project is here: https://github.com/vandekeiser/parallel-stream-fork-join-pool) I see in VisualVM that the culprit is WrappedReportEntry, which indirectly holds references to lots of byte[] and char[] (allocation traces and heap dump pics are included in attachment) I forked and patched maven-surefire-common, and that makes the leak go. I had to replace WrappedReportEntry.original by a singleton fake ReportEntry. Bebefore that i had replaced Utf8RecodingDeferredFileOutputStream.deferredFileOutputStream by a NullOutputStream and the leak was lesser but still here. My fork of maven-surefire-common is there: https://github.com/vandekeiser/maven-surefire/tree/master/maven-surefire-common. It IS a patch so i checked the patch checkbox in the issue reporter, but it is NOT intended to be distributed of course since it is very brutal and basic. Also in my test project i explicitly deactivated reporting, but that doesn't make the reporting leak go away at all: disableXmlReporttrue/disableXmlReport printSummaryfalse/printSummary -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-424) Compile errors and warning when generating the test-javadoc
[
https://jira.codehaus.org/browse/MJAVADOC-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365117#comment-365117
]
Jim Sellers commented on MJAVADOC-424:
--
I'll try to test 2.10.3-SNAPSHOT tomorrow.
Compile errors and warning when generating the test-javadoc
---
Key: MJAVADOC-424
URL: https://jira.codehaus.org/browse/MJAVADOC-424
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10.1
Reporter: Jim Sellers
With the changes to the classpath done in MJAVADOC-398 and MJAVADOC-406, this
means now I get javadoc warnings and errors when creating a site. The errors
fail the build.
This showed up because code in src/test/java used constants defined in
src/main/java.
Work around was to revert to 2.9.1
{code:XML|title=Sample pom snipit}
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
!-- version2.9.1/version --
version2.10.1/version
configuration
detectLinksfalse/detectLinks
detectOfflineLinkstrue/detectOfflineLinks
/configuration
/plugin
/plugins
/pluginManagement
/build
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
configuration
detectLinksfalse/detectLinks
detectOfflineLinkstrue/detectOfflineLinks
/configuration
reportSets
reportSet
iddefault/id
reports
reportjavadoc/report
reporttest-javadoc/report
/reports
/reportSet
/reportSets
/plugin
/plugins
/reporting
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEP-436) German umlauts in outputDirectory and destFileName getting garbled
[ https://jira.codehaus.org/browse/MDEP-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365082#comment-365082 ] Markus KARG commented on MDEP-436: -- According to Kristian Rosenvold this issue is NOT fixed and CP850 won't work (only UTF-8 will). So I'd like to kindly ask to reopen and fix this issue, which is really important to Windows users, as Windows can only display ZIPs encoded as CP850. :-) German umlauts in outputDirectory and destFileName getting garbled -- Key: MDEP-436 URL: https://jira.codehaus.org/browse/MDEP-436 Project: Maven Dependency Plugin Issue Type: Bug Components: copy Affects Versions: 2.8 Environment: Win7 Pro SP1 64 Bit, JRE 7, MVN 3.0.4 Reporter: Markus KARG Assignee: Kristian Rosenvold Priority: Critical Fix For: 2.10 I am using German umlauts like Ã, à and à in my POM when configuring the outputDirectory and destFileName properties of the copy goal. When the plugin does the actual copy, the directory and file do not contain that umlauts, but instead a strange symbol (encoding garbage). It seems the plugin is unable to deal with German umlauts. While Java definitively IS able to correctly handle it, and while the POM is encoded in UTF-8, it is definitively a bug of a Maven component. As I do not know which component fails here, I am reporting it at the failing plugin, as it is the entry-point for me. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MWAR-303) filtering of ${project.developers[0].id} does not work
[
https://jira.codehaus.org/browse/MWAR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabriel Belingueres updated MWAR-303:
-
Environment: tested with maven 3.0.5, 3.1.0, 3.2.1 Win XP and 7, Java
7. (was: maven 3.0.5 and 3.1.0, Win XP and 7, Java 7.)
Affects Version/s: 2.5
2.6
filtering of ${project.developers[0].id} does not work
--
Key: MWAR-303
URL: https://jira.codehaus.org/browse/MWAR-303
Project: Maven WAR Plugin
Issue Type: Bug
Components: filtering
Affects Versions: 2.4, 2.5, 2.6
Environment: tested with maven 3.0.5, 3.1.0, 3.2.1 Win XP and 7, Java
7.
Reporter: Gabriel Belingueres
Attachments: modified-integ-test.patch
An expression like ${project.developers[0].id} is not filtered in version
2.4.
It works fine in maven war plugin version 2.3.
I attached a patch file with a modified integration test.
Regards,
Gabriel
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-424) Compile errors and warning when generating the test-javadoc
[
https://jira.codehaus.org/browse/MJAVADOC-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365079#comment-365079
]
Michal Srb commented on MJAVADOC-424:
-
I believe that this is a same issue as in MJAVADOC-414.
Compile errors and warning when generating the test-javadoc
---
Key: MJAVADOC-424
URL: https://jira.codehaus.org/browse/MJAVADOC-424
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10.1
Reporter: Jim Sellers
With the changes to the classpath done in MJAVADOC-398 and MJAVADOC-406, this
means now I get javadoc warnings and errors when creating a site. The errors
fail the build.
This showed up because code in src/test/java used constants defined in
src/main/java.
Work around was to revert to 2.9.1
{code:XML|title=Sample pom snipit}
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
!-- version2.9.1/version --
version2.10.1/version
configuration
detectLinksfalse/detectLinks
detectOfflineLinkstrue/detectOfflineLinks
/configuration
/plugin
/plugins
/pluginManagement
/build
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
configuration
detectLinksfalse/detectLinks
detectOfflineLinkstrue/detectOfflineLinks
/configuration
reportSets
reportSet
iddefault/id
reports
reportjavadoc/report
reporttest-javadoc/report
/reports
/reportSet
/reportSets
/plugin
/plugins
/reporting
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (ARCHETYPE-478) cannot run archetype:create-from-project when dependency on maven-ear-plugin
Bernard LUPIN created ARCHETYPE-478: --- Summary: cannot run archetype:create-from-project when dependency on maven-ear-plugin Key: ARCHETYPE-478 URL: https://jira.codehaus.org/browse/ARCHETYPE-478 Project: Maven Archetype Issue Type: Bug Affects Versions: 2.3 Environment: Windows 7, Maven 3.0.5 Reporter: Bernard LUPIN Attachments: myproj.zip I'm migrating maven-archetype-plugin from 2.2 to 2.3. I cannot create an archetype if my project has a dependency on maven-ear-plugin. Using attached pom.xml and running mvn archetype:create-from-project gives me following error : [ERROR] Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:2.3:create-from-project (default-cli) on project myproj: null: MojoFailureException - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:2.3:create-from-project (default-cli) on project myproj: null at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.MojoFailureException at org.apache.maven.archetype.mojos.CreateArchetypeFromProjectMojo.execute(CreateArchetypeFromProjectMojo.java:258) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) I tried several versions of maven-ear-plugin, adding configuration or not, I always get this obscure error. Everything works well with previous archetype plugin version 2.2. And everything works well with archetype plugin version 2.3 without maven-ear-plugin. Regards, Bernard -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEP-436) German umlauts in outputDirectory and destFileName getting garbled
[ https://jira.codehaus.org/browse/MDEP-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365064#comment-365064 ] Markus KARG commented on MDEP-436: -- Can you please append a comment showing how to configure maven-dependency-plugin:unpack in a way that will preserve German umlauts of file names when the ZIP was created with encodingCP850/encoding? With the default configuration maven-dependency-plugin:unpack actually unpacks garbage! .-( German umlauts in outputDirectory and destFileName getting garbled -- Key: MDEP-436 URL: https://jira.codehaus.org/browse/MDEP-436 Project: Maven Dependency Plugin Issue Type: Bug Components: copy Affects Versions: 2.8 Environment: Win7 Pro SP1 64 Bit, JRE 7, MVN 3.0.4 Reporter: Markus KARG Assignee: Kristian Rosenvold Priority: Critical Fix For: 2.10 I am using German umlauts like Ã, à and à in my POM when configuring the outputDirectory and destFileName properties of the copy goal. When the plugin does the actual copy, the directory and file do not contain that umlauts, but instead a strange symbol (encoding garbage). It seems the plugin is unable to deal with German umlauts. While Java definitively IS able to correctly handle it, and while the POM is encoded in UTF-8, it is definitively a bug of a Maven component. As I do not know which component fails here, I am reporting it at the failing plugin, as it is the entry-point for me. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (ARCHETYPE-478) cannot run archetype:create-from-project when dependency on maven-ear-plugin
[ https://jira.codehaus.org/browse/ARCHETYPE-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365088#comment-365088 ] Bernard LUPIN commented on ARCHETYPE-478: - Also tried with Maven 3.2.5 / JDK 7.0.75, same result. cannot run archetype:create-from-project when dependency on maven-ear-plugin Key: ARCHETYPE-478 URL: https://jira.codehaus.org/browse/ARCHETYPE-478 Project: Maven Archetype Issue Type: Bug Affects Versions: 2.3 Environment: Windows 7, Maven 3.0.5 Reporter: Bernard LUPIN Attachments: myproj.zip I'm migrating maven-archetype-plugin from 2.2 to 2.3. I cannot create an archetype if my project has a dependency on maven-ear-plugin. Using attached pom.xml and running mvn archetype:create-from-project gives me following error : [ERROR] Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:2.3:create-from-project (default-cli) on project myproj: null: MojoFailureException - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:2.3:create-from-project (default-cli) on project myproj: null at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.MojoFailureException at org.apache.maven.archetype.mojos.CreateArchetypeFromProjectMojo.execute(CreateArchetypeFromProjectMojo.java:258) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) I tried several versions of maven-ear-plugin, adding configuration or not, I always get this obscure error. Everything works well with previous archetype plugin version 2.2. And everything works well with archetype plugin version 2.3 without maven-ear-plugin. Regards, Bernard -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-302) Allow usage of supplemental-model in reports (e.g. dependencies)
[ https://jira.codehaus.org/browse/MPIR-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grégory Joseph updated MPIR-302: Attachment: BUILD-185-MPIR-302.zip (updated sample to use pir 2.8, where the problem still exists) Allow usage of supplemental-model in reports (e.g. dependencies) Key: MPIR-302 URL: https://jira.codehaus.org/browse/MPIR-302 Project: Maven Project Info Reports Plugin Issue Type: Improvement Components: dependencies, dependency-management Affects Versions: 2.7 Reporter: Grégory Joseph Attachments: BUILD-185-MPIR-302.zip The remote-resources plugin allows creating and sharing supplemental models, i.e pom snippets that allow overriding (read fixing) those from the repository. We use this to fix licensing info of some libraries that are on central with wrong or inaccurate poms. See http://maven.apache.org/plugins/maven-remote-resources-plugin/supplemental-models.html It would be great if the dependencies reports (and others maybe ?) could make use of the same information, such that those generated reports are consistent with the resources generated by remote-resources plugin. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-302) Allow usage of supplemental-model in reports (e.g. dependencies)
[
https://jira.codehaus.org/browse/MPIR-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grégory Joseph updated MPIR-302:
Attachment: BUILD-185-MPIR-302.zip
Sorry this took a while, but here's an example.
If you run {{mvn clean install site:site}}, you'll see that
{{sample/target/classes/README.txt}} contains corrected license information
about ASM; this comes from the supplemental-model file.
You'll also see that {{sample/target/site/dependencies.html}} does not.
(asm:asm:3.1 has no license info in its pom)
Allow usage of supplemental-model in reports (e.g. dependencies)
Key: MPIR-302
URL: https://jira.codehaus.org/browse/MPIR-302
Project: Maven Project Info Reports Plugin
Issue Type: Improvement
Components: dependencies, dependency-management
Affects Versions: 2.7
Reporter: Grégory Joseph
Attachments: BUILD-185-MPIR-302.zip
The remote-resources plugin allows creating and sharing supplemental
models, i.e pom snippets that allow overriding (read fixing) those from
the repository. We use this to fix licensing info of some libraries that are
on central with wrong or inaccurate poms.
See
http://maven.apache.org/plugins/maven-remote-resources-plugin/supplemental-models.html
It would be great if the dependencies reports (and others maybe ?) could make
use of the same information, such that those generated reports are consistent
with the resources generated by remote-resources plugin.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-302) Allow usage of supplemental-model in reports (e.g. dependencies)
[ https://jira.codehaus.org/browse/MPIR-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grégory Joseph updated MPIR-302: Attachment: (was: BUILD-185-MPIR-302.zip) Allow usage of supplemental-model in reports (e.g. dependencies) Key: MPIR-302 URL: https://jira.codehaus.org/browse/MPIR-302 Project: Maven Project Info Reports Plugin Issue Type: Improvement Components: dependencies, dependency-management Affects Versions: 2.7 Reporter: Grégory Joseph The remote-resources plugin allows creating and sharing supplemental models, i.e pom snippets that allow overriding (read fixing) those from the repository. We use this to fix licensing info of some libraries that are on central with wrong or inaccurate poms. See http://maven.apache.org/plugins/maven-remote-resources-plugin/supplemental-models.html It would be great if the dependencies reports (and others maybe ?) could make use of the same information, such that those generated reports are consistent with the resources generated by remote-resources plugin. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRRESOURCES-94) Performance issue in ProcessRemoteResourcesMojo.configureVelocityContext(...)
Falko Modler created MRRESOURCES-94:
---
Summary: Performance issue in
ProcessRemoteResourcesMojo.configureVelocityContext(...)
Key: MRRESOURCES-94
URL: https://jira.codehaus.org/browse/MRRESOURCES-94
Project: Maven Remote Resources Plugin
Issue Type: Bug
Affects Versions: 1.5
Reporter: Falko Modler
I was wondering why our multi-threaded maven build of 80+ modules took so long
even when excluding tests. I checked every plugin execution and to my surprise,
{{maven-remote-resources-plugin}} was the number 1 consumer *before*
compiler-plugin etc.
We use {{maven-remote-resources-plugin}} just to exchange some few xml files
among the modules, nothing spectacular!
While debugging the plugin I found out that
{{ProcessRemoteResourcesMojo.configureVelocityContext(VelocityContext
context)}} may take *up to 30 seconds* for our project setup which is not
acceptable.
Almost certainly the problem is caused by the following project lookups
(especially {{getProjects()}}):
{noformat}
ListMavenProject projects = getProjects();
context.put( projects, projects );
context.put( projectsSortedByOrganization,
getProjectsSortedByOrganization( projects ) );
{noformat}
As we do not use velocity templates at all, the solution for us was to patch
the plugin to call {{configureVelocityContext(...)}} only on demand, not
eagerly. Of course this won't help when using velocity templates...
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1147) Unbounded memory usage when running MANY tests
[ https://jira.codehaus.org/browse/SUREFIRE-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365113#comment-365113 ] Laurent Claisse edited comment on SUREFIRE-1147 at 3/16/15 3:50 PM: I tried with both, doesn't change a thing. Not surprising because this issue is likely not due to a superficial regression, but to the way the pipeline was designed (guessing): store everything in memory in case it's needed, instead of streaming the output. This probably requires a refactor to fix. was (Author: chtimi59): I tried with both, doesn't change a thing. Not surprising because this issue is likely not due to a superficial regression, but to the way the pipeline was designed (guessing): store everything in memory in case it's needed, instead of streaming the output. Unbounded memory usage when running MANY tests -- Key: SUREFIRE-1147 URL: https://jira.codehaus.org/browse/SUREFIRE-1147 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.18.1 Environment: win7, jdk 8u25, mvn 3.2.5 Reporter: Laurent Claisse Attachments: surefire-allocation-traces.png, surefire-leak2.png, surefire-leak3.png, surefire-leak.png I'm writing concurrency tests, checking that this thing is reproducible, that other thing isn't, and so on. So i repeat tests MANY times like 100_000 (to reproduce the leak, the test project is here: https://github.com/vandekeiser/parallel-stream-fork-join-pool) I see in VisualVM that the culprit is WrappedReportEntry, which indirectly holds references to lots of byte[] and char[] (allocation traces and heap dump pics are included in attachment) I forked and patched maven-surefire-common, and that makes the leak go. I had to replace WrappedReportEntry.original by a singleton fake ReportEntry. Bebefore that i had replaced Utf8RecodingDeferredFileOutputStream.deferredFileOutputStream by a NullOutputStream and the leak was lesser but still here. My fork of maven-surefire-common is there: https://github.com/vandekeiser/maven-surefire/tree/master/maven-surefire-common. It IS a patch so i checked the patch checkbox in the issue reporter, but it is NOT intended to be distributed of course since it is very brutal and basic. Also in my test project i explicitly deactivated reporting, but that doesn't make the reporting leak go away at all: disableXmlReporttrue/disableXmlReport printSummaryfalse/printSummary -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-741) Links to subsections are not unique
Aleksey Nesterenko created MSITE-741: - Summary: Links to subsections are not unique Key: MSITE-741 URL: https://jira.codehaus.org/browse/MSITE-741 Project: Maven Site Plugin Issue Type: Bug Affects Versions: 3.4 Reporter: Aleksey Nesterenko Maven site does not have possibility to refer subsections, e.g.: http://alexkravin.github.io/anchors/config_annotation.html#AnnotationUseStyle This is link to section But I can't put reference to subsection, e.g.: http://alexkravin.github.io/anchors/config_annotation.html#Description This refers to only first occurrence, I expect functionality like: http://alexkravin.github.io/anchors/config_annotation.html#AnnotationUseStyle#Description http://alexkravin.github.io/anchors/config_annotation.html#MissingDeprecated#Description etc.. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINVOKER-184) Implement IT in an other way.
[
https://jira.codehaus.org/browse/MINVOKER-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MINVOKER-184:
-
Fix Version/s: 1.9.1
Implement IT in an other way.
-
Key: MINVOKER-184
URL: https://jira.codehaus.org/browse/MINVOKER-184
Project: Maven Invoker Plugin
Issue Type: Improvement
Affects Versions: 1.9.1
Reporter: Karl-Heinz Marbaise
Fix For: 1.9.1
{quote}
IIRC subversion has some issues with special characters.
Together with Olivier we came to the conclusion that it is better to create
these kind of files and folders during setup of the IT.
So if someone hits such an issue you know how to fix it.
Robert
Op Sat, 14 Mar 2015 19:39:43 +0100 schreef khmarba...@apache.org:
Author: khmarbaise
Date: Sat Mar 14 18:39:43 2015
New Revision: 1666722
URL: http://svn.apache.org/r1666722
Log:
[MINVOKER-183] IT failing when path contains accents
Added an IT with accents etc. in path name.
{quote}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-424) Compile errors and warning when generating the test-javadoc
[
https://jira.codehaus.org/browse/MJAVADOC-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365116#comment-365116
]
Karl-Heinz Marbaise commented on MJAVADOC-424:
--
Can someone check this by using the current SNAPSHOT on trunk to check if this
true if so we can close the issue.
Compile errors and warning when generating the test-javadoc
---
Key: MJAVADOC-424
URL: https://jira.codehaus.org/browse/MJAVADOC-424
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10.1
Reporter: Jim Sellers
With the changes to the classpath done in MJAVADOC-398 and MJAVADOC-406, this
means now I get javadoc warnings and errors when creating a site. The errors
fail the build.
This showed up because code in src/test/java used constants defined in
src/main/java.
Work around was to revert to 2.9.1
{code:XML|title=Sample pom snipit}
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
!-- version2.9.1/version --
version2.10.1/version
configuration
detectLinksfalse/detectLinks
detectOfflineLinkstrue/detectOfflineLinks
/configuration
/plugin
/plugins
/pluginManagement
/build
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
configuration
detectLinksfalse/detectLinks
detectOfflineLinkstrue/detectOfflineLinks
/configuration
reportSets
reportSet
iddefault/id
reports
reportjavadoc/report
reporttest-javadoc/report
/reports
/reportSet
/reportSets
/plugin
/plugins
/reporting
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINVOKER-184) Implement IT in an other way.
Karl-Heinz Marbaise created MINVOKER-184:
Summary: Implement IT in an other way.
Key: MINVOKER-184
URL: https://jira.codehaus.org/browse/MINVOKER-184
Project: Maven Invoker Plugin
Issue Type: Improvement
Affects Versions: 1.9.1
Reporter: Karl-Heinz Marbaise
{quote}
IIRC subversion has some issues with special characters.
Together with Olivier we came to the conclusion that it is better to create
these kind of files and folders during setup of the IT.
So if someone hits such an issue you know how to fix it.
Robert
Op Sat, 14 Mar 2015 19:39:43 +0100 schreef khmarba...@apache.org:
Author: khmarbaise
Date: Sat Mar 14 18:39:43 2015
New Revision: 1666722
URL: http://svn.apache.org/r1666722
Log:
[MINVOKER-183] IT failing when path contains accents
Added an IT with accents etc. in path name.
{quote}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MWAR-215) class file JAR inconsistency (archiveClasses and attachClasses options)
[
https://jira.codehaus.org/browse/MWAR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neeme Praks reopened MWAR-215:
--
Sorry, I missed some of the comments above. Caught up now.
What was the verdict, did we reach a decision?
Backwards compatible by default or no?
Configuration option name(s)?
class file JAR inconsistency (archiveClasses and attachClasses options)
---
Key: MWAR-215
URL: https://jira.codehaus.org/browse/MWAR-215
Project: Maven WAR Plugin
Issue Type: Improvement
Affects Versions: 2.1-beta-1
Reporter: Neeme Praks
Attachments: maven-WAR-plugin-classes.patch
Copy-paste from
http://article.gmane.org/gmane.comp.jakarta.turbine.maven.devel/94789
{quote}
I have a couple of issues with the current WAR plugin and the way it
packages class files in JAR files (archiveClasses and attachClasses
configuration options), as these two options work independently of each
other:
* archiveClasses moves all class files (and related resources) from
classes directory to JAR file inside WEB-INF/lib directory
* attachClasses creates a new JAR file in target directory from same
set of files and attaches it to the Maven project with some qualifier
(by default it uses classes qualifier)
When we deploy artifacts to Maven repository, this results in two
different JAR files being deployed: one inside WAR and the other
separate from WAR.
Problems with this approach:
* two different JAR files with different MD5/SHA1 checksums.
* the naming convention for these two JAR files is different
These issues really start to snag you when you need to perform updates
after the initial deploy of the WAR. Consider the following scenario:
* development team hands WAR artifact over to deployment team for deployment
* development team needs to give an update to the webapp code (the
dependencies have not changed). One approach is to give the whole WAR
again, but a more reasonable approach would be to give only JAR file, as
it contains all the changes and dependent JARs have not changed.
Whole-WAR-approach becomes especially problematic, when the update needs
to be uploaded over slow network links and you are in a hurry. However,
giving only JAR file presents us with some problems:
# there is no easy way to check the currently deployed webapp JAR
version, as the checksum of the embedded JAR file does not match any
other JAR file in the Maven repository.
# as the naming convention differs, it is going to confuse the
deployment team
Solution to this mess? Unify the way archiveClasses and
attachClasses functionalities work, so they would operate on the same
JAR file. The way this would work:
* if archiveClasses option is specified, it moves all class files to
JAR file inside WEB-INF/lib directory (same as before). It would use the
same naming convention as regular Maven JAR artifacts, with some qualifier.
* if attachClasses option is specified, it attaches that same JAR
file (as created in previous point) to the Maven project.
* if attachClasses is specified, but no archiveClasses - nothing
happens. Or maybe we should then implicitly turn on also the
archiveClasses option?
This has some implications for backwards compatibility:
* naming convention of the embedded JAR file is changed
* the attached JAR file is no longer created in the target
directory, next to the WAR file (it is now attached directly from
WEB-INF/lib directory)
{quote}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MWAR-340) packagingExcludes is ignored by war:exploded
[
https://jira.codehaus.org/browse/MWAR-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hendy Irawan updated MWAR-340:
--
Affects Version/s: 2.6
packagingExcludes is ignored by war:exploded
--
Key: MWAR-340
URL: https://jira.codehaus.org/browse/MWAR-340
Project: Maven WAR Plugin
Issue Type: Bug
Affects Versions: 2.5, 2.6
Reporter: Hendy Irawan
e.g.
{code}
packagingExcludesWEB-INF/classes/logback.xml/packagingExcludes
{code}
in the exploded directory, that/those file(s) is incorrectly still included.
However in the .war file, that file is properly excluded.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MWAR-340) packagingExcludes is ignored by war:exploded
[
https://jira.codehaus.org/browse/MWAR-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=365057#comment-365057
]
Hendy Irawan commented on MWAR-340:
---
Please take a look at this issue. Still happens on 2.6 :(
packagingExcludes is ignored by war:exploded
--
Key: MWAR-340
URL: https://jira.codehaus.org/browse/MWAR-340
Project: Maven WAR Plugin
Issue Type: Bug
Affects Versions: 2.5, 2.6
Reporter: Hendy Irawan
e.g.
{code}
packagingExcludesWEB-INF/classes/logback.xml/packagingExcludes
{code}
in the exploded directory, that/those file(s) is incorrectly still included.
However in the .war file, that file is properly excluded.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
