OSGiPackageScanClassResolver does not search extensions in Fragment bundles
Description
Environment
OSGi 4.3 and above
Activity
Nathan Voxland October 8, 2015 at 4:17 PM
I merged the pull request in. Thanks for the code and your patience. It does simplify things, which I always appreciate.
I don't have a great OSGi environment to test it in, so if anyone runs into any issues, let me know.
Balázs Zsoldos September 30, 2015 at 10:26 AM
@nvoxland: Could you please let me know when this pull request could be reviewed? It would be nice to know when we can expect a version of Liquibase where a solution like this is integrated. It would be also a very useful information if we have to wait longer or the pull request cannot be accepted as is.
Although it seems to be a bigger change, it simplifies things a lot (no need to have extra osgi project anymore) and the core is fully backward compatible.
Balázs Zsoldos September 11, 2015 at 1:52 PMEdited
I have not commented here yet, but I created a pull request. Could you please have a look somewhen?
Description of the changes is available in the description of the pull request.
Balázs Zsoldos August 25, 2015 at 5:52 AM
I started to migrate our code, pull request comes within 1-2 days.
Nathan Voxland June 23, 2015 at 7:46 PM
Whenever you can get to it would be great. I know how busy goes
I'll take a look at your session too, thanks for the link.
It is hard to write an extension to Liquibase in the modularized way. There is an enhancement for Liquibase that can scan extension classes within the Liquibase bundle as well. It seems to be logical that extensions should be added in the way that they are placed into Fragment bundles. However, the current function call of PackageScanClassResolver searches classes only in liquibase-osgi bundle. The current call is the following:
It would be nicer to use the bundleWiring of the bundle as it searches classes and resources in the fragments as well. Classloader can be retrieved from OSGi 4.3 in the following way (I do not thing it is reasonable to be compatible with OSGi 4.2 as it is ancient):
Please note, that this could be only a temporary solution. As a long term solution (Liquibase 4.x) it would be nice to refactor Liquibase in the way that it does not use singletons and patterns coming from the old Java EE world.