juddi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kurt Stam <kurt.s...@gmail.com>
Subject Re: TCK Productization Strategy
Date Wed, 05 Jun 2013 21:01:43 GMT
Ok i still think the same be accomplished with maven :)

On Jun 5, 2013, at 16:32, "Alex O'Ree" <spyhunter99@gmail.com> 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 <kurt.stam@gmail.com> 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" <kurt.stam@gmail.com> 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 <kurt.stam@gmail.com>
>>>>> 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
>>>>>> 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
>>>>>>>> will trigger the tests, the configuration loads from within
the jar,
>>>>>>>> not from a user definable location, and running junit tests
>>>>>>>> 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
>>>>>>>>>> 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
>>>>>>>>>> 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

View raw message