That's the idea. I think its possible but we'll need to find a way to identify test classes without knowing a priori. This will make it more robust and hands off. I'll see what i can do On Jun 4, 2013 8:28 AM, "Kurt T Stam" <[email protected]> wrote:
> That way we get all the reporting options for free? > > On 6/3/13 11:32 AM, Alex O'Ree wrote: > >> 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 <[email protected]> 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 <[email protected]> >>>> 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 <[email protected]> >>>>>> 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. >>>>>>>> >>>>>>> >>>>>>> >
