Actually, the reason for considering pending packages is quite simple. Imagine a bundle that provides a service and exports/imports its service package. Now imagine that you have a bug fix for the service implementation. Since the new version of the service is compatible with the old version, it can be wired to the pending packages of the old version of the service and all clients of the old service can immediately start using the bug fixed version. If pending packages were not considered, then you would be forced to do a refresh and bring down all clients every time you updated the service implementation, which could prove too disruptive in some situations.
Keep in mind, however, that this only affects bundles that import/export the same package; this is generally good practice for bundles that export and implement services. If you are sharing implementation packages or know for a fact that you cannot make backwards compatibility claims, then you should only export your packages. Another approach when importing/exporting the same package is to not use a broad version range on the import, so that new versions of the bundle can export versions outside of the version range so that prior exported versions are no longer candidates. Yet another approach is to place those packages in a separate bundle. Regardless, you have stumbled upon a general issue that the performance of Felix' resolver needs to be optimized. The resolver can be described as a two-pass resolver. In the first pass, all potential candidates for all dependencies are calculated transitively. In the second pass, we try to pick a set of candidates that result in a consistent class space. The first pass used to be quick because we used a specific approach that could use indexing to do package lookups. When we moved to the generic resolver the first pass slowed down quite a bit, which is why trunk is actually a hybrid generic resolver instead of a pure generic resolver. In my workspace I currently have code that allows us to create indexes for LDAP query evaluation, so once I get it ironed out we should be able to go to a pure generic resolver. In contrast to the first pass, which was fast to begin with (and will be fast again), the second pass has always been slow in the worst case of lots of candidates with lots of 'uses' constraints. So the general solution is to improve performance on the second pass of the resolver, especially since it will only get worse when we start adding support for fragments. The current implementation simply permutates through all possible combinations in an arbitrary order, which is not very smart. One approach to optimize it is to think about how to order the permutations in such a way where candidates with the best chance for success are selected first. Another approach is related to what you suggest, trying to find ways to eliminate candidates that can never succeed to reduce the permutations. Those are ideas off the top of my head and I am sure there are others. Help in this area would be greatly appreciated! :-) -> richard -----Original Message----- From: "Felix Meschberger" <[EMAIL PROTECTED]> Subj: Re: Felix bundle resolution Date: Wed 16. May 2007 8:30 Size: 941 bytes To: [email protected] Hi, On 5/16/07, Richard S. Hall <[EMAIL PROTECTED]> wrote: > > > I am not sure we can do that. There has been some waffling on this in the > spec. I think that R4 basically said pending packages should not be > considered, but I think there was some discussion for R4.1 that reversed > this thinking. So, I am pretty sure Felix used to not consider pending > packages and was modified to explicitly consider them not too long ago. Interesting. Because considering packages of a bundle's module to be updated as candidates seems useless (at least to some uninitiated mind like mine). Furthermore, the degradation in performance is drastic: The resolution takes hours and hours compared to sub-seconds ignoring the updated module. Maybe, only the pending module of the bundle which is updated should be ignored while other pending packages should be looked at ? I will look into it some more to verify... Thanks alot. Regards Felix
