Hi Christian On a high level I disagree and would suggest to continue releasing individual bundles.
Plus: don’t blindly update dependency versions just because there is a new release. I think the „plus“ is actually key here: With OSGi applications are bound late at the time of deployment using the wiring „instructions“ such as Import-Package and Export-Package. This is the essential dependency management for bundles. The build time dependencies really are just that: build time. So unless the build (the actual code, not necessairily the tests) don’t need any newly released features, it is actually better to *not* update the dependencies. Because this allows to update individual bundles more independently at deployment time. If there are requirements, then updating makes sense. But other than bundles implementing new API or bundles using new API, I fail to see any need for such updates. There is another one: In OSGi „projects“ bundles generally evolve independently. Releasing them in lock-step might/will create new versions of bundles which have not actually changed. What does the new version then purvey ? Nothing, at best it would be confusing. Just my $.02 Regards Felix > Am 03.01.2017 um 12:34 schrieb Christian Schneider <[email protected]>: > > Currently the blueprint bundles are released individually. I think this > creates a lot of overhead as there are quite many bundles and for each > release you have to manually update the dependencies in several places. I am > also sure that we quite regularly forgot to update dependencies. For example > the blueprint-repository project was not updated for any recent releases. > > So I propose we change the blueprint subproject to always release all bundles > and keep the bundle versions aligned. We should still be able to make the > project very stable by using package versions for the APIs. > > A side effect would be that we could have blueprint karaf features and an OBR > repository for other non karaf deployments in the aries blueprint code and > the maintenance would be quite low. > > So what do you think? > > Christian > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com >
