juddi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex O'Ree" <spyhunte...@gmail.com>
Subject Re: TCK Productization Strategy
Date Mon, 03 Jun 2013 14:08:02 GMT

1) we don't distribute maven, the source code and all of the other
dependencies with the client jar packages
2) it won't work if you're on an isolated network
3) is a full source code checkout really necessary in order to
validate that someone else's product is valid?

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.stam@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.stam@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.

View raw message