felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "San Martín, Matías" <matias...@yahoo.com.ar>
Subject Re: OBR resolver knows about a requirement of a missing requirement
Date Tue, 13 Mar 2012 23:31:32 GMT
El 13/03/12 00:19, Richard S. Hall escribió:
> On 3/11/12 12:27 , matias san martin wrote:
>> Hi Richard,
>>
>> I want to thank you again for taking the time to analyze my problem.
>> I attach a .zip file with the following content:
>>
>> 1- Repositories/
>> 2- test.osgi.obr.resolver.main/
>> 3- org.osgi.service.obr-1.0.2.jar
>> 4- test.osgi.obr.resolver.main_1.0.0.jar
>>
>>
>> 1- Is a directory with the repositories and bundles that are being 
>> used (repo1, repo2 and repo3 as defined in my previous mails)
>> 2- I the source (Eclipse project) of the bundle I'm using to resolve 
>> the dependencies (logic described in my previous mails)
>> 3- Is the bundle defining the OBR service interface (is the same that 
>> can be downloaded from felix's download page [1], I just add it for 
>> completeness).
>> 4- Is the compiled into a bundle version of 2
>>
>> I'm using felix framework 4.0.2.
>>
>> The steps to reproduce my problems are:
>>
>> 1- Copy Repositories/ to the framework's runtime current directory 
>> (./). This base directory is hardcoded in the 
>> test.osgi.obr.resolver.main_1.0.0.jar bundle, you can change if you 
>> want (in 
>> test.osgi.obr.resolver.main/src/test/osgi/obr/resolver/main/impl/Resolutor.java)

>> but you will need to regenerate the bundle.
>> 2- Start the felix framework 4.0.2
>>
>> 3- Install and start the OBR api bundle (org.osgi.service.obr-1.0.2.jar)
>> 4- Install and start the bundle test.osgi.obr.resolver.main_1.0.0.jar
>> 5- If everything is ok, you should see an output like:
>> -----------------------
>> Adding new repository: ./Repositories/repo1/repository.xml
>> Found 1 resources
>>
>> R Id: test.osgi.dynload.bundle.main/1.0.0, SimbolicName: 
>> test.osgi.dynload.bundle.main. str: 
>> org.apache.felix.bundlerepository.impl.wrapper.ResourceWrapper@5f49d886
>> Getting a new resolver
>> Number of unsatisfied requirements: 1
>> Unable to resolve Name: package, filter: 
>> (&(package=test.osgi.dynload.bundle.runner.thread)(version>=1.0.0)(!(version>=2.0.0)))
>> Adding new repository: ./Repositories/repo2/repository.xml
>> Getting a new resolver
>> Number of unsatisfied requirements: 2
>> Unable to resolve Name: package, filter: 
>> (&(package=test.osgi.dynload.bundle.inter.runner)(version>=1.0.0)(!(version>=2.0.0)))
>> Unable to resolve Name: package, filter: 
>> (&(package=test.osgi.dynload.bundle.runner.thread)(version>=1.0.0)(!(version>=2.0.0)))
>> Adding new repository: ./Repositories/repo3/repository.xml
>> Adding new repository: ./Repositories/repo2/repository.xml
>> Getting a new resolver
>> Resource: successfully deployed
>> g! Llamando a echoer
>> Echooooooo, cuenta: 1
>>
>> -----------------------
>>
>> Hope you can figure out which is the "problem" because certainly I 
>> can't Regards and thanks again
>
> What this is doing is correct. The first repository is missing a 
> provider for main's import of the ...runner.thread package, which is 
> the first unsatisfied requirement you see. Then you add the second 
> repo which has a provider for ...runner.thread, but that provider 
> imports the ...inter.runner package which cannot be satisfied in 
> either repo1 or repo2.
>
> So, you end up with two unsatisfied requirements on your second 
> resolve attempt, one for the main's import of ...runner.thread and one 
> for runner.thread's import of ...inter.runner, which is what you see 
> above. Perhaps you are confused because you see two unsatisfied 
> requirements here and you were expecting to see one. But two is 
> correct since neither import from the two different bundles could be 
> resolved.
>
> On the third attempt you add both the repo2 and repo3 (although 
> technically you don't need to add repo2 again, since you already added 
> it). After that, everything can be satisfied, which is correct.
>
> -> richard
>

Now that you mention it, it seems so obvious. I didn't get that the 
runner.thread dependency will appear again as an unresolved dependency 
since it couldn't be resolved because the inter.runner is missing.
Thank you for the feed-back!


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message