Apparently I did something wrong when testing these changes and there seem to be a couple of test problems caused here.
1. A couple of blueprint tests fail with the new tracker. I think they are testing blueprint using composite bundles. Since composite bundles are a non-standard feature I wonder if it would be plausible to have a switch to turn on composite bundles support in recursive bundle tracker? 2. Apparently code compiled against R4.3 can't be used with R4.2? Compiling aries utils with R4.3 (so the code I added can compile, since it uses R4.3 classes) results in code that calls Version.compareTo(Version) which results in a NoSuchMethod error when called in a R4.2 framework where the method is Version.compareTo(Object). Does anyone have any ideas how to work around these problems? If anyone wants to revert my commits while we figure out what to do, go ahead. thanks david jencks On Nov 9, 2011, at 6:05 PM, David Jencks wrote: > I made a couple changes to utils (issues 777 and 778) to provide R43 > bundle-to-classloader determination and to make the RecursiveBundleTracker > work with equinox Region based isolation as well as the obsolete composite > bundle support. Aries seems to build fine for me and I can get the blueprint > extender to work in an isolated region using this, but I didn't try very hard > to see if it broke stuff in earlier frameworks. Please let me know if there > are problems. > > The approach I used for the bundle tracker is to register a bundle event hook > and feed the events to a bundle tracker (code copied from felix's bundle > tracker). This avoids all bundle event filtering. If anyone thinks this > approach is inappropriate please speak up :-) > > thanks > david jencks
