Unfortunately Liquibase 2 doesn’t work correct on OSGi, see http://liquibase.jira.com/browse/CORE-504
There is problem with code looking for extensions - it tries to translate classpath url to file (to get entries from jar or list files from directory) which is not possible using OSGi.
So ServiceLocator.findClasses should recognize protocol “bundle:” and in such case get correct Bundle and scan it using Bundle.getEntryPaths(String)
Actually, current ServiceLocator implementation use something like Extender Model - it reads “LiquiBase-Package” header from Manifest.mf and load classes from given packages.
- Liquibase should detect new installed bundles (as (Synchronous)BundleListener)
- some classloading issues should be fixed (for example in OSGi calls to Class.forName should pass classloader). Also static singletons are not recommended.
- all packages with classes loaded by ServiceLocator - including core extensions, should be declared in Manifest.mf
I’m not sure if extender model would be good for reading changeset files.
There is also possibility to create OSGi service with liquibase instance exported for other bundles (something like spring bean). It may use (import) DataSource exported as a service.
Another issue using OSGi is that the same packages (package names) should not occur in many bundles. It is so called “split-packages” and is difficult to use.
So any non-core Liquibase extensions should not be in liquibase.* packages - its opposite to curent recommendations in documentation.
I have no time to code functionality mentioned above, but gladly help with any OSGI related issues or questions.