Bug 4818 - TCK property jsr352.impl.runtime not sufficient
TCK property jsr352.impl.runtime not sufficient
Product: jbatch
Classification: Unclassified
Component: TCK
All All
: P5 normal
: ---
Assigned To: cvignola
Depends on:
  Show dependency treegraph
Reported: 2013-03-20 20:04 UTC by cf126330
Modified: 2013-08-28 22:04 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description cf126330 2013-03-20 20:04:36 UTC
jsr352.impl.runtime property may not be sufficient for tck testing.  Since we only need to get the implementation classes, I suggest changing it to batch.impl.classes, for example,


The current ant run target only takes impl classes from ${jsr352.impl.runtime}/**/*.jar, but some implementation may keep classes in a directory, not jar, or may not have every jar under one single directory.

We may also want to add a property for passing testing jvm options.
Comment 1 ScottKurz 2013-03-20 20:34:01 UTC
We'll try to look at this type of enhancement, though we should probably prioritize areas where our coverage of the spec needs improvement.

I must admit I'm not familiar with what if any rules exist about modifying buildfiles in order to run the TCK, but I'm hoping, for example, that if you needed to make such a change it will still count as an official run.
Comment 2 cf126330 2013-03-21 02:33:46 UTC
w.r.t user properties, the common practice in TCKs is to keep them in a properties file so as to avoid mixing up with logics in build files.  Users should not need to touch build.xml files.  This is also how CTS handles it, and if we follow the same pattern, it makes it easier to integrate it into CTS later.

In addition to batch.impl.classes, we also need a property to pass jvm options to testng, such as -DjobOperator.sleep.time, debug options, etc.
Comment 3 ScottKurz 2013-03-21 04:49:30 UTC
I agree that's a better way to do it.. and actually, I think we might have a bit more time on the SE TCK, especially the automation around the TCK... so I think we can fix this.

BTW, our latest drop includes an exposure of all of our "sleep times" via front-end JVM system property.   

This enables someone who is failing a test because something is running "too slow" (or too fast) to try a different sleep value without recompile.    It seemed that to test this type of async function this was an acceptable design tradeoff.