[jboss-cvs] JBossAS SVN: r96582 - in projects/jboss-osgi/trunk/reactor/framework/src: main/java/org/jboss/osgi/framework/resolver/internal and 8 other directories.

[Thomas Diesler]

I have removed all dependencies on the Resolver API. Instead the 
resolver tests now use the PackageAdmin API. I also made the Resolver 
plugin optional and removed it from the MC Framework configuration. 
There are tests failing and I still need to look into some issues in the 
integration test suite as they would show up in hudson. Isolated issues 
I then port back to framework so that we have tests for them in the 
project directly. This will all be documented properly in the forum, 
hopefully tomorrow or the day after.

cheers
-thomas

On 11/23/2009 05:15 PM, Ales Justin wrote:
> In defense of Thomas's today's resolver commits,
> we discussed this and decided the following:
> * Thomas makes current resolver tests generic - exposing potential 
> problems
> * you (Adrian) step in and make resolving work properly,
>   hoping those tests will help you find/expose issues faster
> * Thomas takes over the issue of bundle's lifecycle wrt MC's 
> ErrorHandler impl
> * error handling: MC core, Deployers facade, actual OSGi impl/behavior
>
> -Ales
>
> Adrian Brock wrote:
>> You're still wasting your time.
>> You can't say I haven't given you enough warnings. :-)
>>
>> I'd understand it if the tests were written properly
>> and tested the requirements. But these tests are written against 
>> implementation details:
>>
>> On Thu, 2009-11-19 at 10:59 -0500, jboss-cvs-commits at lists.jboss.org
>> wrote:
>>> Author: thomas.diesler at jboss.com
>>> Date: 2009-11-19 10:59:11 -0500 (Thu, 19 Nov 2009)
>>> New Revision: 96582
>>
>>>           Resolver resolver = getTestResolver();
>>>           assertEquals(1, resolver.getBundles().size());
>>>           -         ResolverBundle resolvableA = 
>>> resolver.getBundle(bundleA.getSymbolicName(), null);
>>> -         assertNotNull("Resolvable not null", resolvableA);
>>> +         ResolverBundle resBundleA = 
>>> resolver.getBundle(bundleA.getSymbolicName(), null);
>>> +         assertNotNull("Resolvable not null", resBundleA);
>>>           -         resolvableA = 
>>> resolver.getBundle(bundleA.getSymbolicName(), bundleA.getVersion());
>>> -         assertNotNull("Resolvable not null", resolvableA);
>>> +         resBundleA = resolver.getBundle(bundleA.getSymbolicName(), 
>>> bundleA.getVersion());
>>> +         assertNotNull("Resolvable not null", resBundleA);
>>>           -         resolvableA = resolver.getBundle(bundleA);
>>> -         assertNotNull("Resolvable not null", resolvableA);
>>> +         resBundleA = resolver.getBundle(bundleA);
>>> +         assertNotNull("Resolvable not null", resBundleA);
>>
>> So I can't use them when I do this properly using jboss-cl.
>>
>> That's why its never a good idea to write regression tests
>> against implementation details, you should write to the exposed 
>> public interface.
>>
>> i.e. which bundle did it load that class from?
>> See for example ExportImportPackageUnitTestCase
>>
>> P.S. I also recently added a
>> deployBundle(String name, OSGiMetaData metaData, Class<?>... packages)
>>
>> so you don't need to create a MANIFEST.MF for each test. You
>> just populate the OSGiMetaData programmatically in your test code.
>> It still needs a builder to make this easier.
>>
>> See for example testAssembledDeployment() in the smoke tests.
>>


-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx