[jira] (MNG-5446) AM/PM inconsistency in mng-3827 and mng-3864 ITs?
[
https://jira.codehaus.org/browse/MNG-5446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321687#comment-321687
]
Stuart McCulloch commented on MNG-5446:
---
Proposed patch: https://github.com/apache/maven-integration-testing/pull/3
> AM/PM inconsistency in mng-3827 and mng-3864 ITs?
> -
>
> Key: MNG-5446
> URL: https://jira.codehaus.org/browse/MNG-5446
> Project: Maven 2 & 3
> Issue Type: Test
> Components: Integration Tests
>Reporter: Stuart McCulloch
>Priority: Minor
>
> The mng-3827 and mng-3864 ITs both include the following Date parameter in
> their plugin test configuration:
> {code}
> 2008-11-09 11:59:03.0 PM
> {code}
> https://github.com/apache/maven-integration-testing/blob/master/core-it-suite/src/test/resources/mng-3827/pom.xml#L63
> https://github.com/apache/maven-integration-testing/blob/master/core-it-suite/src/test/resources/mng-3864/pom.xml#L69
> This parameter is then expected to be written out as:
> {code}
> 2008-11-09 11:59:03
> {code}
> https://github.com/apache/maven-integration-testing/blob/master/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3827PluginConfigTest.java#L72
> https://github.com/apache/maven-integration-testing/blob/master/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3864PerExecPluginConfigTest.java#L72
> This looks odd - I would expect "23:59:03" since the time is being written
> back out without the AM/PM flag and {code}System.err.println(new
> Date());{code} uses the 24 hour clock on my local JVM.
> I suspect there's a long-standing bug in the Plexus DateConverter where it
> parses the date using a SimpleDateFormat of "-MM-dd HH:mm:ss.S a" for
> values with an AM/PM flag. This format uses 'HH' to parse the hour as 'Hour
> in day (0-23)' rather than 'hh' to parse it as 'Hour in am/pm (1-12)', which
> would explain why "11:59:03.0 PM" is written back as "11:59:03" and not
> "23:59:03".
> If that's the case then I'd like to suggest the dateParam in the mng-3827 and
> mng-3864 ITs is changed to:
> {code}
> 2008-11-09 11:59:03.0 AM
> {code}
> because that way the result would still match the expected "11:59:03" string
> if/when the DateConverter is fixed (I'm doing some refactoring in the
> Sisu-Plexus internals to improve re-use which touches on configuration).
> AFAICT these ITs don't appear to be testing this specific Date conversion
> behaviour (ie. silently ignoring / dropping the PM flag), but if this isn't
> the case and the current behaviour should be maintained for legacy reasons
> then I'd also like to know.
> Thanks in advance!
--
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-5445) Missing PathTranslator @Requirement in org.apache.maven.project.interpolation.StringSearchModelInterpolator
[
https://jira.codehaus.org/browse/MNG-5445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321686#comment-321686
]
Stuart McCulloch commented on MNG-5445:
---
Reduced testcase (removes IT dependency on versions plugin)
https://github.com/apache/maven-integration-testing/pull/2
> Missing PathTranslator @Requirement in
> org.apache.maven.project.interpolation.StringSearchModelInterpolator
> ---
>
> Key: MNG-5445
> URL: https://jira.codehaus.org/browse/MNG-5445
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.0.4
>Reporter: Stuart McCulloch
>Assignee: Olivier Lamy
> Fix For: 3.1.0
>
>
> In Maven 2.2.1 the StringSearchModelInterpolator component had an explicit
> PathTranslator requirement defined in the following components.xml:
>
> https://github.com/apache/maven/blob/maven-2.2.1/maven-project/src/main/resources/META-INF/plexus/components.xml#L53
> In Maven 3.x this component became part of the maven-compat module, and while
> other components had their XML requirements turned into @Requirement
> annotations, this was not done for the PathTranslator field declared in
> StringSearchModelInterpolator's superclass:
>
> https://github.com/apache/maven/blob/master/maven-compat/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java#L91
> This is the root cause of https://jira.codehaus.org/browse/MVERSIONS-205
> Suggested patch:
> {code}
> diff --git
> a/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
>
> b/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
> index c77aebd..2190267 100644
> ---
> a/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
> +++
> b/maven-project/src/main/java/org/apache/maven/project/interpolation/AbstractStringBasedModelInterpolator.java
> @@ -25,6 +25,7 @@ import org.apache.maven.model.io.xpp3.MavenXpp3Writer;
> import org.apache.maven.project.DefaultProjectBuilderConfiguration;
> import org.apache.maven.project.ProjectBuilderConfiguration;
> import org.apache.maven.project.path.PathTranslator;
> +import org.codehaus.plexus.component.annotations.Requirement;
> import org.codehaus.plexus.interpolation.AbstractValueSource;
> import org.codehaus.plexus.interpolation.InterpolationException;
> import org.codehaus.plexus.interpolation.InterpolationPostProcessor;
> @@ -88,6 +89,7 @@ public abstract class AbstractStringBasedModelInterpolator
> TRANSLATED_PATH_EXPRESSIONS = translatedPrefixes;
> }
>
> +@Requirement
> private PathTranslator pathTranslator;
>
> private Interpolator interpolator;
> {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] (SCM-714) mvn release:prepare fails if the command line is too long on windows
[ https://jira.codehaus.org/browse/SCM-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321683#comment-321683 ] Robert Scholte commented on SCM-714: I've checked the GIT documentation and I haven't found a way to compress the statement. However, there is the [commitByProject|http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#commitByProject] option, which should commit the files one by one. That way the command line should fit for Windows. > mvn release:prepare fails if the command line is too long on windows > > > Key: SCM-714 > URL: https://jira.codehaus.org/browse/SCM-714 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.8.1 >Reporter: Felix Simmendinger >Priority: Blocker > > The issue from SCM-697 does not solve the issue as the gitprovider is not > using the add command but the checkin command during a release. -- 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-751) Support parallel/fork mode similar to http://maven-junit-plugin.kenai.com/
[ https://jira.codehaus.org/browse/SUREFIRE-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321682#comment-321682 ] Jesse Glick commented on SUREFIRE-751: -- Thanks, this makes it much clearer. > Support parallel/fork mode similar to http://maven-junit-plugin.kenai.com/ > -- > > Key: SUREFIRE-751 > URL: https://jira.codehaus.org/browse/SUREFIRE-751 > Project: Maven Surefire > Issue Type: New Feature > Components: process forking >Affects Versions: 2.9 >Reporter: Stephen Connolly >Assignee: Kristian Rosenvold > Fix For: 2.13 > > Attachments: SUREFIRE-751-part1.patch, SUREFIRE-751-part2.patch > > > The current parallel execution spawns one thread _per_class_ > When there is a large disparity between the number of tests in different > classes, this can result in a longer execution time. This can often happen in > GUI testing, where a couple of classes will contain a lot of long running > (but low cpu) test cases, and the remaining classes run fast. > See http://maven-junit-plugin.kenai.com/ for an attempt at solving 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-751) Support parallel/fork mode similar to http://maven-junit-plugin.kenai.com/
[ https://jira.codehaus.org/browse/SUREFIRE-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321680#comment-321680 ] Andreas Gudian edited comment on SUREFIRE-751 at 3/8/13 2:36 PM: - There it is: http://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html was (Author: agudian): The website of 2.14 is not yet in place, but you can preview it here: http://maven.apache.org/surefire-archives/maven-surefire-2.14/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html The correct URL later on will be: http://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html > Support parallel/fork mode similar to http://maven-junit-plugin.kenai.com/ > -- > > Key: SUREFIRE-751 > URL: https://jira.codehaus.org/browse/SUREFIRE-751 > Project: Maven Surefire > Issue Type: New Feature > Components: process forking >Affects Versions: 2.9 >Reporter: Stephen Connolly >Assignee: Kristian Rosenvold > Fix For: 2.13 > > Attachments: SUREFIRE-751-part1.patch, SUREFIRE-751-part2.patch > > > The current parallel execution spawns one thread _per_class_ > When there is a large disparity between the number of tests in different > classes, this can result in a longer execution time. This can often happen in > GUI testing, where a couple of classes will contain a lot of long running > (but low cpu) test cases, and the remaining classes run fast. > See http://maven-junit-plugin.kenai.com/ for an attempt at solving 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-751) Support parallel/fork mode similar to http://maven-junit-plugin.kenai.com/
[ https://jira.codehaus.org/browse/SUREFIRE-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321680#comment-321680 ] Andreas Gudian commented on SUREFIRE-751: - The website of 2.14 is not yet in place, but you can preview it here: http://maven.apache.org/surefire-archives/maven-surefire-2.14/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html The correct URL later on will be: http://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html > Support parallel/fork mode similar to http://maven-junit-plugin.kenai.com/ > -- > > Key: SUREFIRE-751 > URL: https://jira.codehaus.org/browse/SUREFIRE-751 > Project: Maven Surefire > Issue Type: New Feature > Components: process forking >Affects Versions: 2.9 >Reporter: Stephen Connolly >Assignee: Kristian Rosenvold > Fix For: 2.13 > > Attachments: SUREFIRE-751-part1.patch, SUREFIRE-751-part2.patch > > > The current parallel execution spawns one thread _per_class_ > When there is a large disparity between the number of tests in different > classes, this can result in a longer execution time. This can often happen in > GUI testing, where a couple of classes will contain a lot of long running > (but low cpu) test cases, and the remaining classes run fast. > See http://maven-junit-plugin.kenai.com/ for an attempt at solving 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-968) Test summary line does not indicate what was being run when using concurrency
Jesse Glick created SUREFIRE-968:
Summary: Test summary line does not indicate what was being run
when using concurrency
Key: SUREFIRE-968
URL: https://jira.codehaus.org/browse/SUREFIRE-968
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.14
Environment: Ubuntu, JDK 7
Reporter: Jesse Glick
Priority: Minor
When running multiple test suites in parallel, Surefire prints summaries of
ongoing test counts, but it is not at all clear which results are being
summarized. E.g. with {{forkCount=1C}}:
{code:none}
Running CoreJellyTest
Running org.jvnet.hudson.main.AppTest
Running org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest
Running org.jvnet.hudson.test.MemoryAssertTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
Running org.jvnet.hudson.test.MockFolderTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 15.719 sec
Running hudson.bugs.DateConversionTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.867 sec
Running hudson.bugs.LoginRedirectTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 21.208 sec
Running hudson.bugs.JnlpAccessWithSecuredHudsonTest
Tests run: 538, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 36.847 sec
â¦
{code}
It is impossible to tell which results correspond to which test, since there is
no way to know which test will finish first. At best you can guess based on the
number of test case methods known to be in each class.
The {{Tests run}} summary line should give the suite name.
--
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-751) Support parallel/fork mode similar to http://maven-junit-plugin.kenai.com/
[ https://jira.codehaus.org/browse/SUREFIRE-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321675#comment-321675 ] Jesse Glick commented on SUREFIRE-751: -- @agudian: any progress on your examples page? Struggling the digest the implications of SUREFIRE-949. > Support parallel/fork mode similar to http://maven-junit-plugin.kenai.com/ > -- > > Key: SUREFIRE-751 > URL: https://jira.codehaus.org/browse/SUREFIRE-751 > Project: Maven Surefire > Issue Type: New Feature > Components: process forking >Affects Versions: 2.9 >Reporter: Stephen Connolly >Assignee: Kristian Rosenvold > Fix For: 2.13 > > Attachments: SUREFIRE-751-part1.patch, SUREFIRE-751-part2.patch > > > The current parallel execution spawns one thread _per_class_ > When there is a large disparity between the number of tests in different > classes, this can result in a longer execution time. This can often happen in > GUI testing, where a couple of classes will contain a lot of long running > (but low cpu) test cases, and the remaining classes run fast. > See http://maven-junit-plugin.kenai.com/ for an attempt at solving 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] (MSITE-650) Problem with multiple executions of surefire within site plugin 3.0
[
https://jira.codehaus.org/browse/MSITE-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321665#comment-321665
]
Pierre Cardoso commented on MSITE-650:
--
Well, it is indeed the same problem. Using maven -X, I see that the
maven-surefire-plugin executions triggered by the site plugin are messed up.
The debug traces show that the four executions (default-test, unit-tests,
comp-tests, sys-tests) have the same set of properties, that seem to be those
of unit-tests. Notice the "groups" line :
For default :
{noformat}
[INFO] --- maven-surefire-plugin:2.12.2:test (default-test) @ mavenproject2 ---
[DEBUG] Configuring mojo
org.apache.maven.plugins:maven-surefire-plugin:2.12.2:test from plugin realm
ClassRealm[plugin>org.apache.maven.plugins:maven-surefire-plugin:2.12.2,
parent: sun.misc.Launcher$AppClassLoader@93dee9]
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-surefire-plugin:2.12.2:test' with basic
configurator -->
[DEBUG] (s) basedir = D:\DONNEES\workspace\mavenproject2
[DEBUG] (s) childDelegation = false
[DEBUG] (s) classesDirectory =
D:\DONNEES\workspace\mavenproject2\target\generated-classes\cobertura
[DEBUG] (s) disableXmlReport = false
[DEBUG] (s) enableAssertions = true
[DEBUG] (s) forkMode = once
[DEBUG] (s) groups = com.mycompany.mavenproject2.UnitTest
[DEBUG] (s) junitArtifactName = junit:junit
[DEBUG] (s) localRepository =id: local
{noformat}
For unit-tests :
{noformat}
[INFO] --- maven-surefire-plugin:2.12.2:test (unit-tests) @ mavenproject2 ---
[DEBUG] Configuring mojo
org.apache.maven.plugins:maven-surefire-plugin:2.12.2:test from plugin realm
ClassRealm[plugin>org.apache.maven.plugins:maven-surefire-plugin:2.12.2,
parent: sun.misc.Launcher$AppClassLoader@93dee9]
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-surefire-plugin:2.12.2:test' with basic
configurator -->
[DEBUG] (s) basedir = D:\DONNEES\workspace\mavenproject2
[DEBUG] (s) childDelegation = false
[DEBUG] (s) classesDirectory =
D:\DONNEES\workspace\mavenproject2\target\generated-classes\cobertura
[DEBUG] (s) disableXmlReport = false
[DEBUG] (s) enableAssertions = true
[DEBUG] (s) forkMode = once
[DEBUG] (s) groups = com.mycompany.mavenproject2.UnitTest
[DEBUG] (s) junitArtifactName = junit:junit
[DEBUG] (s) localRepository =id: local
{noformat}
For comp-tests :
{noformat}
[INFO] --- maven-surefire-plugin:2.12.2:test (comp-tests) @ mavenproject2 ---
[DEBUG] Configuring mojo
org.apache.maven.plugins:maven-surefire-plugin:2.12.2:test from plugin realm
ClassRealm[plugin>org.apache.maven.plugins:maven-surefire-plugin:2.12.2,
parent: sun.misc.Launcher$AppClassLoader@93dee9]
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-surefire-plugin:2.12.2:test' with basic
configurator -->
[DEBUG] (s) basedir = D:\DONNEES\workspace\mavenproject2
[DEBUG] (s) childDelegation = false
[DEBUG] (s) classesDirectory =
D:\DONNEES\workspace\mavenproject2\target\generated-classes\cobertura
[DEBUG] (s) disableXmlReport = false
[DEBUG] (s) enableAssertions = true
[DEBUG] (s) forkMode = once
[DEBUG] (s) groups = com.mycompany.mavenproject2.UnitTest
[DEBUG] (s) junitArtifactName = junit:junit
[DEBUG] (s) localRepository =id: local
{noformat}
And so on.
With "mvn install", the debug output is different : the "groups" property only
appear for the non-default runs. And then the values are the right values.
Unit-tests :
{noformat}
[INFO] --- maven-surefire-plugin:2.12.2:test (unit-tests) @ mavenproject2 ---
[DEBUG] Configuring mojo
org.apache.maven.plugins:maven-surefire-plugin:2.12.2:test from plugin realm
ClassRealm[plugin>org.apache.maven.plugins:maven-surefire-plugin:2.12.2,
parent: sun.misc.Launcher$AppClassLoader@93dee9]
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-surefire-plugin:2.12.2:test' with basic
configurator -->
[DEBUG] (s) basedir = D:\DONNEES\workspace\mavenproject2
[DEBUG] (s) childDelegation = false
[DEBUG] (s) classesDirectory =
D:\DONNEES\workspace\mavenproject2\target\classes
[DEBUG] (s) disableXmlReport = false
[DEBUG] (s) enableAssertions = true
[DEBUG] (s) forkMode = once
[DEBUG] (s) groups = com.mycompany.mavenproject2.UnitTest
[DEBUG] (s) junitArtifactName = junit:junit
[DEBUG] (s) localRepository =id: local
{noformat}
Comp-tests :
{noformat}
[INFO] --- maven-surefire-plugin:2.12.2:test (comp-tests) @ mavenproject2 ---
[DEBUG] Configuring mojo
org.apache.maven.plugins:maven-surefire-plugin:2.12.2:test from plugin realm
ClassRealm[plugin>org.apache.maven.plugins:maven-surefire-plugin:2.12.2,
parent: sun.misc.Launcher$AppClassLoader@93dee9]
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-surefire-plugin:2.12.2:test' with basic
configurator -->
[DEBUG] (s) basedir = D:\DONNEES\workspace\mavenproject2
[DEBUG] (s) childDelegation = false
[DEBUG] (s) classesDirectory
[jira] (SUREFIRE-967) ArrayIndexOutOfBounds in SmartStackTraceParser
[
https://jira.codehaus.org/browse/SUREFIRE-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321640#comment-321640
]
Rastislav Cesnek edited comment on SUREFIRE-967 at 3/8/13 7:10 AM:
---
Works charming, tested with maven-surefire-plugin-2.15-20130307.043150-1
{code}
Tests run: 7, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.688 sec <<<
FAILURE!
selfComposite(com.whitestein.lsps.exec.SharedRecordCompositionTest) Time
elapsed: 2.016 sec <<< ERROR!
javax.ejb.EJBTransactionRolledbackException: nested exception is:
javax.ejb.EJBException: See nested exception; nested exception is:
java.util.ConcurrentModificationException
at
java.util.HashMap$AbstractMapIterator.checkConcurrentMod(HashMap.java:191)
at java.util.HashMap$AbstractMapIterator.makeNext(HashMap.java:196)
at java.util.HashMap$KeyIterator.next(HashMap.java:269)
at
java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1017)
[...SNIP...]
Results :
Tests in error:
SharedRecordCompositionTest ? EJBTransactionRolledback nested exception is:
ja...
{code}
was (Author: erce):
Works charming, tested with maven-surefire-plugin-2.15-20130307.043150-1
Tests run: 7, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.688 sec <<<
FAILURE!
selfComposite(com.whitestein.lsps.exec.SharedRecordCompositionTest) Time
elapsed: 2.016 sec <<< ERROR!
javax.ejb.EJBTransactionRolledbackException: nested exception is:
javax.ejb.EJBException: See nested exception; nested exception is:
java.util.ConcurrentModificationException
at
java.util.HashMap$AbstractMapIterator.checkConcurrentMod(HashMap.java:191)
at java.util.HashMap$AbstractMapIterator.makeNext(HashMap.java:196)
at java.util.HashMap$KeyIterator.next(HashMap.java:269)
at
java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1017)
[...SNIP...]
Results :
Tests in error:
SharedRecordCompositionTest ? EJBTransactionRolledback nested exception is:
ja...
> ArrayIndexOutOfBounds in SmartStackTraceParser
> --
>
> Key: SUREFIRE-967
> URL: https://jira.codehaus.org/browse/SUREFIRE-967
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.13
> Environment: *
>Reporter: Rastislav Cesnek
>Assignee: Kristian Rosenvold
> Fix For: 2.15
>
>
> We are testing using JUnit tests against Webshphere 7 aplication server.
> For some whatever strange reason, WebSphere creates an exception chain, in
> which not all exceptions in the chain have a stack trace array filled in. (I
> have heard rumors of JVMs loosing stack traces in exceptions under some
> strange conditions).
> The result is the following exception in Surefire 2.13 (with 2.11, the tests
> pass and report is generated correctly as the exception processing is
> different from 2.13 as I have seen):
> {code}
> [INFO] There was an error in the forked process
> org.apache.maven.surefire.testset.TestSetFailedException:
> java.lang.ArrayIndexOutOfBoundsException: 0; nested exception is
> java.lang.ArrayIndexOutOfBoundsException: 0
> java.lang.ArrayIndexOutOfBoundsException: 0
> at
> org.apache.maven.surefire.report.SmartStackTraceParser.rootIsInclass(SmartStackTraceParser.java:176)
> at
> org.apache.maven.surefire.report.SmartStackTraceParser.getString(SmartStackTraceParser.java:131)
> at
> org.apache.maven.surefire.common.junit4.JUnit4StackTraceWriter.smartTrimmedStackTrace(JUnit4StackTraceWriter.java:73)
> at
> org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:328)
> at
> org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:312)
> at
> org.apache.maven.surefire.booter.ForkingRunListener.toString(ForkingRunListener.java:258)
> at
> org.apache.maven.surefire.booter.ForkingRunListener.testError(ForkingRunListener.java:131)
> at
> org.apache.maven.surefire.common.junit4.JUnit4RunListener.testFailure(JUnit4RunListener.java:111)
> at
> org.junit.runner.notification.RunNotifier$4.notifyListener(RunNotifier.java:100)
> at
> org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:41)
> at
> org.junit.runner.notification.RunNotifier.fireTestFailure(RunNotifier.java:97)
> at
> org.junit.internal.runners.model.EachTestNotifier.addFailure(EachTestNotifier.java:26)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:267)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:69)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:48)
> at org.junit.runne
[jira] (SUREFIRE-967) ArrayIndexOutOfBounds in SmartStackTraceParser
[
https://jira.codehaus.org/browse/SUREFIRE-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321640#comment-321640
]
Rastislav Cesnek commented on SUREFIRE-967:
---
Works charming, tested with maven-surefire-plugin-2.15-20130307.043150-1
Tests run: 7, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.688 sec <<<
FAILURE!
selfComposite(com.whitestein.lsps.exec.SharedRecordCompositionTest) Time
elapsed: 2.016 sec <<< ERROR!
javax.ejb.EJBTransactionRolledbackException: nested exception is:
javax.ejb.EJBException: See nested exception; nested exception is:
java.util.ConcurrentModificationException
at
java.util.HashMap$AbstractMapIterator.checkConcurrentMod(HashMap.java:191)
at java.util.HashMap$AbstractMapIterator.makeNext(HashMap.java:196)
at java.util.HashMap$KeyIterator.next(HashMap.java:269)
at
java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1017)
[...SNIP...]
Results :
Tests in error:
SharedRecordCompositionTest ? EJBTransactionRolledback nested exception is:
ja...
> ArrayIndexOutOfBounds in SmartStackTraceParser
> --
>
> Key: SUREFIRE-967
> URL: https://jira.codehaus.org/browse/SUREFIRE-967
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.13
> Environment: *
>Reporter: Rastislav Cesnek
>Assignee: Kristian Rosenvold
> Fix For: 2.15
>
>
> We are testing using JUnit tests against Webshphere 7 aplication server.
> For some whatever strange reason, WebSphere creates an exception chain, in
> which not all exceptions in the chain have a stack trace array filled in. (I
> have heard rumors of JVMs loosing stack traces in exceptions under some
> strange conditions).
> The result is the following exception in Surefire 2.13 (with 2.11, the tests
> pass and report is generated correctly as the exception processing is
> different from 2.13 as I have seen):
> {code}
> [INFO] There was an error in the forked process
> org.apache.maven.surefire.testset.TestSetFailedException:
> java.lang.ArrayIndexOutOfBoundsException: 0; nested exception is
> java.lang.ArrayIndexOutOfBoundsException: 0
> java.lang.ArrayIndexOutOfBoundsException: 0
> at
> org.apache.maven.surefire.report.SmartStackTraceParser.rootIsInclass(SmartStackTraceParser.java:176)
> at
> org.apache.maven.surefire.report.SmartStackTraceParser.getString(SmartStackTraceParser.java:131)
> at
> org.apache.maven.surefire.common.junit4.JUnit4StackTraceWriter.smartTrimmedStackTrace(JUnit4StackTraceWriter.java:73)
> at
> org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:328)
> at
> org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:312)
> at
> org.apache.maven.surefire.booter.ForkingRunListener.toString(ForkingRunListener.java:258)
> at
> org.apache.maven.surefire.booter.ForkingRunListener.testError(ForkingRunListener.java:131)
> at
> org.apache.maven.surefire.common.junit4.JUnit4RunListener.testFailure(JUnit4RunListener.java:111)
> at
> org.junit.runner.notification.RunNotifier$4.notifyListener(RunNotifier.java:100)
> at
> org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:41)
> at
> org.junit.runner.notification.RunNotifier.fireTestFailure(RunNotifier.java:97)
> at
> org.junit.internal.runners.model.EachTestNotifier.addFailure(EachTestNotifier.java:26)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:267)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:69)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:48)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMe
[jira] (MWAR-280) Big performance hit in overlay
[
https://jira.codehaus.org/browse/MWAR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321631#comment-321631
]
Simone Bordet commented on MWAR-280:
-
Version 2.3 is still affected by this bug.
Any takers ?
> Big performance hit in overlay
> --
>
> Key: MWAR-280
> URL: https://jira.codehaus.org/browse/MWAR-280
> Project: Maven 2.x WAR Plugin
> Issue Type: Bug
> Components: overlay
>Affects Versions: 2.2
>Reporter: Simone Bordet
>
> Here is the output of version 2.1.1 of the maven war plugin when overlaying
> org.cometd.javascript:cometd-javascript-dojo:
> {code}
> [INFO] --- maven-war-plugin:2.1.1:war (default-war) @ tutorials-skeleton ---
> [INFO] Packaging webapp
> [INFO] Assembling webapp [tutorials-skeleton] in
> [/home/simon/opensource/cometd/tutorials-skeleton/target/tutorials-skeleton-1.0.0-SNAPSHOT]
> [INFO] Processing war project
> [INFO] Copying webapp resources
> [/home/simon/opensource/cometd/tutorials-skeleton/src/main/webapp]
> [INFO] Processing overlay [ id org.cometd.javascript:cometd-javascript-dojo]
> [INFO] Webapp assembled in [7026 msecs]
> {code}
> Note how it took 7026 ms.
> This is the output for the same project, but using version 2.2 of the maven
> war plugin:
> {code}
> [INFO] --- maven-war-plugin:2.2:war (default-war) @ tutorials-skeleton ---
> [INFO] Packaging webapp
> [INFO] Assembling webapp [tutorials-skeleton] in
> [/home/simon/opensource/cometd/tutorials-skeleton/target/tutorials-skeleton-1.0.0-SNAPSHOT]
> [INFO] Processing war project
> [INFO] Copying webapp resources
> [/home/simon/opensource/cometd/tutorials-skeleton/src/main/webapp]
> [INFO] Processing overlay [ id org.cometd.javascript:cometd-javascript-dojo]
> [INFO] Webapp assembled in [24151 msecs]
> {code}
> Note how it took 24151 ms, i.e. a 3-4 times performance hit.
--
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] (MCOMPILER-201) [Regression] Compilation fails due to ignored compiler argument
[
https://jira.codehaus.org/browse/MCOMPILER-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Schaible closed MCOMPILER-201.
---
Resolution: Not A Bug
The problem is a result of the new behavior in version 3.0 to use the tools.jar
of the JDK instead of the native compiler. The usage of javac can now be forced
with the new option forceJavacCompilerUse, which allows the IT to pass.
> [Regression] Compilation fails due to ignored compiler argument
> ---
>
> Key: MCOMPILER-201
> URL: https://jira.codehaus.org/browse/MCOMPILER-201
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.0
>Reporter: Jörg Schaible
> Attachments: compilerArgs-it.tb2
>
>
> With compiler plugin 2.5.1 we can configure the Sun/Oracle compiler with
> {noformat}
>
>
>
> {noformat}
> to support internal classes, in our case constants from
> com.sun.xml.internal.ws.developer.JAXWSProperties.
> Since compiler version 3.0, the compilation fails, the symbol is no longer
> found. Same for the upcoming 3.1 in the stage area even if we use the new
> configuration syntax:
> {noformat}
>
> -XDignore.symbol.file
>
> {noformat}
> Since we can see with Maven's debug output that the argument is formally
> detected, the bug could be actually a problem of the newer plexus-compiler
> dependencies (1.9.1 vs. 2.0).
> IT attached.
--
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] (MCOMPILER-201) [Regression] Compilation fails due to ignored compiler argument
Jörg Schaible created MCOMPILER-201:
---
Summary: [Regression] Compilation fails due to ignored compiler
argument
Key: MCOMPILER-201
URL: https://jira.codehaus.org/browse/MCOMPILER-201
Project: Maven 2.x Compiler Plugin
Issue Type: Bug
Affects Versions: 3.0
Reporter: Jörg Schaible
Attachments: compilerArgs-it.tb2
With compiler plugin 2.5.1 we can configure the Sun/Oracle compiler with
{noformat}
{noformat}
to support internal classes, in our case constants from
com.sun.xml.internal.ws.developer.JAXWSProperties.
Since compiler version 3.0, the compilation fails, the symbol is no longer
found. Same for the upcoming 3.1 in the stage area even if we use the new
configuration syntax:
{noformat}
-XDignore.symbol.file
{noformat}
Since we can see with Maven's debug output that the argument is formally
detected, the bug could be actually a problem of the newer plexus-compiler
dependencies (1.9.1 vs. 2.0).
IT attached.
--
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
