[jira] (MWAR-304) WAR plugin ignores attached artifacts from previous plugins
[
https://jira.codehaus.org/browse/MWAR-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=331133#comment-331133
]
Jörg Schaible commented on MWAR-304:
Attach means that the resulting artifact is an additional project result and
will be installed/deployed to the repository on its own. It is certainly not
meant to be included automatically into the main artifact. Such a behavior
would break quite a lot of existing projects.
If you want to add it to the war, simply set the proper target directory for
this attached artifact (into
${project.build.directory}/${project.build.finalName}/WEB-INF/lib).
> WAR plugin ignores attached artifacts from previous plugins
> ---
>
> Key: MWAR-304
> URL: https://jira.codehaus.org/browse/MWAR-304
> Project: Maven WAR Plugin
> Issue Type: Bug
> Components: overlay
>Affects Versions: 2.4
> Environment: any
>Reporter: Richard Sand
>
> If my maven project includes a plugin that attaches an artifact to the
> project, the war plugin will not process the artifact for inclusion in the
> results
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4838) Permament move (error 301) not handled properly by Maven
[ https://jira.codehaus.org/browse/MNG-4838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-4838. - Resolution: Duplicate Fix Version/s: (was: 3.x / Backlog) Assignee: Brett Porter Yes, fixed since Maven 3.0.4 - but due to MNG-5175 rather than WAGON-314. > Permament move (error 301) not handled properly by Maven > > > Key: MNG-4838 > URL: https://jira.codehaus.org/browse/MNG-4838 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.11, 2.2.1, 3.0-beta-3 >Reporter: Grzegorz Slowikowski >Assignee: Brett Porter >Priority: Minor > > Artifact cannot be downloaded by http-lightweight-wagon used (as default) in > all Maven versions except 2.2.0, which uses http-wagon by default. > Instead of pom and jar files html files appear in the local repo with content > like: > > > 301 Moved Permanently > > Moved Permanently > The document has moved href="http://download.java.net/maven/2/org/codehaus/castor/castor-xml-schema/1.2/castor-xml-schema-1.2.pom";>here. > > Apache Server at maven2-repository.dev.java.net Port 443 > > Only Maven 2.2.0 handles 301 properly. > By the way, I haven't expected such Apache configuration (permament move) in > central Maven repo. > As you can see this is not handled properly by almost all versions of Maven. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-169) Add support for EAR 7
[
https://jira.codehaus.org/browse/MEAR-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stéphane Nicoll updated MEAR-169:
-
Fix Version/s: 2.9
Assignee: Stéphane Nicoll
> Add support for EAR 7
> -
>
> Key: MEAR-169
> URL: https://jira.codehaus.org/browse/MEAR-169
> Project: Maven Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Fred Bricon
>Assignee: Stéphane Nicoll
> Fix For: 2.9
>
>
> maven-ear-plugin 2.8 doesn't support version=7 (build fails with Invalid
> version [7]). It's probably time to add it to the list of supported versions.
> According to the final draft of the Java EE 7 spec, section EE 8.6 :
> {quote}
> The deployment descriptor must be named META-INF/
> application.xml in the .ear file. Note that this name is case-sensitive. The
> XML
> Schema located at http://xmlns.jcp.org/xml/ns/javaee/application_7.xsd
> defines the XML grammar for a Java EE application deployment descriptor.
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-797) Parallel junit does not run in parallel when a Suite is used at the top level
[ https://jira.codehaus.org/browse/SUREFIRE-797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=331160#comment-331160 ] Tibor Digana commented on SUREFIRE-797: --- @Jonatan Jönsson The surefire 2.16 went out. Now if you specify methods and a suite is in or , the methods of classes included in the suite will run in parallel. You can nowadays use combinations of suites, classes, and methods to run them in parallel and configure thread resources. I am working on a next release which will calculate and optimize thread resources upon the total thread count, the amount of suites, classes and methods to gain the performance of your tests. > Parallel junit does not run in parallel when a Suite is used at the top level > - > > Key: SUREFIRE-797 > URL: https://jira.codehaus.org/browse/SUREFIRE-797 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.6, 2.7, 2.8, 2.9, 2.10 >Reporter: Kristian Rosenvold > Fix For: Backlog > > > Using the test project at > maven-surefire/surefire-integration-tests/src/test/resources/junit47-parallel-with-suite > one can see that the actual tests do not get run in parallel. This is due to > the project running a top-level suite. > I have researched this a little bit, and it seems like this does not even > work with regular JUnit (even without our special runners), so the problem > may be theirs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-797) Parallel junit does not run in parallel when a Suite is used at the top level
[ https://jira.codehaus.org/browse/SUREFIRE-797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=331160#comment-331160 ] Tibor Digana edited comment on SUREFIRE-797 at 8/20/13 6:11 AM: @Jonatan Jönsson The surefire 2.16 went out. Now if you specify methods and a suite is in or , only the methods of classes included in the suite will run in parallel. You can nowadays use combinations of suites, classes, and methods to run them in parallel and configure thread resources. I am working on a next release which will calculate and optimize thread resources upon the total thread count, the amount of suites, classes and methods to gain the performance of your tests. was (Author: tibor17): @Jonatan Jönsson The surefire 2.16 went out. Now if you specify methods and a suite is in or , the methods of classes included in the suite will run in parallel. You can nowadays use combinations of suites, classes, and methods to run them in parallel and configure thread resources. I am working on a next release which will calculate and optimize thread resources upon the total thread count, the amount of suites, classes and methods to gain the performance of your tests. > Parallel junit does not run in parallel when a Suite is used at the top level > - > > Key: SUREFIRE-797 > URL: https://jira.codehaus.org/browse/SUREFIRE-797 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.6, 2.7, 2.8, 2.9, 2.10 >Reporter: Kristian Rosenvold > Fix For: Backlog > > > Using the test project at > maven-surefire/surefire-integration-tests/src/test/resources/junit47-parallel-with-suite > one can see that the actual tests do not get run in parallel. This is due to > the project running a top-level suite. > I have researched this a little bit, and it seems like this does not even > work with regular JUnit (even without our special runners), so the problem > may be theirs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-277) JarSignerUtil.unsignArchive invalid entry compressed size
[ https://jira.codehaus.org/browse/MSHARED-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timo Meinen updated MSHARED-277: Attachment: MSHARED-277.patch Same problem here. Created a patch. > JarSignerUtil.unsignArchive invalid entry compressed size > - > > Key: MSHARED-277 > URL: https://jira.codehaus.org/browse/MSHARED-277 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-jarsigner >Affects Versions: maven-jarsigner-1.0 > Environment: Java 6, Windows 7, Maven 3.0.5 >Reporter: Kai Zimmermann >Priority: Blocker > Attachments: javax.persistence_2.0.5.v201212031355.jar, > MSHARED-277.patch > > > You can check the attached file with > "org.apache.maven.plugins:maven-jarsigner-plugin:1.2:verify" and everything > is fine. But if you want to use > "org.apache.maven.plugins:maven-jarsigner-plugin:1.2:sign" and use the > "removeExistingSignatures" option, you get the following error: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-jarsigner-plugin:1.2:sign (sign) on project > unsign: Failed to unsign archive javax.persistence_2.0.5.v201212031355.jar: > invalid entry compressed size (expected 6375 but got 6495 bytes) -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-jarsigner-plugin:1.2:sign (sign) on > project unsign: Failed to unsign archive > javax.persistence_2.0.5.v201212031355.jar: invalid entry compressed size > (expected 6375 but got 6495 bytes) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) > 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:319) > 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:601) > 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.MojoExecutionException: Failed to unsign > archive > C:\Projekte\Java\SE\aktuelle\unsign\javax.persistence_2.0.5.v201212031355.jar: > invalid entry compressed size (expected 6375 but got 6495 bytes) > at > org.apache.maven.plugins.jarsigner.JarsignerSignMojo.unsignArchive(JarsignerSignMojo.java:252) > at > org.apache.maven.plugins.jarsigner.JarsignerSignMojo.preProcessArchive(JarsignerSignMojo.java:204) > at > org.apache.maven.plugins.jarsigner.AbstractJarsignerMojo.processArchive(AbstractJarsignerMojo.java:418) > at > org.apache.maven.plugins.jarsigner.AbstractJarsignerMojo.execute(AbstractJarsignerMojo.java:263) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) > ... 19 more > Caused by: java.util.zip.ZipException: invalid entry compressed size > (expected 6375 but got 6495 bytes) > at java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:248) > at > java.util.zip.ZipOutputStream.putNextEntry(ZipOutputStream.java:177) > at > org.apache.maven.plugins.jarsigner.JarsignerSignMojo.unsignArchive(JarsignerSignMojo.java:244) > ... 24 more > I have bypassed the problem with a small patch in JarSignerUtil line 107: > zos.putNextEntry(
[jira] (MWAR-304) WAR plugin ignores attached artifacts from previous plugins
[ https://jira.codehaus.org/browse/MWAR-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=331185#comment-331185 ] Richard Sand commented on MWAR-304: --- OK understood, thanks for the explanation > WAR plugin ignores attached artifacts from previous plugins > --- > > Key: MWAR-304 > URL: https://jira.codehaus.org/browse/MWAR-304 > Project: Maven WAR Plugin > Issue Type: Bug > Components: overlay >Affects Versions: 2.4 > Environment: any >Reporter: Richard Sand > > If my maven project includes a plugin that attaches an artifact to the > project, the war plugin will not process the artifact for inclusion in the > results -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MWAR-304) WAR plugin ignores attached artifacts from previous plugins
[ https://jira.codehaus.org/browse/MWAR-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand closed MWAR-304. - Resolution: Not A Bug > WAR plugin ignores attached artifacts from previous plugins > --- > > Key: MWAR-304 > URL: https://jira.codehaus.org/browse/MWAR-304 > Project: Maven WAR Plugin > Issue Type: Bug > Components: overlay >Affects Versions: 2.4 > Environment: any >Reporter: Richard Sand > > If my maven project includes a plugin that attaches an artifact to the > project, the war plugin will not process the artifact for inclusion in the > results -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MWAR-304) WAR plugin ignores attached artifacts from previous plugins
[ https://jira.codehaus.org/browse/MWAR-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand reopened MWAR-304: --- Sorry just one question before closing - is there any merit to the idea of having a configuration option in maven-war-plugin to include attached artifacts in the webapp in the same way it includes dependent artifacts? If there is merit to the idea I'll be happy to submit a new update here > WAR plugin ignores attached artifacts from previous plugins > --- > > Key: MWAR-304 > URL: https://jira.codehaus.org/browse/MWAR-304 > Project: Maven WAR Plugin > Issue Type: Bug > Components: overlay >Affects Versions: 2.4 > Environment: any >Reporter: Richard Sand > > If my maven project includes a plugin that attaches an artifact to the > project, the war plugin will not process the artifact for inclusion in the > results -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (DOXIA-386) Snippet Macro: Reference file does not support UTF-8 file format to generate the page garbage
[
https://jira.codehaus.org/browse/DOXIA-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=331198#comment-331198
]
Michael Osipov commented on DOXIA-386:
--
After an investigation, I have found this spot:
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.maven.doxia/doxia-site-renderer/1.4/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#406
So we would need to pass the encoding all way down. It would require to change
a lot of change. I have an lighter patch for that. I simply added an encoding
parameter to the snippet macro which works as desired, though I dislike what
the sink does. It turns everything above 7 bit into a entity reference but all
chars get passed.
Should a upload the patch and the apply after approval?
> Snippet Macro: Reference file does not support UTF-8 file format to generate
> the page garbage
> --
>
> Key: DOXIA-386
> URL: https://jira.codehaus.org/browse/DOXIA-386
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.1.2
> Environment: windows7 zh_CN
>Reporter: pinghe
>
> {code:xml}
>
> maven-site-plugin
> 2.1
>
> zh_CN
> UTF-8
> UTF-8
>
>
> {code}
> my sample apt file:
> {noformat}
> %{snippet|file=target/site/reference/html/sample.html|verbatim=false}
> {noformat}
> sample.html:
> {code:xml}
>
>PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
> xmlns="http://www.w3.org/1999/xhtml";>中文
> {code}
> {{org.apache.maven.doxia.macro.snippet.SnippetReader}}
> readLines:
> {code}
> reader = new BufferedReader(new InputStreamReader(source.openStream()));
> {code}
> use {{InputStreamReader(InputStream in)}}
> change to:
> {code}
> InputStreamReader(InputStream in, Charset cs)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-381) Both Maven 2 and 3 fail to retrieve a that is larger than Integer.MAX_VALUE
[
https://jira.codehaus.org/browse/WAGON-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=331203#comment-331203
]
Benson Margulies commented on WAGON-381:
We're seeing the same thing here with Nexus as the repo.
> Both Maven 2 and 3 fail to retrieve a that is larger than
> Integer.MAX_VALUE
>
>
> Key: WAGON-381
> URL: https://jira.codehaus.org/browse/WAGON-381
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 2.2
>Reporter: Evgeny Goldin
>Assignee: Olivier Lamy
> Fix For: 2.5
>
> Attachments: 1.png, 2.png
>
>
> We have a *{{*.tar}}* file stored in corporate Maven repository, its size is
> *{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of
> *{{2147483647}}* size to be downloaded to local maven repo, which is exactly
> 231-1.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1007) Inconsisten encoding with large standard output
[ https://jira.codehaus.org/browse/SUREFIRE-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=331209#comment-331209 ] Yves Langisch commented on SUREFIRE-1007: - Just did some testing with 2.16 and 2.17-SNAPSHOT. They show the same behavior. The switch of the encoding in the middle of the output seems to be fixed :). But as a new behavior I noticed that the file.encoding property is completely ignored. The output in the XML is always UTF-8. With versions < 2.16 that property was honored. What's the correct behavior? > Inconsisten encoding with large standard output > --- > > Key: SUREFIRE-1007 > URL: https://jira.codehaus.org/browse/SUREFIRE-1007 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Report Plugin, xml generation >Affects Versions: 2.14.1, 2.15 >Reporter: Yves Langisch > Attachments: ibm-jdk7.log, ora-jdk7.log, surefire-encoding-test.zip, > TEST-net.test.surefireencodingtest.EncodingTest.xml > > > When having a lot of standard output in a failing test, the encoding of the > resulting surefire-report XML is not consistent. The attached project shows > that the encoding in 'TEST-net.test.surefireencodingtest.EncodingTest.xml' in > the element suddenly switches from UTF-8 to ISO-8859-1. > Any workaround is highly appreciated... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1007) Inconsisten encoding with large standard output
[ https://jira.codehaus.org/browse/SUREFIRE-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=331210#comment-331210 ] Kristian Rosenvold commented on SUREFIRE-1007: -- The xml file should always be UTF-8 (regardless of file.encoding), so previous versions were buggy. The "txt" file should respect file.encoding. > Inconsisten encoding with large standard output > --- > > Key: SUREFIRE-1007 > URL: https://jira.codehaus.org/browse/SUREFIRE-1007 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Report Plugin, xml generation >Affects Versions: 2.14.1, 2.15 >Reporter: Yves Langisch > Attachments: ibm-jdk7.log, ora-jdk7.log, surefire-encoding-test.zip, > TEST-net.test.surefireencodingtest.EncodingTest.xml > > > When having a lot of standard output in a failing test, the encoding of the > resulting surefire-report XML is not consistent. The attached project shows > that the encoding in 'TEST-net.test.surefireencodingtest.EncodingTest.xml' in > the element suddenly switches from UTF-8 to ISO-8859-1. > Any workaround is highly appreciated... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1007) Inconsisten encoding with large standard output
[
https://jira.codehaus.org/browse/SUREFIRE-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=331211#comment-331211
]
Andreas Gudian commented on SUREFIRE-1007:
--
The correct behavior is UTF-8 in the XML file (as stated in the processor
directive in the first line of the file). The output file with stdout and
stderr of the test should be in {{file.encoding}}.
> Inconsisten encoding with large standard output
> ---
>
> Key: SUREFIRE-1007
> URL: https://jira.codehaus.org/browse/SUREFIRE-1007
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin, xml generation
>Affects Versions: 2.14.1, 2.15
>Reporter: Yves Langisch
> Attachments: ibm-jdk7.log, ora-jdk7.log, surefire-encoding-test.zip,
> TEST-net.test.surefireencodingtest.EncodingTest.xml
>
>
> When having a lot of standard output in a failing test, the encoding of the
> resulting surefire-report XML is not consistent. The attached project shows
> that the encoding in 'TEST-net.test.surefireencodingtest.EncodingTest.xml' in
> the element suddenly switches from UTF-8 to ISO-8859-1.
> Any workaround is highly appreciated...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1007) Inconsisten encoding with large standard output
[ https://jira.codehaus.org/browse/SUREFIRE-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=331212#comment-331212 ] Andreas Gudian commented on SUREFIRE-1007: -- Kristian was faster ;). @Yves: I guess we can close this issue now, right? > Inconsisten encoding with large standard output > --- > > Key: SUREFIRE-1007 > URL: https://jira.codehaus.org/browse/SUREFIRE-1007 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Report Plugin, xml generation >Affects Versions: 2.14.1, 2.15 >Reporter: Yves Langisch > Attachments: ibm-jdk7.log, ora-jdk7.log, surefire-encoding-test.zip, > TEST-net.test.surefireencodingtest.EncodingTest.xml > > > When having a lot of standard output in a failing test, the encoding of the > resulting surefire-report XML is not consistent. The attached project shows > that the encoding in 'TEST-net.test.surefireencodingtest.EncodingTest.xml' in > the element suddenly switches from UTF-8 to ISO-8859-1. > Any workaround is highly appreciated... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1007) Inconsisten encoding with large standard output
[ https://jira.codehaus.org/browse/SUREFIRE-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=331213#comment-331213 ] Yves Langisch commented on SUREFIRE-1007: - Yes, you can close the issue. Thanks! > Inconsisten encoding with large standard output > --- > > Key: SUREFIRE-1007 > URL: https://jira.codehaus.org/browse/SUREFIRE-1007 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Report Plugin, xml generation >Affects Versions: 2.14.1, 2.15 >Reporter: Yves Langisch > Attachments: ibm-jdk7.log, ora-jdk7.log, surefire-encoding-test.zip, > TEST-net.test.surefireencodingtest.EncodingTest.xml > > > When having a lot of standard output in a failing test, the encoding of the > resulting surefire-report XML is not consistent. The attached project shows > that the encoding in 'TEST-net.test.surefireencodingtest.EncodingTest.xml' in > the element suddenly switches from UTF-8 to ISO-8859-1. > Any workaround is highly appreciated... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1007) Inconsisten encoding with large standard output
[ https://jira.codehaus.org/browse/SUREFIRE-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Gudian reassigned SUREFIRE-1007: Assignee: Andreas Gudian > Inconsisten encoding with large standard output > --- > > Key: SUREFIRE-1007 > URL: https://jira.codehaus.org/browse/SUREFIRE-1007 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Report Plugin, xml generation >Affects Versions: 2.14.1, 2.15 >Reporter: Yves Langisch >Assignee: Andreas Gudian > Attachments: ibm-jdk7.log, ora-jdk7.log, surefire-encoding-test.zip, > TEST-net.test.surefireencodingtest.EncodingTest.xml > > > When having a lot of standard output in a failing test, the encoding of the > resulting surefire-report XML is not consistent. The attached project shows > that the encoding in 'TEST-net.test.surefireencodingtest.EncodingTest.xml' in > the element suddenly switches from UTF-8 to ISO-8859-1. > Any workaround is highly appreciated... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1007) Inconsisten encoding with large standard output
[ https://jira.codehaus.org/browse/SUREFIRE-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Gudian closed SUREFIRE-1007. Resolution: Fixed Fix Version/s: 2.16 > Inconsisten encoding with large standard output > --- > > Key: SUREFIRE-1007 > URL: https://jira.codehaus.org/browse/SUREFIRE-1007 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Report Plugin, xml generation >Affects Versions: 2.14.1, 2.15 >Reporter: Yves Langisch >Assignee: Andreas Gudian > Fix For: 2.16 > > Attachments: ibm-jdk7.log, ora-jdk7.log, surefire-encoding-test.zip, > TEST-net.test.surefireencodingtest.EncodingTest.xml > > > When having a lot of standard output in a failing test, the encoding of the > resulting surefire-report XML is not consistent. The attached project shows > that the encoding in 'TEST-net.test.surefireencodingtest.EncodingTest.xml' in > the element suddenly switches from UTF-8 to ISO-8859-1. > Any workaround is highly appreciated... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
