[jira] Created: (SUREFIRE-680) Printout Running TestSuite twice times
Printout Running TestSuite twice times
--
Key: SUREFIRE-680
URL: http://jira.codehaus.org/browse/SUREFIRE-680
Project: Maven Surefire
Issue Type: Bug
Components: TestNG support
Affects Versions: 2.7.1
Environment: ubunut
Reporter: Karl Heinz Marbaise
I have a [project|https://github.com/khmarbaise/sapm] which contains Unit Tests
in relationship with TestNG (5.14.6) and the maven surefire plugin (2.7.1)
which produces the following output:
{code}[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile)
@ sapm ---
[INFO] Compiling 15 source files to /home/kama/ws-git/sapm/target/test-classes
[INFO]
[INFO] --- maven-surefire-plugin:2.7.1:test (default-test) @ sapm ---
[INFO] Surefire report directory: /home/kama/ws-git/sapm/target/surefire-reports
---
T E S T S
---
Running TestSuite
Running TestSuite
Tests run: 225, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.332 sec
Results :
Tests run: 225, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 7.053s
[INFO] Finished at: Mon Jan 03 10:31:32 CET 2011
[INFO] Final Memory: 22M/147M
[INFO]
{code}
There you can see the doubled Running TestSuite. I have checked that against
maven-surefire plugin (version 2.6) which produces the same output except the
double Running TestSuite.
--
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: (SUREFIRE-680) Printout Running TestSuite twice times
[
http://jira.codehaus.org/browse/SUREFIRE-680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=250260#action_250260
]
Karl Heinz Marbaise commented on SUREFIRE-680:
--
What i missed is that the above happens with Maven 3.0.1 as well as Maven 2.2.1
Printout Running TestSuite twice times
--
Key: SUREFIRE-680
URL: http://jira.codehaus.org/browse/SUREFIRE-680
Project: Maven Surefire
Issue Type: Bug
Components: TestNG support
Affects Versions: 2.7.1
Environment: ubunut
Reporter: Karl Heinz Marbaise
I have a [project|https://github.com/khmarbaise/sapm] which contains Unit
Tests in relationship with TestNG (5.14.6) and the maven surefire plugin
(2.7.1) which produces the following output:
{code}[INFO] --- maven-compiler-plugin:2.3.2:testCompile
(default-testCompile) @ sapm ---
[INFO] Compiling 15 source files to /home/kama/ws-git/sapm/target/test-classes
[INFO]
[INFO] --- maven-surefire-plugin:2.7.1:test (default-test) @ sapm ---
[INFO] Surefire report directory:
/home/kama/ws-git/sapm/target/surefire-reports
---
T E S T S
---
Running TestSuite
Running TestSuite
Tests run: 225, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.332 sec
Results :
Tests run: 225, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 7.053s
[INFO] Finished at: Mon Jan 03 10:31:32 CET 2011
[INFO] Final Memory: 22M/147M
[INFO]
{code}
There you can see the doubled Running TestSuite. I have checked that
against maven-surefire plugin (version 2.6) which produces the same output
except the double Running TestSuite.
--
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: (SUREFIRE-680) Printout Running TestSuite twice times
[
http://jira.codehaus.org/browse/SUREFIRE-680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=250260#action_250260
]
Karl Heinz Marbaise edited comment on SUREFIRE-680 at 1/3/11 3:58 AM:
--
What i missed is that the above happens with Maven 3.0.1 as well as Maven
2.2.1. The above output was produced by calling mvn clean test.
was (Author: khmarbaise):
What i missed is that the above happens with Maven 3.0.1 as well as Maven
2.2.1
Printout Running TestSuite twice times
--
Key: SUREFIRE-680
URL: http://jira.codehaus.org/browse/SUREFIRE-680
Project: Maven Surefire
Issue Type: Bug
Components: TestNG support
Affects Versions: 2.7.1
Environment: ubunut
Reporter: Karl Heinz Marbaise
I have a [project|https://github.com/khmarbaise/sapm] which contains Unit
Tests in relationship with TestNG (5.14.6) and the maven surefire plugin
(2.7.1) which produces the following output:
{code}[INFO] --- maven-compiler-plugin:2.3.2:testCompile
(default-testCompile) @ sapm ---
[INFO] Compiling 15 source files to /home/kama/ws-git/sapm/target/test-classes
[INFO]
[INFO] --- maven-surefire-plugin:2.7.1:test (default-test) @ sapm ---
[INFO] Surefire report directory:
/home/kama/ws-git/sapm/target/surefire-reports
---
T E S T S
---
Running TestSuite
Running TestSuite
Tests run: 225, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.332 sec
Results :
Tests run: 225, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 7.053s
[INFO] Finished at: Mon Jan 03 10:31:32 CET 2011
[INFO] Final Memory: 22M/147M
[INFO]
{code}
There you can see the doubled Running TestSuite. I have checked that
against maven-surefire plugin (version 2.6) which produces the same output
except the double Running TestSuite.
--
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: (MCHANGES-213) Update Velocity 1.7
Update Velocity 1.7 --- Key: MCHANGES-213 URL: http://jira.codehaus.org/browse/MCHANGES-213 Project: Maven 2.x Changes Plugin Issue Type: Improvement Affects Versions: 2.3 Environment: jdk 6, maven 2.2.1 Reporter: Bruno Marti whats about with updating to velocity 1.7 -- 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: (SUREFIRE-681) Add timestamp when each test is run in the generated report
Add timestamp when each test is run in the generated report
---
Key: SUREFIRE-681
URL: http://jira.codehaus.org/browse/SUREFIRE-681
Project: Maven Surefire
Issue Type: Improvement
Reporter: Viggo Navarsete
We run integration tests using maven-surefire-plugin by filtering on the names
(they end with *TestIntegration). These tests access a JBoss server, and leave
log entires in the server log. When a test fail, it would be great to have a
timestamp on each test in the test report from surefire so that it can be
matched against what is happening in the server log. This is especially true
when you have a lot of integration tests running and you can't directly spot
the server log entries related to the failing test. By adding a timestamp to
the tests it would make it MUCH easier to figure out the server log dependent
calls.
Current output:
{noformat]
---
Test set: com.tracetracker.gqi3.QueryRestTestIntegration
---
Tests run: 17, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.546 sec
FAILURE!
testSimpleEventQueryRecordTime(com.tracetracker.gqi3.QueryRestTestIntegration)
Time elapsed: 0.031 sec FAILURE!
junit.framework.AssertionFailedError: List of recordTime should not be empty
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at
com.tracetracker.gqi3.QueryRestTestIntegration.testSimpleEventQueryRecordTime(QueryRestTestIntegration.java:283)
{noformat}
Each failing test should have the timestamp added to the start of the line.
--
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] Closed: (MNG-4955) [regression] Outdated remote snapshots are preferred over locally installed snapshots
[
http://jira.codehaus.org/browse/MNG-4955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4955.
--
Resolution: Fixed
Fix Version/s: 3.0.2
Assignee: Benjamin Bentmann
Fixed in [r1054651|http://svn.apache.org/viewvc?view=revisionrevision=1054651].
[regression] Outdated remote snapshots are preferred over locally installed
snapshots
-
Key: MNG-4955
URL: http://jira.codehaus.org/browse/MNG-4955
Project: Maven 2 3
Issue Type: Bug
Components: Artifacts and Repositories, Dependencies
Affects Versions: 3.0.1
Reporter: Benjamin Bentmann
Assignee: Benjamin Bentmann
Fix For: 3.0.2
When using the new metadata format, remote snapshots listed by locally cached
{{maven-metadata-*.xml}} will always be selected regardless of their relative
age compared to any locally installed snapshots. To repro:
a) mvn deploy lib-a
b) wait a few seconds
c) mvn install lib-a, this creates a local snapshot that is newer than the
remote snapshot
d) in a dependent project lib-b, mvn compile -U
The -U flag to enforce metadata download is rather crucial as otherwise the
feature introduced for MNG-4326 hides the defect.
Besides the expected download of the remote metadata, Maven erroneously also
downloads/uses the outdated remote snapshots.
--
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] Closed: (MNG-4952) [regression] RELEASE field of repository metadata is not updated upon repeated deployments
[ http://jira.codehaus.org/browse/MNG-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4952. -- Resolution: Fixed Fix Version/s: 3.0.2 Assignee: Benjamin Bentmann Fixed in [r1054683|http://svn.apache.org/viewvc?view=revisionrevision=1054683]. [regression] RELEASE field of repository metadata is not updated upon repeated deployments -- Key: MNG-4952 URL: http://jira.codehaus.org/browse/MNG-4952 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0.1 Reporter: Benjamin Bentmann Assignee: Benjamin Bentmann Fix For: 3.0.2 As reported by [Marcin Kuthan on the user list|http://www.mail-archive.com/users@maven.apache.org/msg115404.html], the g:a-level metadata's release field is not updated upon redeployments, i.e. the value is stuck at its initial value. -- 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] Closed: (MNG-4933) With a resource directory as . maven raise an java.lang.StringIndexOutOfBoundsException:217
[ http://jira.codehaus.org/browse/MNG-4933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4933. -- Resolution: Fixed Fix Version/s: 3.0.2 Assignee: Benjamin Bentmann Fixed in [r1054712|http://svn.apache.org/viewvc?view=revisionrevision=1054712]. Interestingly, Maven 2.2.1 doesn't yield this exact error but produces an invalid release-pom.xml which fails the Release Plugin as well. With a resource directory as . maven raise an java.lang.StringIndexOutOfBoundsException:217 --- Key: MNG-4933 URL: http://jira.codehaus.org/browse/MNG-4933 Project: Maven 2 3 Issue Type: Bug Affects Versions: 3.0.1 Environment: $ mvn --version Apache Maven 3.0.1 (r1038046; 2010-11-23 11:58:32+0100) Java version: 1.6.0_21 Java home: D:\java\jdk1.6.0_21\jre Default locale: fr_FR, platform encoding: Cp1252 OS name: windows xp version: 5.1 arch: x86 Family: windows Reporter: Stephane Chomat Assignee: Benjamin Bentmann Fix For: 3.0.2 I exexute a release:prepare-with-pom I debug this execution and I found when the directory is equal to basedir.getPath() an exception is raised. And I have this definition in my pom.xml resource directory./directory includes includeplugin.xml/include includeplugin.properties/include includeicons/**/include /includes /resource Trace: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.1.1:prepare-with-pom (default-cli) on project servicelayer: Execution default-cli of goal org.apache.maven.plugins:maven-release-plugin:2.1.1:prepare-with-pom failed: String index out of range: -1 - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.1.1:prepare-with-pom (default-cli) on project servicelayer: Execution default-cli of goal org.apache.maven.plugins:maven-release-plugin:2.1.1:prepare-with-pom failed: String index out of range: -1 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:211) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140) 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:316) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188) at org.apache.maven.cli.MavenCli.main(MavenCli.java:134) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) 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.PluginExecutionException: Execution default-cli of goal org.apache.maven.plugins:maven-release-plugin:2.1.1:prepare-with-pom failed: String index out of range: -1 at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:116) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195) ... 19 more Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1937) at java.lang.String.substring(String.java:1904) at org.apache.maven.project.path.DefaultPathTranslator.unalignFromBaseDirectory(DefaultPathTranslator.java:217) at org.apache.maven.project.path.DefaultPathTranslator.unalignFromBaseDirectory(DefaultPathTranslator.java:181) at
[jira] Created: (MNG-4957) Emit validation warning when project version uses irregular SNAPSHOT version string
Emit validation warning when project version uses irregular SNAPSHOT version
string
---
Key: MNG-4957
URL: http://jira.codehaus.org/browse/MNG-4957
Project: Maven 2 3
Issue Type: Task
Components: POM
Affects Versions: 3.0.1
Reporter: Benjamin Bentmann
Priority: Trivial
As per discussions around MNG-4893 and [Cleanup to SNAPSHOT version
handling|http://www.mail-archive.com/dev@maven.apache.org/msg86634.html], we
want to establisch {{\*-SNAPSHOT}} as the only valid format for snapshot
versioning. To communicate this to users that currently use {{SNAPSHOT}} or
{{\*.SNAPSHOT}}, we need to emit a model warning for projects using any of the
deprecated forms.
--
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] Updated: (SUREFIRE-680) Printout Running TestSuite twice times
[
http://jira.codehaus.org/browse/SUREFIRE-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated SUREFIRE-680:
Fix Version/s: 2.7.2
Assignee: Kristian Rosenvold
Printout Running TestSuite twice times
--
Key: SUREFIRE-680
URL: http://jira.codehaus.org/browse/SUREFIRE-680
Project: Maven Surefire
Issue Type: Bug
Components: TestNG support
Affects Versions: 2.7.1
Environment: ubunut
Reporter: Karl Heinz Marbaise
Assignee: Kristian Rosenvold
Fix For: 2.7.2
I have a [project|https://github.com/khmarbaise/sapm] which contains Unit
Tests in relationship with TestNG (5.14.6) and the maven surefire plugin
(2.7.1) which produces the following output:
{code}[INFO] --- maven-compiler-plugin:2.3.2:testCompile
(default-testCompile) @ sapm ---
[INFO] Compiling 15 source files to /home/kama/ws-git/sapm/target/test-classes
[INFO]
[INFO] --- maven-surefire-plugin:2.7.1:test (default-test) @ sapm ---
[INFO] Surefire report directory:
/home/kama/ws-git/sapm/target/surefire-reports
---
T E S T S
---
Running TestSuite
Running TestSuite
Tests run: 225, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.332 sec
Results :
Tests run: 225, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 7.053s
[INFO] Finished at: Mon Jan 03 10:31:32 CET 2011
[INFO] Final Memory: 22M/147M
[INFO]
{code}
There you can see the doubled Running TestSuite. I have checked that
against maven-surefire plugin (version 2.6) which produces the same output
except the double Running TestSuite.
--
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] Closed: (MNG-4957) Emit validation warning when project version uses irregular SNAPSHOT version string
[
http://jira.codehaus.org/browse/MNG-4957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4957.
--
Resolution: Fixed
Fix Version/s: 3.0.2
Assignee: Benjamin Bentmann
Done in [r1054743|http://svn.apache.org/viewvc?view=revisionrevision=1054743]:
{noformat}
[WARNING] 'version' uses an unsupported snapshot version format, should be
'*-SNAPSHOT' instead.
{noformat}
Emit validation warning when project version uses irregular SNAPSHOT version
string
---
Key: MNG-4957
URL: http://jira.codehaus.org/browse/MNG-4957
Project: Maven 2 3
Issue Type: Task
Components: POM
Affects Versions: 3.0.1
Reporter: Benjamin Bentmann
Assignee: Benjamin Bentmann
Priority: Trivial
Fix For: 3.0.2
As per discussions around MNG-4893 and [Cleanup to SNAPSHOT version
handling|http://www.mail-archive.com/dev@maven.apache.org/msg86634.html], we
want to establisch {{\*-SNAPSHOT}} as the only valid format for snapshot
versioning. To communicate this to users that currently use {{SNAPSHOT}} or
{{\*.SNAPSHOT}}, we need to emit a model warning for projects using any of
the deprecated forms.
--
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] Closed: (MNG-4893) [regression] Version x.y.z.SNAPSHOT does not deploy correctly
[
http://jira.codehaus.org/browse/MNG-4893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4893.
--
Resolution: Won't Fix
Fix Version/s: (was: 3.x / Backlog)
Assignee: Benjamin Bentmann
As discussed, going forward {{\*-SNAPSHOT}} is the only snapshot version format
we want to support. A corresponding warning for irregular snapshot versions has
been added as per MNG-4957.
[regression] Version x.y.z.SNAPSHOT does not deploy correctly
-
Key: MNG-4893
URL: http://jira.codehaus.org/browse/MNG-4893
Project: Maven 2 3
Issue Type: Bug
Components: Deployment
Affects Versions: 3.0
Reporter: Paul Gier
Assignee: Benjamin Bentmann
Priority: Critical
When using a version that ends with .SNAPSHOT instead of the usual
-SNAPSHOT, Maven 3.0 changes the project version to the timestamped
version. So 5.2.0.SNAPSHOT becomes something like
5.2.0.20101109.215833-1. A Nexus snapshot repository will reject this
deployment because the version in the directory name does not end with
SNAPSHOT.
I tested that this works in Maven 2.2.1 and Maven 3.0-beta-1, but does not
work in Maven 3.0. The build returns an HTTP 400 error when deploying to
Nexus.
Error from Nexus log
{noformat}
2010-11-09 22:02:23 INFO [1298122354-2147] - o.s.n.p.m.m.M2Repos~ - Storing
of item snapshots:/org/drools
/drools/5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom is
forbidden by Maven Repository
policy. Because snapshots is a SNAPSHOT repository
2010-11-09 22:02:23 ERROR [1298122354-2147] - o.s.n.r.ContentPlex~ - Got
exception during processing
request PUT
http://repository.jboss.org/nexus/content/repositories/snapshots/org/drools/drools
/5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom: Storing of
item snapshots:/org/drools
/drools/5.2.0.20101110.030222-361/drools-5.2.0.20101110.030222-361.pom is
forbidden by Maven Repository
policy. Because snapshots is a SNAPSHOT repository
{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: (SUREFIRE-680) Printout Running TestSuite twice times
[
http://jira.codehaus.org/browse/SUREFIRE-680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=250327#action_250327
]
Kristian Rosenvold commented on SUREFIRE-680:
-
I have uploaded an updated 2.7.2-SNAPSHOT which could be used to verify that
this issue is indeed fixed
Printout Running TestSuite twice times
--
Key: SUREFIRE-680
URL: http://jira.codehaus.org/browse/SUREFIRE-680
Project: Maven Surefire
Issue Type: Bug
Components: TestNG support
Affects Versions: 2.7.1
Environment: ubunut
Reporter: Karl Heinz Marbaise
Assignee: Kristian Rosenvold
Fix For: 2.7.2
I have a [project|https://github.com/khmarbaise/sapm] which contains Unit
Tests in relationship with TestNG (5.14.6) and the maven surefire plugin
(2.7.1) which produces the following output:
{code}[INFO] --- maven-compiler-plugin:2.3.2:testCompile
(default-testCompile) @ sapm ---
[INFO] Compiling 15 source files to /home/kama/ws-git/sapm/target/test-classes
[INFO]
[INFO] --- maven-surefire-plugin:2.7.1:test (default-test) @ sapm ---
[INFO] Surefire report directory:
/home/kama/ws-git/sapm/target/surefire-reports
---
T E S T S
---
Running TestSuite
Running TestSuite
Tests run: 225, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.332 sec
Results :
Tests run: 225, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 7.053s
[INFO] Finished at: Mon Jan 03 10:31:32 CET 2011
[INFO] Final Memory: 22M/147M
[INFO]
{code}
There you can see the doubled Running TestSuite. I have checked that
against maven-surefire plugin (version 2.6) which produces the same output
except the double Running TestSuite.
--
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: (MSITE-537) site:stage-deploy creates wrong directory structure if run from a sub-module
site:stage-deploy creates wrong directory structure if run from a sub-module Key: MSITE-537 URL: http://jira.codehaus.org/browse/MSITE-537 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: inheritance, multi module, site:deploy Affects Versions: 2.2 Reporter: Lukas Theussl On a simple multi-module project with one parent and one child, site:deploy creates a directory structure like parent/child/ at the target location. If you run site:deploy from the child module, it gets deployed to parent/child/ which is correct. OTOH site:stage-deploy creates parent/staging/child if run from the parent project, but from the child project it creates parent/child/staging. It should be parent/staging/child. -- 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] Updated: (MSITE-361) Site:stage should have file include/exclude options
[ http://jira.codehaus.org/browse/MSITE-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated MSITE-361: Component/s: site:stage(-deploy) Site:stage should have file include/exclude options --- Key: MSITE-361 URL: http://jira.codehaus.org/browse/MSITE-361 Project: Maven 2.x and 3.x Site Plugin Issue Type: Improvement Components: site:deploy, site:stage(-deploy) Affects Versions: 2.0-beta-6 Environment: JDK 1.5 for Windows Reporter: Ben Speiser The site:stage goal moves a set of files that are designated as generated content to the staging area. However, this doesn't provide any flexibility to include additional generated content or exclude certain generated content, such as generated Cobertura XML files. The Maven Site Plugin should have an option to configure additional includes and excludes for when content is staged. Presumably, site:deploy and site:stage-deploy have the same problem; although I have not tested it. Certainly no include/exclude options are present in the plugin documentation. -- 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] Updated: (MSITE-405) Having distributionManagement repository url with dav protocol, result to corrupt staging directory structure
[ http://jira.codehaus.org/browse/MSITE-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated MSITE-405: Component/s: site:stage(-deploy) Having distributionManagement repository url with dav protocol, result to corrupt staging directory structure - Key: MSITE-405 URL: http://jira.codehaus.org/browse/MSITE-405 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: site:stage(-deploy) Affects Versions: 2.0 Environment: windows XP Reporter: Albert Kurucz distributionManagement !-- this is where binaries are deployed -- repository idcodehaus.org/id nameJTStand Repository/name urldav:https://dav.codehaus.org/repository/jtstand//url /repository !-- NOTE: the uniqueVersion element tells Maven to keep only a single version of a SNAPSHOT -- snapshotRepository idcodehaus.org/id uniqueVersionfalse/uniqueVersion nameJTStand Snapshot Repository/name urldav:https://dav.codehaus.org/snapshots.repository/jtstand//url /snapshotRepository ... site:stage results to: target/staging/https/odehaus.org/jtstand ... The odehaus is not a typo here, I think this is the bug. -- 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
