I think the DefaultPackageScanResolver doesn’t work with OSGi. As far as I can see, the DefaultPackageScanResolver lists classes from either the filesystem or a jar file in order to find implementations. But it cannot do so for OSGi bundles (http://grepcode.com/file/repo1.maven.org/maven2/org.liquibase/liquibase-core/2.0.1/liquibase/servicelocator/DefaultPackageScanClassResolver.java#169).
Maybe one can create a compatible PackageScanClassResolver that doesnt scan packages but looks up services from the OSGi registry (or better to create a compatible ServiceLocator, so its newInstance() method can return the service directly from the registry). This way it’s possible to find implementations of interfaces (not subclasses of “normal” classes, though) – and one would have to register every implementation to the registry – which are quite a few… A BundleActivator can then just instantiate either the new ServiceLocator or set the osgi-enabled class resolver.
I just gave it a quick try with a very simple changelog that only creates a table and inserts a row. But I don’t know liquibase code well enough, maybe this won’t work in real world. I have no idea for a “simple” workaround.