[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=327419#comment-327419 ] Kristian Rosenvold commented on SUREFIRE-1007: -- This bug certainly has my attention :) I had a quick look yesterday and there might actually be something in how we encode the output from the fork that is spooled back to the actual plugin, it does not look entirely correct - even on oracle JDK. (I do "mvn -X -e test" inside your project and look for the phrase "Forking command Line". This allows me to pick up the actual java incantation that starts the fork, and also allows me to look at the encoded output from the fork. On my machine right now I can re-run the following command: c:\java\jdk1.7.0_21\jre\bin\java -Dfile.encoding=UTF-8 -jar c:\surefire-encoding-test\target\surefire\surefirebooter3824531682507406949.jar c:\surefire-encoding-test\target\surefire\surefire7318311038042376446tmp c:\surefire-encoding-test\target\surefire\surefire_08096983680892074894tmp If you can capture this output from the IBM jdk7 version and any other "working" version, it would be extemely interesting to know if the output is different; it should be identical to the last byte. > 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: 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] (MNGSITE-182) [site] download page consistency
[ https://jira.codehaus.org/browse/MNGSITE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MNGSITE-182. Resolution: Fixed thanks! > [site] download page consistency > > > Key: MNGSITE-182 > URL: https://jira.codehaus.org/browse/MNGSITE-182 > Project: Maven Project Web Site > Issue Type: Improvement > Environment: n/a >Reporter: Eric Barboni >Assignee: Olivier Lamy >Priority: Minor > Attachments: download.xml.vm.patch, download.xml.vm.patch > > > a little patch to make download page more consistent in 3 operation > 1) remove the duplicated row for both > maven 3.1.0-alpha1 and 3.0.5 (binary tar.gz) > 2)section 3.1 series the same as others series. > 3) add a paragraph for 3.1 and 3.0.5 as it was for 2.2 and 2.0. Text is to > be reviewed I guess) > regards -- 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] (MNGSITE-182) [site] download page consistency
[ https://jira.codehaus.org/browse/MNGSITE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reassigned MNGSITE-182: Assignee: Olivier Lamy > [site] download page consistency > > > Key: MNGSITE-182 > URL: https://jira.codehaus.org/browse/MNGSITE-182 > Project: Maven Project Web Site > Issue Type: Improvement > Environment: n/a >Reporter: Eric Barboni >Assignee: Olivier Lamy >Priority: Minor > Attachments: download.xml.vm.patch, download.xml.vm.patch > > > a little patch to make download page more consistent in 3 operation > 1) remove the duplicated row for both > maven 3.1.0-alpha1 and 3.0.5 (binary tar.gz) > 2)section 3.1 series the same as others series. > 3) add a paragraph for 3.1 and 3.0.5 as it was for 2.2 and 2.0. Text is to > be reviewed I guess) > regards -- 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] (MNGSITE-182) [site] download page consistency
[ https://jira.codehaus.org/browse/MNGSITE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Barboni updated MNGSITE-182: - Attachment: download.xml.vm.patch updated to last commited changes > [site] download page consistency > > > Key: MNGSITE-182 > URL: https://jira.codehaus.org/browse/MNGSITE-182 > Project: Maven Project Web Site > Issue Type: Improvement > Environment: n/a >Reporter: Eric Barboni >Priority: Minor > Attachments: download.xml.vm.patch, download.xml.vm.patch > > > a little patch to make download page more consistent in 3 operation > 1) remove the duplicated row for both > maven 3.1.0-alpha1 and 3.0.5 (binary tar.gz) > 2)section 3.1 series the same as others series. > 3) add a paragraph for 3.1 and 3.0.5 as it was for 2.2 and 2.0. Text is to > be reviewed I guess) > regards -- 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=327407#comment-327407 ] Yves Langisch commented on SUREFIRE-1007: - Any idea what could cause this different behaviour? JDK bug, improper use of stream in the plugin, ... > 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: 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=327403#comment-327403 ] Yves Langisch commented on SUREFIRE-1007: - Did some more testing (all platforms with os.encoding=UTF-8): OS X / JDK6: OK Windows / Oracle JDK6: OK Windows / Oracle JDK7: OK Windows / IBM JDK6: OK Windows / IBM JDK7: NOK -> is my default JDK as we develop for Websphere 8.5 :( > 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: 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] (MJAR-156) Classpath created in manifest contains timestamp instead of the suffix "-SNAPSHOT"
[
https://jira.codehaus.org/browse/MJAR-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=327401#comment-327401
]
Jason Mihalick edited comment on MJAR-156 at 6/26/13 2:49 PM:
--
I am having the same problem. This is particularly problematic if one is also
using the maven-dependency-plugin, which uses the -SNAPSHOT suffix when copying
snapshot artifacts. I thought I could use the maven-dependency-plugin to
quickly collect the dependencies for my artifact into a directory that I could
use for deploying to a target server and then have the auto generated manifest
in my executable jar align with those same dependencies. The problem is that
the manifest snapshot dependencies have timestamps on them while the
dependencies collected by the dependency plugin use the -SNAPSHOT suffix. :(
Update: for those that find this in the future. I found the solution to my
particular problem above
[here|http://stackoverflow.com/questions/14256291/maven-archiver-uses-unlocked-snapshot-in-classpath-but-copy-dependencies-copy-l].
was (Author: jrmihalick):
I am having the same problem. This is particularly problematic if one is
also using the maven-dependency-plugin, which uses the -SNAPSHOT suffix when
copying snapshot artifacts. I thought I could use the maven-dependency-plugin
to quickly collect the dependencies for my artifact into a directory that I
could use for deploying to a target server and then have the auto generated
manifest in my executable jar align with those same dependencies. The problem
is that the manifest snapshot dependencies have timestamps on them while the
dependencies collected by the dependency plugin use the -SNAPSHOT suffix. :(
> Classpath created in manifest contains timestamp instead of the suffix
> "-SNAPSHOT"
> ---
>
> Key: MJAR-156
> URL: https://jira.codehaus.org/browse/MJAR-156
> Project: Maven 2.x JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.3.2, 2.4
> Environment: Win7 Pro SP1 (64 Bit), JDK 1.6.0_26 (32 Bit)
>Reporter: Markus KARG
> Attachments: Sample.zip
>
>
> Sometimes the JAR packager replaces a dependency's "-SNAPSHOT" suffix by a
> timestamp when calculating a corresponding "Class-Path:"-entry for all
> dependencies into the MANIFEST.MF file of the packaged JAR. This is
> problematic, as typically the dependency shipped together with the created
> JAR will NOT be renamed, but shipped WITH the suffix "-SNAPSHOT". The created
> JAR will at runtime not find the JAR due to the wrong suffix then
> ("ClassNotFoundException" will happen for all content in the dependency,
> obviously). Strange but true, this seem to happen only for SOME JARs and only
> in SOME particular situations, but I was not able to identify the root causes.
> Attached is a tiny MVN project containing a pom that will produce this
> behaviour.
> * How to demonstrate:
> - Unpack attached JAR
> - Manually deploy the dependency "webdav-jaxrs-1.2-SNAPSHOT.jar" found in
> subfolder "install-this-in-repo" into the local repository.
> - mvn clean package
> - "target\sample-1.0.0-SNAPSHOT.jar" contains wrong MANIFEST.MF Class-Path:
> entry now:
> Class-Path: webdav-jaxrs-1.2-20120621.141509-35.jar jsr311-api-1.1.1.jar
> (Sample output contained in ZIP\target!)
> Obviously "-SNAPSHOT" was replaced by "20120621.141509-35", what induces the
> problem that the actual dependency is not found, as its file ends still on
> "-SNAPSHOT" (by intention!). This scenario typically happens when both files
> end up in an EAR for example.
> * Expected Result:
> - Class-Path: webdav-jaxrs-1.2-SNAPSHOT.jar jsr311-api-1.1.1.jar
> * Actual Result:
> - Class-Path: webdav-jaxrs-1.2-20120621.141509-35.jar jsr311-api-1.1.1.jar
> * Workaround:
> - Provide a static MANIFEST.MF file. Drawback: Changing dependency induces
> manual corrections to the static file.
> - Fix the entry manually after each build. Drawback: Hard to automate this.
--
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] (MJAR-156) Classpath created in manifest contains timestamp instead of the suffix "-SNAPSHOT"
[
https://jira.codehaus.org/browse/MJAR-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=327401#comment-327401
]
Jason Mihalick commented on MJAR-156:
-
I am having the same problem. This is particularly problematic if one is also
using the maven-dependency-plugin, which uses the -SNAPSHOT suffix when copying
snapshot artifacts. I thought I could use the maven-dependency-plugin to
quickly collect the dependencies for my artifact into a directory that I could
use for deploying to a target server and then have the auto generated manifest
in my executable jar align with those same dependencies. The problem is that
the manifest snapshot dependencies have timestamps on them while the
dependencies collected by the dependency plugin use the -SNAPSHOT suffix. :(
> Classpath created in manifest contains timestamp instead of the suffix
> "-SNAPSHOT"
> ---
>
> Key: MJAR-156
> URL: https://jira.codehaus.org/browse/MJAR-156
> Project: Maven 2.x JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.3.2, 2.4
> Environment: Win7 Pro SP1 (64 Bit), JDK 1.6.0_26 (32 Bit)
>Reporter: Markus KARG
> Attachments: Sample.zip
>
>
> Sometimes the JAR packager replaces a dependency's "-SNAPSHOT" suffix by a
> timestamp when calculating a corresponding "Class-Path:"-entry for all
> dependencies into the MANIFEST.MF file of the packaged JAR. This is
> problematic, as typically the dependency shipped together with the created
> JAR will NOT be renamed, but shipped WITH the suffix "-SNAPSHOT". The created
> JAR will at runtime not find the JAR due to the wrong suffix then
> ("ClassNotFoundException" will happen for all content in the dependency,
> obviously). Strange but true, this seem to happen only for SOME JARs and only
> in SOME particular situations, but I was not able to identify the root causes.
> Attached is a tiny MVN project containing a pom that will produce this
> behaviour.
> * How to demonstrate:
> - Unpack attached JAR
> - Manually deploy the dependency "webdav-jaxrs-1.2-SNAPSHOT.jar" found in
> subfolder "install-this-in-repo" into the local repository.
> - mvn clean package
> - "target\sample-1.0.0-SNAPSHOT.jar" contains wrong MANIFEST.MF Class-Path:
> entry now:
> Class-Path: webdav-jaxrs-1.2-20120621.141509-35.jar jsr311-api-1.1.1.jar
> (Sample output contained in ZIP\target!)
> Obviously "-SNAPSHOT" was replaced by "20120621.141509-35", what induces the
> problem that the actual dependency is not found, as its file ends still on
> "-SNAPSHOT" (by intention!). This scenario typically happens when both files
> end up in an EAR for example.
> * Expected Result:
> - Class-Path: webdav-jaxrs-1.2-SNAPSHOT.jar jsr311-api-1.1.1.jar
> * Actual Result:
> - Class-Path: webdav-jaxrs-1.2-20120621.141509-35.jar jsr311-api-1.1.1.jar
> * Workaround:
> - Provide a static MANIFEST.MF file. Drawback: Changing dependency induces
> manual corrections to the static file.
> - Fix the entry manually after each build. Drawback: Hard to automate this.
--
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=327400#comment-327400 ] Kristian Rosenvold edited comment on SUREFIRE-1007 at 6/26/13 1:29 PM: --- "Works here" :) What is your OS/default encoding? was (Author: krosenvold): "Works here" :) What is your OS/default 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: 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=327400#comment-327400 ] Kristian Rosenvold commented on SUREFIRE-1007: -- "Works here" :) What is your OS/default 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: 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-998) Problems with Umlauts in (and probably ) content of junit xml report.
[
https://jira.codehaus.org/browse/SUREFIRE-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=327399#comment-327399
]
Kristian Rosenvold commented on SUREFIRE-998:
-
@Mirko:
The source file contains
0150 63 65 70 74 69 6f 6e 28 22 c3 a4 c3 b6 c3 bc c3 |ception("...|
0160 9f 22 29 3b 0a 20 20 20 20 20 20 20 20 53 79 73 |.");.Sys|
and the report file contains:
1520 6c 61 6e 67 2e 49 6c 6c 65 67 61 6c 53 74 61 74 |lang.IllegalStat|
1530 65 45 78 63 65 70 74 69 6f 6e 3a 20 c3 a4 c3 b6 |eException: |
1540 c3 bc c3 9f 0a 55 54 46 2d 38 0a 3c 2f 73 79 73 |.UTF-8.<
I suspect the problem is actually SUREFIRE-1006 ?
> Problems with Umlauts in (and probably ) content of
> junit xml report.
> --
>
> Key: SUREFIRE-998
> URL: https://jira.codehaus.org/browse/SUREFIRE-998
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Report Plugin
>Affects Versions: 2.15
> Environment: Apache Maven 3.0.5
> (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 14:51:28+0100)
> Maven home: /Software/nobackup/apache-maven-3.0.5
> Java version: 1.7.0_21, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.8.3", arch: "x86_64", family: "mac"
>Reporter: Mirko Friedenhagen
>Assignee: Kristian Rosenvold
> Fix For: 2.15
>
> Attachments: pastebin-surefire-encoding-test (1).zip,
> pastebin-surefire-encoding-test.zip
>
>
> When I output german umlauts on stdout, with surefire-2.14.1 everything runs
> fine, with surefire-2.15-SNAPSHOT (ce62b9a2c0b36105355f44c71f29f01d2f818c46)
> I get the following stacktrace:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-report-plugin:2.15-SNAPSHOT:report
> (default-cli) on project surefire-encoding-test: An error has occurred in
> Surefire Report report generation. Error parsing JUnit XML report
> /Users/mirko/workspace/foss/pastebin/target/surefire-reports/TEST-net.friedenhagen.surefireencodingtest.EncodingTest.xml:
> The reference to entity "amp" must end with the ';' delimiter. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal
> org.apache.maven.plugins:maven-surefire-report-plugin:2.15-SNAPSHOT:report
> (default-cli) on project surefire-encoding-test: An error has occurred in
> Surefire Report report generation.
> 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: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: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: An error has
> occurred in Surefire Report report generation.
> at
> org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:122)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java
[jira] (SUREFIRE-1007) Inconsisten encoding with large standard output
Yves Langisch created SUREFIRE-1007: --- Summary: 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.15, 2.14.1 Reporter: Yves Langisch Attachments: 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] (MNGSITE-152) Maven websites don't follow ASF rules on License
[ https://jira.codehaus.org/browse/MNGSITE-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=327395#comment-327395 ] SebbASF commented on MNGSITE-152: - PING > Maven websites don't follow ASF rules on License > > > Key: MNGSITE-152 > URL: https://jira.codehaus.org/browse/MNGSITE-152 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: SebbASF > > ASF projects are supposed to provide a prominent link [0] to the ASF licenses > page [1] > AIUI, websites are not supposed to provide their own license pages. > [0] http://apache.org/foundation/marks/pmcs.html#navigation > [1] http://www.apache.org/licenses/ -- 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] (MJAVADOC-371) Goals missing from overview page
SebbASF created MJAVADOC-371: Summary: Goals missing from overview page Key: MJAVADOC-371 URL: https://jira.codehaus.org/browse/MJAVADOC-371 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.9 Reporter: SebbASF Priority: Minor The plugin overview page says that javadoc has ten goals, however according to "mvn javadoc:help" it has 13. This includes the "help" goal but there are still 2 goals missing: javadoc:resource-bundle javadoc:test-resource-bundle These should be added to the page. -- 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] (SCM-503) create a native Java GIT provider using JGit
[ https://jira.codehaus.org/browse/SCM-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=327355#comment-327355 ] Frank Jakop commented on SCM-503: - jgit is available in maven central, see http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.eclipse.jgit%22 > create a native Java GIT provider using JGit > > > Key: SCM-503 > URL: https://jira.codehaus.org/browse/SCM-503 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.2 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 1.x > > > JGit is a BSD implementation of GIT in pure Java. > maven-scm-provider-jgit makes use of JGit so we have a Java only stack which > will be a great help on non POSIX conform platforms. -- 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
