aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Utils changes
Date Thu, 10 Nov 2011 08:43:41 GMT
I rolled back these changes so the build should be OK again.  I'd still like some advice on
these points.  For (2) I think it would be possible to have 2 maven projects, one built against
R4.2 with most of the code and one built against R43 with the new code and use the bundle
plugin to pull all the classes from the first jar into the second.  Any better ideas?

david jencks

On Nov 9, 2011, at 8:21 PM, David Jencks wrote:

> 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
> 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
>> 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

View raw message