bjhargrave
commented
9 years ago Talked with @pkriens about this. He wants to
- Add API to bndlib to allow a caller to programmatically add a location (such as a class loader) where plugins can be found.
- Change bndtools to call this new API to have bndlib look in the biz.aQute.repository bundle for plugins.
- Change the gradle plugin to slurp in the biz.aQute.repository code.
Once all three things are done, then we can remove -pluginpath from the bnd build as the repository plugins can be loaded from the gradle plugin for the offline build or the biz.aQute.repository bundle for the bndtools build.
@pkriens will do 1 and 2, @bjhargrave will do 3.
pkriens
We are currently using an old (2.4.0), fixed version of biz.aQute.repository which is committed into the repo: https://github.com/bndtools/bnd/blob/master/cnf/plugins/biz.aQute.repository.jar. We really need to be using a version from the last build like we do with the gradle plugin.
I have made two different proposals for how to address this: #834 and #835. @pkriens suggested instead to slurp biz.aQute.repository into the gradle plugin jar so that we then do not need to specify biz.aQute.repository on the
-pluginpath. While this may work for the gradle build, it fails for bndtools in Eclipse since the gradle plugin jar is not used. In bndtools, the bndlib bundle does not itself have any visibility to the biz.aQute.repository bundle's packages since it does not import them. So unless we slurp biz.aQute.repository into bndlib (which seem wrong), we will need a solution which provides a separate biz.aQute.repository jar which is accessed via-pluginpath. So I think we are back to the choices in #834 and #835.