I've run the attached binary with the improved uses analysis in place:
Uses violation: <Import-Package: org.springframework.beans.factory.aspectj; version="0.0.0"> in bundle <ServiceCounterIntf_1.0.0>
package 'org.aspectj.internal.lang.annotation_1.6.6.BUILD-20090909' in bundle 'com.springsource.region.user_0.0.0' used by 'org.springframework.beans.factory.aspectj_3.0.0.RC1' in bundle 'org.springframework.aspects_3.0.0.RC1'
conflicts with 'org.aspectj.internal.lang.annotation_1.6.6.BUILD-20090909' in bundle 'com.springsource.org.aspectj.weaver_1.6.6.BUILD-20090909' imported by bundle 'ServiceCounterIntf_1.0.0'
The problem here is that Spring's beans bundle (which uses Import-Package for AspectJ) is wired to the region.user bundle, i.e. the bundle that shares packages into the user region from the kernel. The ServiceCounterIntf bundle (which uses Import-Bundle for AspectJ) has been wired to the AspectJ weaver bundle as is expected when using Import-Bundle.
All AspectJ packages are shared between the kernel and the user region to ensure that the serviceability support woven in by Medic will work in both environments. This means that, unfortunately, we can't fix the problem by no longer sharing the types between the kernel and the user region.
We should give this some thought to see if there's anything clever we can do here to allow Import-Bundle to still work (it'd need to figure out the right packages to wire to from the region.user bundle somehow). In the meantime, this problem can be avoided by using Import-Package for AspectJ packages, rather than Import-Bundle.