[jira] (SUREFIRE-1007) Inconsisten encoding with large standard output
[ https://jira.codehaus.org/browse/SUREFIRE-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 system-out 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-tabpanelfocusedCommentId=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 system-out 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-tabpanelfocusedCommentId=330637#comment-330637 ] Yves Langisch commented on SUREFIRE-1007: - Did you already begin the rework mentioned? It would be great to test a newly available snapshot. 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 system-out 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-tabpanelfocusedCommentId=327757#comment-327757 ] Yves Langisch commented on SUREFIRE-1007: - How do you interpret the logs? Anything else I can provide to help you to track down the bug? 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 system-out 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 ] Yves Langisch updated SUREFIRE-1007: Attachment: ora-jdk7.log ibm-jdk7.log Here we go with the two logs. In ibm-jdk7.log you see the same difference as in the report. 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 system-out 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
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 system-out 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-tabpanelfocusedCommentId=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 system-out 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-tabpanelfocusedCommentId=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 system-out 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] (MRELEASE-795) Wrong level when using release:branch
Yves Langisch created MRELEASE-795: -- Summary: Wrong level when using release:branch Key: MRELEASE-795 URL: https://jira.codehaus.org/browse/MRELEASE-795 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.3.2 Reporter: Yves Langisch Attachments: Align_baseUrl_.patch My project has different modules that reference a parent which is in its own folder. SCM part is as follows: scm connectionscm:svn:http://blabla.com/trunk/parent/connection developerConnectionscm:svn:http://blabla.com/trunk/parent/developerConnection urlhttp://blabla.com/trunk/parent/url /scm When using the release:branch goal I then only see the parent folder in my SVN-branch instead of all modules one level higher. Releasing works fine though. I've compared the classes ScmBranchPhase and ScmTagPhase. It looks like the baseDir is not aligned in the case of ScmBranchPhase. After patching the class the branch goal worked as expected. Patch attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-526) release:prepare 2.0 goal tags at the wrong level, tagging project/ instead of project/trunk
[
http://jira.codehaus.org/browse/MRELEASE-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=269282#action_269282
]
Yves Langisch commented on MRELEASE-526:
Where is the new issue? I have the same prolem with Maven 3.0.3 and the plugin
versions 2.0 and 2.1.
release:prepare 2.0 goal tags at the wrong level, tagging project/ instead of
project/trunk
---
Key: MRELEASE-526
URL: http://jira.codehaus.org/browse/MRELEASE-526
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0
Environment: Maven 2.2.1
Reporter: Damien Coraboeuf
Assignee: Brett Porter
Priority: Critical
Attachments: export.zip
We have switched to the release plug-in 2.0 and are using the prepare goal as
we did before using version 2.0-beta-9. Unfortunately, the tag which is now
created is copied from the project level, and from the trunk. With version
2.0-beta-9, the tag was correctly copied from the trunk.
With 2.0-beta-9:
{noformat}
/project
|-- trunk/
|-- pom.xml
|-- src/
|-- tags/
|-- 4.0.1/ (-- copied from trunk
|-- pom.xml
|-- src/
{noformat}
With 2.0:
{noformat}
/project
|-- trunk/
|-- pom.xml
|-- src/
|-- tags/
|-- 4.0.1/ (-- copied from trunk
|-- trunk/
|-- pom.xml
|-- src/
|-- tags/
|-- branches/
{noformat}
Our _pom.xml_ SCM information is declared as follow:
{noformat}
scm
developerConnectionscm:svn:svn://host/path/project/trunk/developerConnection
/scm
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-597) Workspace dependencies not resolved for SNAPSHOT dependencies (artifact has a different version from that in dependency management)
[
http://jira.codehaus.org/browse/MECLIPSE-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=262648#action_262648
]
Yves Langisch commented on MECLIPSE-597:
We are regularly stumbling over this issue which leads to time costly manually
work. Is there any reason why the provided patch is not applied yet? I could
provide a new patch against the trunk if necessary.
Thanks
Yves
Workspace dependencies not resolved for SNAPSHOT dependencies (artifact has a
different version from that in dependency management)
---
Key: MECLIPSE-597
URL: http://jira.codehaus.org/browse/MECLIPSE-597
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Core : Dependencies resolution and build path
(.classpath)
Affects Versions: 2.7
Environment: Nexus 1.3.6, Eclipse 3.4, Windows XP
Reporter: Michal Galet
Priority: Critical
Attachments: maven-eclipse-plugin-2.7.patch
When generating eclipse project with mvn eclipse:eclipse
-Declipse.workspace=d:/eclipse-ws the SNAPSHOT dependencies are not resolved
from workspace correctly. See console output below. This is probably caused
by the way how Nexus handles the SNAPSHOTs. The artifact is resolved by
ArtifactResolver and the version is changed from 1.1.0-SNAPSHOT to
1.1.0-20090819.145009-4.
The comparison should be performed against {{artifact.getBaseVersion()}}
instead of {{artifact.getVersion()}}. A simple fix is attached as a patch.
Console output:
[INFO] Artifact com.test:sample:jar:4.0.0.B02-SNAPSHOT already available a
s a workspace project, but with different version. Expected:
4.0.0.B02-20090819.145009-4, found
: 4.0.0.B02-SNAPSHOT
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MECLIPSE-597) Workspace dependencies not resolved for SNAPSHOT dependencies (artifact has a different version from that in dependency management)
[
http://jira.codehaus.org/browse/MECLIPSE-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=262648#action_262648
]
Yves Langisch edited comment on MECLIPSE-597 at 4/6/11 3:55 AM:
We are regularly stumbling over this issue which leads to time costly manual
work. Is there any reason why the provided patch is not applied yet? I could
provide a new patch against the trunk if necessary.
Thanks
Yves
was (Author: ylangisc):
We are regularly stumbling over this issue which leads to time costly
manually work. Is there any reason why the provided patch is not applied yet? I
could provide a new patch against the trunk if necessary.
Thanks
Yves
Workspace dependencies not resolved for SNAPSHOT dependencies (artifact has a
different version from that in dependency management)
---
Key: MECLIPSE-597
URL: http://jira.codehaus.org/browse/MECLIPSE-597
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Core : Dependencies resolution and build path
(.classpath)
Affects Versions: 2.7
Environment: Nexus 1.3.6, Eclipse 3.4, Windows XP
Reporter: Michal Galet
Priority: Critical
Attachments: maven-eclipse-plugin-2.7.patch
When generating eclipse project with mvn eclipse:eclipse
-Declipse.workspace=d:/eclipse-ws the SNAPSHOT dependencies are not resolved
from workspace correctly. See console output below. This is probably caused
by the way how Nexus handles the SNAPSHOTs. The artifact is resolved by
ArtifactResolver and the version is changed from 1.1.0-SNAPSHOT to
1.1.0-20090819.145009-4.
The comparison should be performed against {{artifact.getBaseVersion()}}
instead of {{artifact.getVersion()}}. A simple fix is attached as a patch.
Console output:
[INFO] Artifact com.test:sample:jar:4.0.0.B02-SNAPSHOT already available a
s a workspace project, but with different version. Expected:
4.0.0.B02-20090819.145009-4, found
: 4.0.0.B02-SNAPSHOT
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSHARED-190) More flexible manifest classpath
More flexible manifest classpath
Key: MSHARED-190
URL: http://jira.codehaus.org/browse/MSHARED-190
Project: Maven Shared Components
Issue Type: Improvement
Components: maven-archiver
Affects Versions: maven-archiver-2.4.1
Reporter: Yves Langisch
Attachments: third_party_classpathPrefix.patch
I'd like to see a more flexible way to adjust the classpath entries in the
manifest file. For example with the ear-plugin I'm able to put third party
libraries to a different folder (e.g. lib/) than project module artifacts (e.g.
root folder). For ejb-modules I need to be able to specify classpath entries
for both folders (e.g. lib/log4j.jar and a.b.c.project-common.jar). As you can
only specify a general prefix this layout is currently not handled.
Attached you find a patch against the trunk which introduces a new additional
configuration option {{classpathPrefixThirdParty}}. Dependencies that have a
different groupId from the project itself are prefixed with that option.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
