TCK progress

["Richard S. Hall" <he...@ungoverned.org>]

FYI

I just committed a patch for FELIX-35, which implemented the few 
remaining PackageAdmin methods from R4 that we were missing. That's good 
in and of itself, but even better -- we are now passing 13 of 15 test 
suites from the TCK.

I will try to find the time to update our status page, but the remaining 
issues revolve around fragments, execution environment checking, and 
native code matching. With fragments, we aren't doing too bad either, 
since we only have partial support, but are passing several of the tests 
in the fragment test suite.

Always good to make progress with the TCK.

It looks like we will be able to have a worthwhile Felix 1.4.0 release 
in the next couple of weeks.

-> richard

Re: TCK progress

["Richard S. Hall" <he...@ungoverned.org>]

Rob Walker wrote:
> Cool - good news.
>
> Not sure how your voice/influence with OSGi is these days.

Me neither! :-)

> Something that occured to me and others recently, was the apparent 
> lack of "standard" TCK tests for the Http alias expansion/resolution - 
> the spec is quite comprehensive, but we've seen that it is open to 
> "interpretation" in a number of areas. There are possibly other Http 
> aspects that might benefit with official TCK tests too, for example I 
> just raised FELIX-772, which I'm not really sure is a bug or expected 
> behaviour. I suspect it's something that HttpService implementations 
> take their own view on depending on what is seen as normal Http server 
> behaviour. So it might be nice if it was (a) spec'd; and (b) 
> verifiable by TCK.

I will bring it up.

-> richard

>
> Cheers
>
> -- Rob
>
> Richard S. Hall wrote:
>> FYI
>>
>> I just committed a patch for FELIX-35, which implemented the few 
>> remaining PackageAdmin methods from R4 that we were missing. That's 
>> good in and of itself, but even better -- we are now passing 13 of 15 
>> test suites from the TCK.
>>
>> I will try to find the time to update our status page, but the 
>> remaining issues revolve around fragments, execution environment 
>> checking, and native code matching. With fragments, we aren't doing 
>> too bad either, since we only have partial support, but are passing 
>> several of the tests in the fragment test suite.
>>
>> Always good to make progress with the TCK.
>>
>> It looks like we will be able to have a worthwhile Felix 1.4.0 
>> release in the next couple of weeks.
>>
>> -> richard
>

Re: TCK progress

[Rob Walker <ro...@ascert.com>]

Cool - good news.

Not sure how your voice/influence with OSGi is these days.

Something that occured to me and others recently, was the apparent lack 
of "standard" TCK tests for the Http alias expansion/resolution - the 
spec is quite comprehensive, but we've seen that it is open to 
"interpretation" in a number of areas. There are possibly other Http 
aspects that might benefit with official TCK tests too, for example I 
just raised FELIX-772, which I'm not really sure is a bug or expected 
behaviour. I suspect it's something that HttpService implementations 
take their own view on depending on what is seen as normal Http server 
behaviour. So it might be nice if it was (a) spec'd; and (b) verifiable 
by TCK.

Cheers

-- Rob

Richard S. Hall wrote:
> FYI
>
> I just committed a patch for FELIX-35, which implemented the few 
> remaining PackageAdmin methods from R4 that we were missing. That's 
> good in and of itself, but even better -- we are now passing 13 of 15 
> test suites from the TCK.
>
> I will try to find the time to update our status page, but the 
> remaining issues revolve around fragments, execution environment 
> checking, and native code matching. With fragments, we aren't doing 
> too bad either, since we only have partial support, but are passing 
> several of the tests in the fragment test suite.
>
> Always good to make progress with the TCK.
>
> It looks like we will be able to have a worthwhile Felix 1.4.0 release 
> in the next couple of weeks.
>
> -> richard

-- 


Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com