Recently, TestNG produced a new release, 5.12. This release is now in the central repository, though under the version 5.12.1 (more on that below).
http://repo1.maven.org/maven2/org/testng/testng/5.12.1/
Upgrading to 5.12.1
If you’ve been using TestNG with Maven, or are familiar with the changes in TestNG 5.12, you’ll notice there is a difference in this version to previous releases. There is no longer a jdk14 and jdk15 variant of the JAR – with the JDK 1.4 javadoc-style annotations no longer supported, there is just the single TestNG JAR. This means that previous versions using ranges will not automatically upgrade, which is expected given the compatibility change.
Where you might previously have had this in your POM:
<dependency> <groupId>org.testng</groupId> <artifactId>testng</artifactId> <version>5.11</version> <classifier>jdk15</classifier> <scope>test</scope> </dependency>
You can now simply use this:
<dependency> <groupId>org.testng</groupId> <artifactId>testng</artifactId> <version>5.12.1</version> <scope>test</scope> </dependency>
No other changes should be necessary.
Guice users should be aware that TestNG now depends on Guice 2.0, and bundles the classes in the JAR. Consequently, Guice is listed as a provided dependency – I haven’t noticed this causing any conflict as long as you are using the official Guice 1.0 or 2.0 release, but this is something to look out for in the future.
Getting TestNG to Central
Some will wonder why this still took so long, given the TestNG release was about a month ago.
Firstly, the library had added a dependency on Guice, and removed a dependency on QDox. This required updates to the POM that were not present in the released bundle. As an Ant-built project, the TestNG POM needs to be maintained separately.
Secondly, Cedric very patiently obliged with several requirements to make it easier for Maven releases in future – in particular, the bundle now includes GPG signatures.
Finally, it turned out that there had been a problem in producing the original distribution, leading to a discrepancy between the Maven release and the original release. This is the reason that there is now a version 5.12.1 (which will likewise be on testng.org shortly) that corrects the content and aligns the TestNG distribution with the Maven release of the same JAR.
The upshot of all of this is that, while this required some back-and-forth to get everything right, future releases will now be much quicker to process and the potential is there for further automation.
Are you Using TestNG with Maven?
I’ve been using TestNG with Maven for some time now, finding it particularly powerful for handling functional testing with Selenium. If you’re using TestNG with Maven, what do you think of the current support?
Brett Porter 
I use TestNG with Maven all the time and love it, however – one thing that always seems to bite me ( and other people ) is that surefire insists on classes beginning or ending with the word Test – which makes scanning for files easier/faster, but can be rather annoying.
How do you workaround that? Configure a new “includes” parameter, or do you use a TestNG Suite XML file?
Have you tried the build helper plugin? http://mojo.codehaus.org/build-helper-maven-plugin/
Pingback: TestNG anniversary « Otaku, Cedric's weblog
It would be great if surefire could just look for the @Test annotation to find tests.
I use TestNG with Gradle, Maven, Eclipse, IntelliJ IDEA — anywhere where JUnit might be used I use TestNG in preference.
I too find Surefire very irritating, both because of its default rules for what constitutes a test, but also it has a dependency on TestNG 5.7.
I fairly much flip-flop between using “includes” in the POM or a SuiteXML file. Gradle makes the latter much easier as it is inline Groovy not a separate XML file.
I updated my POM to depend on TestNG 5.12.1. For some reason, Eclipse’s m2eclipse plugin is pulling in TestNG 5.0 JDK 1.5 in addition to the appropriate JAR.