Tycho/Release Notes/0.26

< Previous Version | Next Version >

New and Noteworthy

Complete list of bug fixes and enhancements in 0.26.0

TestNG support

The Tycho Surefire Plug-in does now support running tests with the TestNG framework. In order to use TestNG you have to:

Provide TestNG as OSGi Bundle

Because TestNG is not an OSGi Bundle, you have to provide the TestNG classes and it's dependencies (currently only com.beust.jcommander) as OSGi bundles by either include the jars into your test plugin and export the TestNG java packages so that the Tycho Surefire Plugin can see them or create a separate Eclipse Plug-in ("Plug-in from Existing JAR Archives" Wizard) that contains the jars. Make sure the TestNG java packages are exported. Add this newly created Plug-in as a dependency to all your Test Plug-ins /Fragments.

Configure Tycho Surefire Plug-in

The TestNG framework provider has to be enabled by setting the <providerHint> configuration value to "testng". Within TestNG tests it is common to use java assertions, so you might also have to enable assertions. Example configuration:

      <build>
           <plugin>
               <groupId>org.eclipse.tycho</groupId>
               <artifactId>tycho-surefire-plugin</artifactId>
               <version>${tycho.version}</version>
               <configuration>
                   <providerHint>testng</providerHint>
                   <argLine>-ea</argLine>
               </configuration>
           </plugin>
      </build>

Using Test Suites

If you want to use test suites you could configure the suite files you want to execute by specifing the suite xml files within the configuration:

      <build>
           <plugin>
               <groupId>org.eclipse.tycho</groupId>
               <artifactId>tycho-surefire-plugin</artifactId>
               <version>${tycho.version}</version>
               <configuration>
                   <providerHint>testng</providerHint>
                   <argLine>-ea</argLine>
                   <suiteXmlFiles>
                       <suiteXmlFile>mysuite1.xml</suiteXmlFile>
                       <suiteXmlFile>mysuite2.xml</suiteXmlFile>
                   </suiteXmlFiles>
               </configuration>
           </plugin>
      </build>

Using Groups

If you want to use groups within your TestNG tests, you have to configure one additional thing. Because of the way TestNG and the Surefire TestNG Plug-in do select the test groups that should be executed, the Plug-in that exports the org.testng packages must be able to load a class from the Surefire TestNG Plug-in. With the OSGi Classloader this is only possible if you dynamically import that package in the plugin you export the TestNG packages. Within the MANIFEST.MF file of that Plug-in add

  DynamicImport-Package: org.apache.maven.surefire.testng.utils

To execute specific groups you could add the group names within the plugin configuration

      <build>
           <plugin>
               <groupId>org.eclipse.tycho</groupId>
               <artifactId>tycho-surefire-plugin</artifactId>
               <version>${tycho.version}</version>
               <configuration>
                   <providerHint>testng</providerHint>
                   <argLine>-ea</argLine>
                   <groups>myGroup1,myGroup2</groups>
               </configuration>
           </plugin>
      </build>

New option to check consistency of .target files

The target-platform-validation-plugin now features a new option flag checkProvisioning which will evaluate whether the content of the .target file can be provisioned all together. It checks for dependencies availability, non-conflicting versions of included installation units, and all kinds of errors usually reported by p2 director.

Execution environment for Forked EclipseRun Run

• (INCOMPATIBLE CHANGE) The <executionEnvironment> parameter of the tycho-eclipserun-plugin:run mojo is used not only to resolve the forked run's dependencies but also to select the execution environment to run it with. Previously the execution enviroment from the configured toolchain (if any) was used, with a fallback on the execution environment that ran the build. Using the <executionEnvironment> parameter to select the execution environment allows one to, e.g., use a newer execution environment for the forked run than is used for the main build (bug 498180).