[jira] [Commented] (SUREFIRE-1245) Unable to run TestNG tests using maven surefire plugin.
[
https://issues.apache.org/jira/browse/SUREFIRE-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15502267#comment-15502267
]
Julien Herr commented on SUREFIRE-1245:
---
Tibor, what do you mean by "hidden in testng"?
As I understand the problem now, everything works well (testng tests run by
surefire or failsafe) except with surefire on mac.
I suppose it is working with other runners like ide or command line or gradle.
Hermanth, could you try some other runners and provide the results ?
> Unable to run TestNG tests using maven surefire plugin.
> ---
>
> Key: SUREFIRE-1245
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1245
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Hemanth
>Assignee: Tibor Digana
>Priority: Blocker
> Attachments: pom.xml, testng.xml
>
>
> I am having testng.xml with around 8 classes. The suite will be running fine
> but suddenly stops working and gives me unreachable browser exception. The
> same tests finishes off its execution using failsafe plugin like a charm, but
> my reporting tool is kind of dependent on the surefire plugin. Running it by
> testng.xml(Right clicking and clicking on run as testng suite is working fine
> as well). If there is any mistake that I have done in the pom.xml please help
> me out as well. Please look into this issue.
> Here is a testng.xml
>
> http://testng.org/testng-1.0.dtd;>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Here is my pom.xml
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
>
> ETNA
> inhouse.NewStandardEcommerceTemplate
> 1.0-SNAPSHOT
>
> 1.8
> 1.5.0.RC2
> 1.8.5
> 2.53.0
> 1.7.7
>
> ETNA
> New standard ecommerce template
>
>
> com.fasterxml.jackson.core
> jackson-databind
> 2.7.0
>
>
>
> com.pojosontheweb
> monte-repack
> 1.0
>
>
> org.testng
> testng
> 6.9.10
> test
>
>
>
>
> com.jayway.restassured
> rest-assured
> 2.9.0
>
>
> org.seleniumhq.selenium
> selenium-firefox-driver
> ${version.selenium}
>
>
>
>
> org.apache.poi
> poi
> 3.13
>
>
>
> org.apache.poi
> poi-ooxml
> 3.13
>
>
> org.apache.poi
> poi-ooxml-schemas
> 3.13
>
>
>
> org.zeroturnaround
> zt-zip
> 1.7
>
>
>
> javax.mail
> mail
> 1.4.7
>
>
>
>
> org.seleniumhq.selenium
> selenium-java
> ${version.selenium}
> test
>
>
>
> org.seleniumhq.selenium
> selenium-server
> ${version.selenium}
>
>
>
>
> ru.yandex.qatools.allure
> allure-testng-adaptor
> ${allure.version}
>
>
> junit
> junit
>
>
>
>
>
> org.hamcrest
> hamcrest-all
> 1.3
>
>
>
> com.google.code.gson
> gson
> 2.3.1
>
>
>
> org.slf4j
> slf4j-api
> ${version.slf4j}
> test
>
>
>
> org.slf4j
> slf4j-log4j12
> ${version.slf4j}
> test
>
>
>
> org.slf4j
> jul-to-slf4j
> ${version.slf4j}
> test
>
>
>
> org.slf4j
> jcl-over-slf4j
> ${version.slf4j}
> test
>
>
>
>
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.1
>
> ${compiler.version}
> ${compiler.version}
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
>
>testng.xml
>
>
>
> -javaagent:${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar
>
[jira] [Commented] (SUREFIRE-1262) Add modulepath support
[
https://issues.apache.org/jira/browse/SUREFIRE-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15502020#comment-15502020
]
Tibor Digana commented on SUREFIRE-1262:
[~rfscholte]
I am removing it from release Version {{2.19.2}} as there can be a nice bunch
of questions around Java 9 compatibility.
As for instance reworking CLI, executing in-plugin process,
additional-classpath and modules inside, extracting additional JAR files and
filtering tests only for appropriate java9 module, scanning module within
{{target/test-classes}}, configuring selected modules via Mojo parameter,
combining modules in {{-Dtest= patterns}}, Test List Processor planned in
Version {{3.0}}.
> Add modulepath support
> --
>
> Key: SUREFIRE-1262
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1262
> Project: Maven Surefire
> Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Tibor Digana
> Fix For: Backlog
>
>
> With the Jigsaw project Java9 is extended with a modulepath. This means that
> surefire should be executed in a different way.
> When working with a modulepath, the Classpath in the MANIFEST of the
> executable jar will be ignored, you need need to add everything on
> commandline.
> Just like javadoc, the java executable has an {{@}} option, where you
> can add arguments per line. So this is the new preferred way to build the
> module-path.
> IIUC for surefire it is important to add {{-Xpatch target/test-classes}}
> which makes it possible to use the same packages as target/classes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1262) Add modulepath support
[
https://issues.apache.org/jira/browse/SUREFIRE-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1262:
---
Fix Version/s: (was: 2.19.2)
Backlog
> Add modulepath support
> --
>
> Key: SUREFIRE-1262
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1262
> Project: Maven Surefire
> Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Tibor Digana
> Fix For: Backlog
>
>
> With the Jigsaw project Java9 is extended with a modulepath. This means that
> surefire should be executed in a different way.
> When working with a modulepath, the Classpath in the MANIFEST of the
> executable jar will be ignored, you need need to add everything on
> commandline.
> Just like javadoc, the java executable has an {{@}} option, where you
> can add arguments per line. So this is the new preferred way to build the
> module-path.
> IIUC for surefire it is important to add {{-Xpatch target/test-classes}}
> which makes it possible to use the same packages as target/classes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1245) Unable to run TestNG tests using maven surefire plugin.
[
https://issues.apache.org/jira/browse/SUREFIRE-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15502004#comment-15502004
]
Tibor Digana commented on SUREFIRE-1245:
[~hemanth.BS]
Can you rewrite {{TestSuite}} to JUnit?
The execution will be more under control of surefire because now it is hidden
in TestNG.
> Unable to run TestNG tests using maven surefire plugin.
> ---
>
> Key: SUREFIRE-1245
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1245
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Hemanth
>Assignee: Tibor Digana
>Priority: Blocker
> Attachments: pom.xml, testng.xml
>
>
> I am having testng.xml with around 8 classes. The suite will be running fine
> but suddenly stops working and gives me unreachable browser exception. The
> same tests finishes off its execution using failsafe plugin like a charm, but
> my reporting tool is kind of dependent on the surefire plugin. Running it by
> testng.xml(Right clicking and clicking on run as testng suite is working fine
> as well). If there is any mistake that I have done in the pom.xml please help
> me out as well. Please look into this issue.
> Here is a testng.xml
>
> http://testng.org/testng-1.0.dtd;>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Here is my pom.xml
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
>
> ETNA
> inhouse.NewStandardEcommerceTemplate
> 1.0-SNAPSHOT
>
> 1.8
> 1.5.0.RC2
> 1.8.5
> 2.53.0
> 1.7.7
>
> ETNA
> New standard ecommerce template
>
>
> com.fasterxml.jackson.core
> jackson-databind
> 2.7.0
>
>
>
> com.pojosontheweb
> monte-repack
> 1.0
>
>
> org.testng
> testng
> 6.9.10
> test
>
>
>
>
> com.jayway.restassured
> rest-assured
> 2.9.0
>
>
> org.seleniumhq.selenium
> selenium-firefox-driver
> ${version.selenium}
>
>
>
>
> org.apache.poi
> poi
> 3.13
>
>
>
> org.apache.poi
> poi-ooxml
> 3.13
>
>
> org.apache.poi
> poi-ooxml-schemas
> 3.13
>
>
>
> org.zeroturnaround
> zt-zip
> 1.7
>
>
>
> javax.mail
> mail
> 1.4.7
>
>
>
>
> org.seleniumhq.selenium
> selenium-java
> ${version.selenium}
> test
>
>
>
> org.seleniumhq.selenium
> selenium-server
> ${version.selenium}
>
>
>
>
> ru.yandex.qatools.allure
> allure-testng-adaptor
> ${allure.version}
>
>
> junit
> junit
>
>
>
>
>
> org.hamcrest
> hamcrest-all
> 1.3
>
>
>
> com.google.code.gson
> gson
> 2.3.1
>
>
>
> org.slf4j
> slf4j-api
> ${version.slf4j}
> test
>
>
>
> org.slf4j
> slf4j-log4j12
> ${version.slf4j}
> test
>
>
>
> org.slf4j
> jul-to-slf4j
> ${version.slf4j}
> test
>
>
>
> org.slf4j
> jcl-over-slf4j
> ${version.slf4j}
> test
>
>
>
>
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.1
>
> ${compiler.version}
> ${compiler.version}
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
>
>testng.xml
>
>
>
> -javaagent:${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar
>
>
>
>
> org.aspectj
> aspectjweaver
>
[jira] [Updated] (SUREFIRE-1281) Fix permanently failing Surefire Windows Build
[ https://issues.apache.org/jira/browse/SUREFIRE-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1281: --- Description: 1. https://builds.apache.org/job/maven-surefire-windows/org.apache.maven.surefire$surefire-integration-tests/1134/ Error Message time for successful test is expected to be positive Stacktrace java.lang.AssertionError: time for successful test is expected to be positive at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.assertTrue(Assert.java:41) at org.apache.maven.surefire.its.jiras.Surefire943ReportContentIT.validate(Surefire943ReportContentIT.java:132) at org.apache.maven.surefire.its.jiras.Surefire943ReportContentIT.doTest(Surefire943ReportContentIT.java:69) at org.apache.maven.surefire.its.jiras.Surefire943ReportContentIT.test_noParallel(Surefire943ReportContentIT.java:39) 2. https://builds.apache.org/job/maven-surefire-windows/1142/org.apache.maven.surefire$surefire-integration-tests/testReport/org.apache.maven.surefire.its/ForkModeTestNGIT/testForkModeOncePerThreadTwoThreads/ Failed org.apache.maven.surefire.its.ForkModeTestNGIT.testForkModeOncePerThreadTwoThreads Error Message number of different pids is not as expected expected:<2> but was:<1> Stacktrace java.lang.AssertionError: number of different pids is not as expected expected:<2> but was:<1> at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:645) at org.apache.maven.surefire.its.ForkModeIT.assertDifferentPids(ForkModeIT.java:171) at org.apache.maven.surefire.its.ForkModeIT.testForkModeOncePerThreadTwoThreads(ForkModeIT.java:105) was: https://builds.apache.org/job/maven-surefire-windows/org.apache.maven.surefire$surefire-integration-tests/1134/ Error Message time for successful test is expected to be positive Stacktrace java.lang.AssertionError: time for successful test is expected to be positive at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.assertTrue(Assert.java:41) at org.apache.maven.surefire.its.jiras.Surefire943ReportContentIT.validate(Surefire943ReportContentIT.java:132) at org.apache.maven.surefire.its.jiras.Surefire943ReportContentIT.doTest(Surefire943ReportContentIT.java:69) at org.apache.maven.surefire.its.jiras.Surefire943ReportContentIT.test_noParallel(Surefire943ReportContentIT.java:39) > Fix permanently failing Surefire Windows Build > -- > > Key: SUREFIRE-1281 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1281 > Project: Maven Surefire > Issue Type: Task > Environment: Jenkins >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19.2 > > > 1. > https://builds.apache.org/job/maven-surefire-windows/org.apache.maven.surefire$surefire-integration-tests/1134/ > Error Message > time for successful test is expected to be positive > Stacktrace > java.lang.AssertionError: time for successful test is expected to be positive > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at > org.apache.maven.surefire.its.jiras.Surefire943ReportContentIT.validate(Surefire943ReportContentIT.java:132) > at > org.apache.maven.surefire.its.jiras.Surefire943ReportContentIT.doTest(Surefire943ReportContentIT.java:69) > at > org.apache.maven.surefire.its.jiras.Surefire943ReportContentIT.test_noParallel(Surefire943ReportContentIT.java:39) > 2. > https://builds.apache.org/job/maven-surefire-windows/1142/org.apache.maven.surefire$surefire-integration-tests/testReport/org.apache.maven.surefire.its/ForkModeTestNGIT/testForkModeOncePerThreadTwoThreads/ > Failed > org.apache.maven.surefire.its.ForkModeTestNGIT.testForkModeOncePerThreadTwoThreads > Error Message > number of different pids is not as expected expected:<2> but was:<1> > Stacktrace > java.lang.AssertionError: number of different pids is not as expected > expected:<2> but was:<1> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at > org.apache.maven.surefire.its.ForkModeIT.assertDifferentPids(ForkModeIT.java:171) > at > org.apache.maven.surefire.its.ForkModeIT.testForkModeOncePerThreadTwoThreads(ForkModeIT.java:105) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1281) Fix permanently failing Surefire Windows Build
[ https://issues.apache.org/jira/browse/SUREFIRE-1281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15501992#comment-15501992 ] Tibor Digana commented on SUREFIRE-1281: commit 689291f674061e85d48198acd5ae622da7697e48 > Fix permanently failing Surefire Windows Build > -- > > Key: SUREFIRE-1281 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1281 > Project: Maven Surefire > Issue Type: Task > Environment: Jenkins >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19.2 > > > 1. > https://builds.apache.org/job/maven-surefire-windows/org.apache.maven.surefire$surefire-integration-tests/1134/ > Error Message > time for successful test is expected to be positive > Stacktrace > java.lang.AssertionError: time for successful test is expected to be positive > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at > org.apache.maven.surefire.its.jiras.Surefire943ReportContentIT.validate(Surefire943ReportContentIT.java:132) > at > org.apache.maven.surefire.its.jiras.Surefire943ReportContentIT.doTest(Surefire943ReportContentIT.java:69) > at > org.apache.maven.surefire.its.jiras.Surefire943ReportContentIT.test_noParallel(Surefire943ReportContentIT.java:39) > 2. > https://builds.apache.org/job/maven-surefire-windows/1142/org.apache.maven.surefire$surefire-integration-tests/testReport/org.apache.maven.surefire.its/ForkModeTestNGIT/testForkModeOncePerThreadTwoThreads/ > Failed > org.apache.maven.surefire.its.ForkModeTestNGIT.testForkModeOncePerThreadTwoThreads > Error Message > number of different pids is not as expected expected:<2> but was:<1> > Stacktrace > java.lang.AssertionError: number of different pids is not as expected > expected:<2> but was:<1> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at > org.apache.maven.surefire.its.ForkModeIT.assertDifferentPids(ForkModeIT.java:171) > at > org.apache.maven.surefire.its.ForkModeIT.testForkModeOncePerThreadTwoThreads(ForkModeIT.java:105) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5297) Site should tell 'prerequisites.maven is deprecated'
[ https://issues.apache.org/jira/browse/MNG-5297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15501723#comment-15501723 ] Hudson commented on MNG-5297: - SUCCESS: Integrated in Jenkins build maven-3.x #1374 (See [https://builds.apache.org/job/maven-3.x/1374/]) MNG-5297 improved explanations on prerequisites.maven in Maven 3 (hboutemy: rev 950a90ececca385f60c336814fb8a48c3b42bb54) * (edit) maven-model/src/main/mdo/maven.mdo > Site should tell 'prerequisites.maven is deprecated' > > > Key: MNG-5297 > URL: https://issues.apache.org/jira/browse/MNG-5297 > Project: Maven > Issue Type: Bug > Components: Sites & Reporting >Affects Versions: 3.0.4 >Reporter: Kengo TODA >Assignee: Jason van Zyl >Priority: Minor > Fix For: 3.3.9 > > > MNG-4840 said 'enforcement of the build environment is left to the Maven > Enforcer Plugin'. > http://jira.codehaus.org/browse/MNG-4840?focusedCommentId=253900=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-253900 > But currently, there is no 'deprecated' mark at Maven site. > http://maven.apache.org/ref/3.0.4/maven-model/maven.html#prerequisites > I think site should has 'deprecated' mark like 'reports' element. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MNG-6092) warn if prerequisites.maven used for non-plugin projects
Hervé Boutemy created MNG-6092: -- Summary: warn if prerequisites.maven used for non-plugin projects Key: MNG-6092 URL: https://issues.apache.org/jira/browse/MNG-6092 Project: Maven Issue Type: Wish Reporter: Hervé Boutemy as seen in MNG'4840 and documented in MNG-5297, in Maven 3, prerequisites.maven has a meaning for plugin projects: defining this for non-plugins projects makes feel that it will be checked like it was done in Maven 2, but thisis not the case. Adding a warning could help people avoid this habit taken with Maven 2 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SUREFIRE-1282) Use assumeJavaVersion() in integration tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1282.
--
Resolution: Fixed
commit 3680bff6d25a6858162d919849e5c77887a5b7be
commit 1090a00a45ea0252b3e2c3150b6eaa47c04e4ace
commit f49249ecb877d98477644dcd8a7ab5eba603972c
> Use assumeJavaVersion() in integration tests
>
>
> Key: SUREFIRE-1282
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1282
> Project: Maven Surefire
> Issue Type: Task
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
>
> Use statement
> {{assumeJavaVersion( javaVersion );}}
> instead of
> {{assumeThat( System.getProperty( "java.version" ), is( greaterThanOrEqualTo(
> javaVersion ) ) );}}
> and
> {{assumeThat( "java.specification.version: ", System.getProperty(
> "java.specification.version" ), is( greaterThanOrEqualTo( "1.7" ) ) );}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1278) TestNG tests are run with group name that ends with specified group
[
https://issues.apache.org/jira/browse/SUREFIRE-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15501635#comment-15501635
]
ASF GitHub Bot commented on SUREFIRE-1278:
--
Github user khospodarysko commented on the issue:
https://github.com/apache/maven-surefire/pull/121
@Tibor17 No, I haven't. This is my first such patch. I'm happy it added
more quality to the product!
> TestNG tests are run with group name that ends with specified group
>
>
> Key: SUREFIRE-1278
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1278
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
> Environment: OS X El Capitan 10.11.6
> TestNG 6.9.10
>Reporter: Kostya Hospodarysko
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
> Attachments: testng-groups.zip
>
>
> h4.Preconditions:
> There is a simple TestNG class with two methods so that 1st method has group
> "group" and 2nd has group "apigroup".
> h4.Steps to reproduce:
> Run tests with command:
> {noformat}
> mvn clean test -Dgroups=group
> {noformat}
> {color:red}h4.Actual:{color}
> Both tests are run.
> {color:green}h4.Expected:{color}
> Only method with group "group" is run.
> Demo project could be found here:
> https://github.com/khospodarysko/testng-groups.
> Looks like the issue is in GroupMatcherMethodSelector as looking at
> includeMethod it is seen that is always returns true.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1282) Use assumeJavaVersion() in integration tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15501622#comment-15501622
]
ASF GitHub Bot commented on SUREFIRE-1282:
--
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/120
@britter
I have created Jira issue for this Task
https://issues.apache.org/jira/browse/SUREFIRE-1282
> Use assumeJavaVersion() in integration tests
>
>
> Key: SUREFIRE-1282
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1282
> Project: Maven Surefire
> Issue Type: Task
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
>
> Use statement
> {{assumeJavaVersion( javaVersion );}}
> instead of
> {{assumeThat( System.getProperty( "java.version" ), is( greaterThanOrEqualTo(
> javaVersion ) ) );}}
> and
> {{assumeThat( "java.specification.version: ", System.getProperty(
> "java.specification.version" ), is( greaterThanOrEqualTo( "1.7" ) ) );}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SUREFIRE-1282) Use assumeJavaVersion() in integration tests
Tibor Digana created SUREFIRE-1282:
--
Summary: Use assumeJavaVersion() in integration tests
Key: SUREFIRE-1282
URL: https://issues.apache.org/jira/browse/SUREFIRE-1282
Project: Maven Surefire
Issue Type: Task
Reporter: Tibor Digana
Assignee: Tibor Digana
Fix For: 2.19.2
Use statement
{{assumeJavaVersion( javaVersion );}}
instead of
{{assumeThat( System.getProperty( "java.version" ), is( greaterThanOrEqualTo(
javaVersion ) ) );}}
and
{{assumeThat( "java.specification.version: ", System.getProperty(
"java.specification.version" ), is( greaterThanOrEqualTo( "1.7" ) ) );}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1278) TestNG tests are run with group name that ends with specified group
[
https://issues.apache.org/jira/browse/SUREFIRE-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15501584#comment-15501584
]
ASF GitHub Bot commented on SUREFIRE-1278:
--
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/121
@khospodarysko CI build was successful. This should be normally closed
automatically and sometimes it takes a day but you can close it as well.
Thank you for contributing.
Have you contributed to Maven in more previous pull-requests?
> TestNG tests are run with group name that ends with specified group
>
>
> Key: SUREFIRE-1278
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1278
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
> Environment: OS X El Capitan 10.11.6
> TestNG 6.9.10
>Reporter: Kostya Hospodarysko
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
> Attachments: testng-groups.zip
>
>
> h4.Preconditions:
> There is a simple TestNG class with two methods so that 1st method has group
> "group" and 2nd has group "apigroup".
> h4.Steps to reproduce:
> Run tests with command:
> {noformat}
> mvn clean test -Dgroups=group
> {noformat}
> {color:red}h4.Actual:{color}
> Both tests are run.
> {color:green}h4.Expected:{color}
> Only method with group "group" is run.
> Demo project could be found here:
> https://github.com/khospodarysko/testng-groups.
> Looks like the issue is in GroupMatcherMethodSelector as looking at
> includeMethod it is seen that is always returns true.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1278) TestNG tests are run with group name that ends with specified group
[
https://issues.apache.org/jira/browse/SUREFIRE-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15501548#comment-15501548
]
Hudson commented on SUREFIRE-1278:
--
SUCCESS: Integrated in Jenkins build maven-surefire #1617 (See
[https://builds.apache.org/job/maven-surefire/1617/])
Fix for SUREFIRE-1278 - TestNG tests are run with group name that ends
(tibor17: rev ae6337ea216b867e76e951e09951e475ed105d06)
* (add)
surefire-integration-tests/src/test/resources/surefire-1278-group-name-ending/pom.xml
* (edit)
surefire-grouper/src/main/java/org/apache/maven/surefire/group/match/SingleGroupMatcher.java
* (add)
surefire-integration-tests/src/test/resources/surefire-1278-group-name-ending/src/test/java/pkg/ATest.java
Fix for SUREFIRE-1278 - TestNG tests are run with group name that ends
(tibor17: rev bab3175e8388b675e1e56814d3b1a5aa25ae250a)
* (add)
surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/jiras/Surefire1278GroupNameEndingIT.java
> TestNG tests are run with group name that ends with specified group
>
>
> Key: SUREFIRE-1278
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1278
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
> Environment: OS X El Capitan 10.11.6
> TestNG 6.9.10
>Reporter: Kostya Hospodarysko
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
> Attachments: testng-groups.zip
>
>
> h4.Preconditions:
> There is a simple TestNG class with two methods so that 1st method has group
> "group" and 2nd has group "apigroup".
> h4.Steps to reproduce:
> Run tests with command:
> {noformat}
> mvn clean test -Dgroups=group
> {noformat}
> {color:red}h4.Actual:{color}
> Both tests are run.
> {color:green}h4.Expected:{color}
> Only method with group "group" is run.
> Demo project could be found here:
> https://github.com/khospodarysko/testng-groups.
> Looks like the issue is in GroupMatcherMethodSelector as looking at
> includeMethod it is seen that is always returns true.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SUREFIRE-1278) TestNG tests are run with group name that ends with specified group
[
https://issues.apache.org/jira/browse/SUREFIRE-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1278.
--
Resolution: Fixed
commit ae6337ea216b867e76e951e09951e475ed105d06
commit bab3175e8388b675e1e56814d3b1a5aa25ae250a
> TestNG tests are run with group name that ends with specified group
>
>
> Key: SUREFIRE-1278
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1278
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
> Environment: OS X El Capitan 10.11.6
> TestNG 6.9.10
>Reporter: Kostya Hospodarysko
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
> Attachments: testng-groups.zip
>
>
> h4.Preconditions:
> There is a simple TestNG class with two methods so that 1st method has group
> "group" and 2nd has group "apigroup".
> h4.Steps to reproduce:
> Run tests with command:
> {noformat}
> mvn clean test -Dgroups=group
> {noformat}
> {color:red}h4.Actual:{color}
> Both tests are run.
> {color:green}h4.Expected:{color}
> Only method with group "group" is run.
> Demo project could be found here:
> https://github.com/khospodarysko/testng-groups.
> Looks like the issue is in GroupMatcherMethodSelector as looking at
> includeMethod it is seen that is always returns true.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1278) TestNG tests are run with group name that ends with specified group
[
https://issues.apache.org/jira/browse/SUREFIRE-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15501477#comment-15501477
]
ASF GitHub Bot commented on SUREFIRE-1278:
--
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/121
LGTM.
> TestNG tests are run with group name that ends with specified group
>
>
> Key: SUREFIRE-1278
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1278
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
> Environment: OS X El Capitan 10.11.6
> TestNG 6.9.10
>Reporter: Kostya Hospodarysko
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
> Attachments: testng-groups.zip
>
>
> h4.Preconditions:
> There is a simple TestNG class with two methods so that 1st method has group
> "group" and 2nd has group "apigroup".
> h4.Steps to reproduce:
> Run tests with command:
> {noformat}
> mvn clean test -Dgroups=group
> {noformat}
> {color:red}h4.Actual:{color}
> Both tests are run.
> {color:green}h4.Expected:{color}
> Only method with group "group" is run.
> Demo project could be found here:
> https://github.com/khospodarysko/testng-groups.
> Looks like the issue is in GroupMatcherMethodSelector as looking at
> includeMethod it is seen that is always returns true.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1278) TestNG tests are run with group name that ends with specified group
[
https://issues.apache.org/jira/browse/SUREFIRE-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15501461#comment-15501461
]
ASF GitHub Bot commented on SUREFIRE-1278:
--
Github user khospodarysko commented on the issue:
https://github.com/apache/maven-surefire/pull/121
Followed the analogy and added
org.apache.maven.surefire.its.jiras.Surefire1278GroupNameEndingIT to
src/test/java folder.
Please let me know if something else is wrong and I'll try to fix it asap.
> TestNG tests are run with group name that ends with specified group
>
>
> Key: SUREFIRE-1278
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1278
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
> Environment: OS X El Capitan 10.11.6
> TestNG 6.9.10
>Reporter: Kostya Hospodarysko
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
> Attachments: testng-groups.zip
>
>
> h4.Preconditions:
> There is a simple TestNG class with two methods so that 1st method has group
> "group" and 2nd has group "apigroup".
> h4.Steps to reproduce:
> Run tests with command:
> {noformat}
> mvn clean test -Dgroups=group
> {noformat}
> {color:red}h4.Actual:{color}
> Both tests are run.
> {color:green}h4.Expected:{color}
> Only method with group "group" is run.
> Demo project could be found here:
> https://github.com/khospodarysko/testng-groups.
> Looks like the issue is in GroupMatcherMethodSelector as looking at
> includeMethod it is seen that is always returns true.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1278) TestNG tests are run with group name that ends with specified group
[
https://issues.apache.org/jira/browse/SUREFIRE-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15501359#comment-15501359
]
ASF GitHub Bot commented on SUREFIRE-1278:
--
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/121
@khospodarysko Do you have it in *.bak file or in bytecode in
/target/classes?
> TestNG tests are run with group name that ends with specified group
>
>
> Key: SUREFIRE-1278
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1278
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
> Environment: OS X El Capitan 10.11.6
> TestNG 6.9.10
>Reporter: Kostya Hospodarysko
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
> Attachments: testng-groups.zip
>
>
> h4.Preconditions:
> There is a simple TestNG class with two methods so that 1st method has group
> "group" and 2nd has group "apigroup".
> h4.Steps to reproduce:
> Run tests with command:
> {noformat}
> mvn clean test -Dgroups=group
> {noformat}
> {color:red}h4.Actual:{color}
> Both tests are run.
> {color:green}h4.Expected:{color}
> Only method with group "group" is run.
> Demo project could be found here:
> https://github.com/khospodarysko/testng-groups.
> Looks like the issue is in GroupMatcherMethodSelector as looking at
> includeMethod it is seen that is always returns true.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1278) TestNG tests are run with group name that ends with specified group
[
https://issues.apache.org/jira/browse/SUREFIRE-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15501356#comment-15501356
]
ASF GitHub Bot commented on SUREFIRE-1278:
--
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/121
@khospodarysko Something wrong happened. The IT class is missing.
> TestNG tests are run with group name that ends with specified group
>
>
> Key: SUREFIRE-1278
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1278
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
> Environment: OS X El Capitan 10.11.6
> TestNG 6.9.10
>Reporter: Kostya Hospodarysko
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
> Attachments: testng-groups.zip
>
>
> h4.Preconditions:
> There is a simple TestNG class with two methods so that 1st method has group
> "group" and 2nd has group "apigroup".
> h4.Steps to reproduce:
> Run tests with command:
> {noformat}
> mvn clean test -Dgroups=group
> {noformat}
> {color:red}h4.Actual:{color}
> Both tests are run.
> {color:green}h4.Expected:{color}
> Only method with group "group" is run.
> Demo project could be found here:
> https://github.com/khospodarysko/testng-groups.
> Looks like the issue is in GroupMatcherMethodSelector as looking at
> includeMethod it is seen that is always returns true.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Deleted] (MSHARED-592) Add interface to install a Maven Project
[ https://issues.apache.org/jira/browse/MSHARED-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise deleted MSHARED-592: > Add interface to install a Maven Project > > > Key: MSHARED-592 > URL: https://issues.apache.org/jira/browse/MSHARED-592 > Project: Maven Shared Components > Issue Type: Improvement >Reporter: Karl Heinz Marbaise >Priority: Minor > > It would be a good idea to add an option to install a whole Maven project. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSHARED-592) Add interface to install a Maven Project
[ https://issues.apache.org/jira/browse/MSHARED-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MSHARED-592: > Add interface to install a Maven Project > > > Key: MSHARED-592 > URL: https://issues.apache.org/jira/browse/MSHARED-592 > Project: Maven Shared Components > Issue Type: Improvement >Reporter: Karl Heinz Marbaise >Priority: Minor > > It would be a good idea to add an option to install a whole Maven project. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSHARED-592) Add interface to install a Maven Project
[ https://issues.apache.org/jira/browse/MSHARED-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MSHARED-592: Component/s: (was: maven-artifact-transfer) > Add interface to install a Maven Project > > > Key: MSHARED-592 > URL: https://issues.apache.org/jira/browse/MSHARED-592 > Project: Maven Shared Components > Issue Type: Improvement >Affects Versions: maven-artifact-transfer-3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > > It would be a good idea to add an option to install a whole Maven project. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSHARED-592) Add interface to install a Maven Project
[ https://issues.apache.org/jira/browse/MSHARED-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MSHARED-592: Fix Version/s: (was: maven-artifact-transfer-3.0.0) > Add interface to install a Maven Project > > > Key: MSHARED-592 > URL: https://issues.apache.org/jira/browse/MSHARED-592 > Project: Maven Shared Components > Issue Type: Improvement >Affects Versions: maven-artifact-transfer-3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > > It would be a good idea to add an option to install a whole Maven project. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MSCMPUB-27) Make it possible to publish only subfolders in a targeting site repository
[
https://issues.apache.org/jira/browse/MSCMPUB-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MSCMPUB-27:
---
Summary: Make it possible to publish only subfolders in a targeting site
repository (was: Make it possible to publish ony subfolders in a targeting
site repository)
> Make it possible to publish only subfolders in a targeting site repository
> --
>
> Key: MSCMPUB-27
> URL: https://issues.apache.org/jira/browse/MSCMPUB-27
> Project: Maven SCM Publish Plugin
> Issue Type: Improvement
>Reporter: Karl Heinz Marbaise
>
> Scenario: Having a single git repo which contains the site for a multi
> component project where each component site should be published at a
> different time point.
> {code}
> /
> .. index.html...
> +--- M1
> +--- M2
> +
> {code}
> I can configure to ignore paths like {{M1,M2}} but I can't configure to use a
> target path while the content is being copied into the target site git repos
> to say that only the current content will be copied into {{M1}} and this is
> the only part which is handle with updates/changes/deletes.
> The root path can be handled by using the {{ignorePathsToDelete}}
> configuration but in the sub modules like M1 and M2 it is not possible to
> configure scm-publish in a way to handle only a sub folder.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SCM-833) getLastChangedRevision() returns null whereas as getRevision() get correct versions
[
https://issues.apache.org/jira/browse/SCM-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated SCM-833:
Affects Version/s: 1.9.5
> getLastChangedRevision() returns null whereas as getRevision() get correct
> versions
> ---
>
> Key: SCM-833
> URL: https://issues.apache.org/jira/browse/SCM-833
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-api, maven-scm-provider-jgit
>Affects Versions: 1.9.4, 1.9.5
>Reporter: Karl Heinz Marbaise
>
> Currently there is a method like this in the code (buildnumber-maven-plugin):
> AbstractScmMojo.java:
> {code:java}
> protected String getScmRevision()
> throws ScmException
> {
> ScmRepository repository = getScmRepository();
> InfoScmResult scmResult = info( repository, new ScmFileSet(
> scmDirectory ) );
> if ( scmResult == null || scmResult.getInfoItems().isEmpty() )
> {
> return ( !StringUtils.isEmpty( revisionOnScmFailure ) ) ?
> revisionOnScmFailure : null;
> }
> checkResult( scmResult );
> InfoItem info = scmResult.getInfoItems().get( 0 );
>
> List infoItems = scmResult.getInfoItems();
>
> for (InfoItem infoItem : infoItems) {
> getLog().info("Item: " +infoItem.getRevision() + " lcr: " +
> infoItem.getLastChangedRevision() );
> }
> getLog().info("useLastCommittedRevision: " +
> useLastCommittedRevision);
> if ( useLastCommittedRevision )
> {
> return info.getLastChangedRevision();
> }
> return info.getRevision();
> }
> {code}
> The problem is simply that {{getLastChangedRevision()}} returns null whereas
> {{getRevision()}} returns the requested value?...
> So ATM I'm not sure if this is really a bug in SCM or a misusage in
> buildnumber-maven-plugin ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Deleted] (MSCMPUB-28) Make it possible to publish ony subfolders in a targeting site repository
[
https://issues.apache.org/jira/browse/MSCMPUB-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise deleted MSCMPUB-28:
---
> Make it possible to publish ony subfolders in a targeting site repository
> -
>
> Key: MSCMPUB-28
> URL: https://issues.apache.org/jira/browse/MSCMPUB-28
> Project: Maven SCM Publish Plugin
> Issue Type: Improvement
>Reporter: Karl Heinz Marbaise
>
> Scenario: Having a single git repo which contains the site for a multi
> component project where each component site should be published at a
> different time point.
> {code}
> /
> .. index.html...
> +--- M1
> +--- M2
> +
> {code}
> I can configure to ignore paths like {{M1,M2}} but I can't configure to use a
> target path while the content is being copied into the target site git repos
> to say that only the current content will be copied into {{M1}} and this is
> the only part which is handle with updates/changes/deletes.
> The root path can be handled by using the {{ignorePathsToDelete}}
> configuration but in the sub modules like M1 and M2 it is not possible to
> configure scm-publish in a way to handle only a sub folder.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MSCMPUB-28) Make it possible to publish ony subfolders in a targeting site repository
Karl Heinz Marbaise created MSCMPUB-28:
--
Summary: Make it possible to publish ony subfolders in a targeting
site repository
Key: MSCMPUB-28
URL: https://issues.apache.org/jira/browse/MSCMPUB-28
Project: Maven SCM Publish Plugin
Issue Type: Improvement
Reporter: Karl Heinz Marbaise
Scenario: Having a single git repo which contains the site for a multi
component project where each component site should be published at a different
time point.
{code}
/
.. index.html...
+--- M1
+--- M2
+
{code}
I can configure to ignore paths like {{M1,M2}} but I can't configure to use a
target path while the content is being copied into the target site git repos to
say that only the current content will be copied into {{M1}} and this is the
only part which is handle with updates/changes/deletes.
The root path can be handled by using the {{ignorePathsToDelete}} configuration
but in the sub modules like M1 and M2 it is not possible to configure
scm-publish in a way to handle only a sub folder.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MSCMPUB-27) Make it possible to publish ony subfolders in a targeting site repository
Karl Heinz Marbaise created MSCMPUB-27:
--
Summary: Make it possible to publish ony subfolders in a targeting
site repository
Key: MSCMPUB-27
URL: https://issues.apache.org/jira/browse/MSCMPUB-27
Project: Maven SCM Publish Plugin
Issue Type: Improvement
Reporter: Karl Heinz Marbaise
Scenario: Having a single git repo which contains the site for a multi
component project where each component site should be published at a different
time point.
{code}
/
.. index.html...
+--- M1
+--- M2
+
{code}
I can configure to ignore paths like {{M1,M2}} but I can't configure to use a
target path while the content is being copied into the target site git repos to
say that only the current content will be copied into {{M1}} and this is the
only part which is handle with updates/changes/deletes.
The root path can be handled by using the {{ignorePathsToDelete}} configuration
but in the sub modules like M1 and M2 it is not possible to configure
scm-publish in a way to handle only a sub folder.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
