aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <>
Subject Re: [Proposal] Use release per subproject for blueprint
Date Tue, 03 Jan 2017 13:04:49 GMT
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


> Am 03.01.2017 um 12:34 schrieb Christian Schneider <>:
> 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
> 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
> So what do you think?
> Christian
> -- 
> Christian Schneider
> Open Source Architect

View raw message