We don't require maven or the source code to run jUDDI, why should the TCK require any of those?
Assuming we don't have those, there's no class that I know of that will start the tests from the command line. What it should be something as simple as this: java -jar uddi-tck.jar <path to config file> On Mon, Jun 3, 2013 at 10:15 AM, Kurt T Stam <kurt.s...@gmail.com> wrote: > On 6/3/13 10:08 AM, Alex O'Ree wrote: >> >> Lots. >> >> 1) we don't distribute maven, the source code and all of the other >> dependencies with the client jar packages > > Hmm. I don't think having to download maven is an issue, and if you really > feel that strongly I guess we cold add maven (and java?) to the distro, one > needs somekind of build tool. I'd rather stick with maven. > >> 2) it won't work if you're on an isolated network > > The -O option should fix that. > >> 3) is a full source code checkout really necessary in order to >> validate that someone else's product is valid? > > No it should be running of the code we ship in the distribution. > >> >> The goal here is to make the tck a usable product without a full up >> dev environment, maven, or network connectivity. Maven is great for >> some things, not for all things >> >> On Mon, Jun 3, 2013 at 10:05 AM, Kurt T Stam <kurt.s...@gmail.com> wrote: >>> >>> What's wrong with running maven? >>> >>> >>> On 6/3/13 9:53 AM, Alex O'Ree wrote: >>>> >>>> Even if we include the unit tests, there's no void main function that >>>> will trigger the tests, the configuration loads from within the jar, >>>> not from a user definable location, and running junit tests from >>>> within your own app is a bit tricky (unless we know we're never going >>>> to add another test ever again, thus the reflection). >>>> >>>> On Mon, Jun 3, 2013 at 9:47 AM, Kurt T Stam <kurt.s...@gmail.com> wrote: >>>>> >>>>> Maybe I'm missing the point, but why can't they run the way they are >>>>> now? >>>>> All we have to do is to add the uddi-tck-test.jar, which for omitted by >>>>> mistake.. >>>>> No? >>>>> >>>>> Cheers, >>>>> >>>>> --Kurt >>>>> >>>>> >>>>> On 6/2/13 12:57 PM, Alex O'Ree wrote: >>>>>> >>>>>> Relevant Tickets: >>>>>> JUDDI-314 Create a juddi-client-bundle-3.0.0 with jar, source and >>>>>> javadocs for juddi-client and uddi-ws >>>>>> JUDDI-583 Productize the TCK test suite >>>>>> >>>>>> I'm attempting to formulate a plan to turn the UDDI TCK into both a >>>>>> testing platform for jUDDI (as it is now) and be able to run the test >>>>>> suites as a standalone program (without requiring a full checkout). >>>>>> >>>>>> Currently, all Unit Test cases (/src/test) are within uddi-tck, and >>>>>> all setup and configure the code is in uddi-tck-base (/src/main) >>>>>> >>>>>> >>>>>> In order to facilitate this change, I've came up with an idea and was >>>>>> wondering if anyone else had a better one before I devote time and >>>>>> effort into it. >>>>>> 1) Use reflection to identify all classes with test cases from >>>>>> uddi-tck, then use JUnitCore to execute them. In addition, rework the >>>>>> configuration loading bits to load files from disk instead of from >>>>>> within the jar file. This requires the test classes (src/test) to be >>>>>> included in the udid-tck jar file. >>>>>> >>>>>> 2) Refactor all existing test cases to uddi-tck/src/main and rework >>>>>> the actually uddi-tck/src/test classes to call the code from src/main. >>>>>> I only think this should be required if for some reason the test >>>>>> classes can't be included with the tck jar file see (JUDDI-314). Then >>>>>> use some kind of reflection to find all test cases and execute them. >>>>>> >>>>>> >>>>>> In either case, it would be nice to have a formatted xml output which >>>>>> identifies all the tests cases that failed and the relevant output. >>>>>> Similar to the surefire test reports, but more user friendly. >>>>> >>>>> >
