[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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=revision&revision=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=revision&revision=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=revision&revision=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 > > . > > plugin.xml > plugin.properties > icons/** > > > 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 > org.apache.maven.shared.r
[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=revision&revision=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] Closed: (SUREFIRE-519) junit-dep 4.4+ isn't detected - transitive dependency to JUnit-3.x causes POJO-test treatment
[ http://jira.codehaus.org/browse/SUREFIRE-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-519. --- Resolution: Fixed Fix Version/s: 2.7.2 Assignee: Kristian Rosenvold Fixed with testcase update in r1054768 > junit-dep 4.4+ isn't detected - transitive dependency to JUnit-3.x causes > POJO-test treatment > - > > Key: SUREFIRE-519 > URL: http://jira.codehaus.org/browse/SUREFIRE-519 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.4.3 > Environment: $ mvn --version > Maven version: 2.0.9 > Java version: 1.6.0_07 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Henrik Kaipe >Assignee: Kristian Rosenvold > Fix For: 2.7.2 > > Attachments: junitdep45-and-transitive-junit3-dependency.zip, > surefire519-fix-and-test.patch > > > Have a dependency to junit-dep version 4.4 or later and a transitive or > optional dependency to junit-3.8.1 and suddenly the fix for SUREFIRE-378 has > been deceived. Your JUnit4 tests will again be executed as if they were > POJO-tests. > The attached maven-project reveals 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
[jira] Commented: (SUREFIRE-680) Printout Running TestSuite twice times
[
http://jira.codehaus.org/browse/SUREFIRE-680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > > > > > codehaus.org > JTStand Repository > dav:https://dav.codehaus.org/repository/jtstand/ > > > > codehaus.org > false > JTStand Snapshot Repository > > dav:https://dav.codehaus.org/snapshots.repository/jtstand/ > > ... > 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
