-
Notifications
You must be signed in to change notification settings - Fork 9
SE_TCK_In_Maven
There are five TCK-related modules of interest:
Collects (in a Maven JAR package) the test and artifact classes, as well as JSL(s), batch.xml, SigTest signature files, etc.
Also has special profiles to update generated batch.xml file and generated SigTest files (which arguably could be factored to fit in better than it does today).
The porting SPI, (if you wanted to use something besides the default polling to wait for a job to end)
Collects (into the "official" zip/archive) the TCK artifacts and dependencies along with the Ant buildfiles driving the TestNG and SigTest portions of the TCK. This is basically the same form factor as the existing SE TCK zip (expanded to include the SigTest Ant buildfile too).
"Unofficial" execution of the TestNG (only, not SigTest) portion of the TCK against the RI (configured for SE mode). In addition to providing testing of the various RI and TCK modules, this also serves as a sample for how other modules might consume the TCK to test their own implementations against the TestNG portion of the TCK.
CDI: By default the RI will use CDI artifact loading / injection, as you'll see if you look at***...CONTAINER_ARTIFACT_FACTORY_SERVICE*** within default.tck.exec.properties:
$ cat com.ibm.jbatch.tck.exec/default.tck.exec.properties
...
com.ibm.jbatch.spi.ServiceRegistry.CONTAINER_ARTIFACT_FACTORY_SERVICE=com.ibm.jbatch.container.services.impl.WeldSEBatchArtifactFactoryImpl
...
More info on roles of the various properties files below.
The Maven execution will use the maven-failsafe-plugin to execute the TestNG suite definition at location com.ibm.jbatch.tck.exec/target/test-classes/testng/jsr352-tck-impl-SE-suite.xml.
This suite XML file comes from the com.ibm.jbatch.tck artifact and is unpacked during the Maven build.
For easier debugging, note that a subset of the full TCK suite can be executed using the TestNG suite definition mentioned above. The suite XML file has a helpful, commented-out example of how to run a subset of the full suite.
"Official" execution of the full TCK (both TestNG + SigTest) against the RI (configured for SE mode). Again, in addition to providing testing of the RI and the TCK distribution, this also serves as a sample for how other modules might consume the official TCK zip distribution and use the Ant scripts to test their own implementations against the TestNG and SigTest portions of the TCK.
Not using CDI: By default the RI will NOT use CDI artifact loading / injection, as you'll see if you look at ...CONTAINER_ARTIFACT_FACTORY_SERVICE within tck.execution.for.ri.properties:
$ cat com.ibm.jbatch.tck.dist.exec/tck.execution.for.ri.properties
...
jvm.options=-Dcom.ibm.jbatch.spi.ServiceRegistry.BATCH_THREADPOOL_SERVICE=com.ibm.jbatch.container.services.impl.GrowableThreadPoolServiceImpl -Dcom.ibm.jbatch.spi.ServiceRegistry.J2SE_MODE=true -Dcom.ibm.jbatch.spi.ServiceRegistry.CONTAINER_ARTIFACT_FACTORY_SERVICE=com.ibm.jbatch.container.services.impl.DelegatingBatchArtifactFactoryImpl
...
More info on roles of the various properties files below.
There are several properties files to understand, which can get confusing.
Some important ones for the TCK execution within the build:
These properties files will be read during the Ant execution of the official TCK (in the SigTest and TestNG portions, respectively). Within the build these are just templates to be copied into the official distribution, to be populated by the executor later.
In executing the official TCK against the RI, we use this properties file to supply the properties that could be set in the two above files, jsr352-tck.properties and jsr352-sigtest-tck.properties. Rather than trying to manipulate those two properties in the filesystem within this Maven execution, we just read them into memory as system properties before executing the TCK.
These properties are purely there to configure the RI, during its run of the TestNG portion of the TCK using the failsafe plugin. They configure the services (eg artifact factory) used by the RI as well as the sleep time properties used by the TCK. However, we don't have to worry about using properties to point to paths and JAR locations like we do in the official Ant-based TCK.
The execution actually runs against the test.properties file, which is ignored in the Git repo, though default.tck.exec.properties is committed into Git and will be copied into place as test.properties if one isn't present.