Ok i still think the same be accomplished with maven :) On Jun 5, 2013, at 16:32, "Alex O'Ree" <[email protected]> wrote:
> I'm not suggesting that we remove anything. This is an "in addition > to" function that would support performing tck based testing without > the need for internet access, maven, and the full source tree. > > On Tue, Jun 4, 2013 at 12:37 PM, Kurt T Stam <[email protected]> wrote: >> Hmm I think it would be better to keep things standard and use the unit >> tests framework and maven. >> >> >> On 6/4/13 9:33 AM, Alex O'Ree wrote: >> >> 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. >>
