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 Wed, 04 Jan 2017 14:41:49 GMT

Sorry ahead for getting somewhat PITA ...

> Am 03.01.2017 um 20:04 schrieb Christian Schneider <>:
> The motivation for releasing the bundles together is that it makes life
> easier for maintainers as well as users. The maintainer can do the complete
> release in one step.

As a user I don’t care for that. As a maintainer I bite the bullet to make life for the
user easier.

> The user can just combine the bundles with the same
> version and knows they work together.

As a user I trust the Import-Package instructions to ensure this cooperation. Any other „work
together“ dependency not declared by Import-Package or a generic Capability/Requirement
pair, IMHO is very much not OSGi.

> It is also good for the developers as
> the tests always use the newest bundles. So tests always cover the newest
> changes. In current aries tests we often find at some point that tests
> still use the old versions and so are not covering errors in current code.

Sorry to be blunt, this sounds like solving for lazyness.

> In OSGi the bundle version does not mean much the important version is on
> the package.

True. My remark was more from the POV of a human encountering V1 and V2 of a bundle and assuming
there is a change. If there is none, I would be confused.

> So if we upgrade package versions using semantic versioning we
> should not have a problem with compatibility at runtime.
> By cleverly using the package versions we still can assure that more
> advanced users can upgrade individual bundles and keep others the same.
> Especially user code will be very compatible if we do not change package
> versions when there are no changes.

Oh, I assume the bundles are already configured like that ;-)

If you export packages with their bundle versions, you would be doing something wrong anyway.
Not looking at the source right now, but I assume this is not the case.

> We already have some examples where this works very well like Aries RSA.
> See
> The bundles are all released together. Still the spi package which is the
> most important dependency accross modules (besides the rsa spec) is still
> at 1.0.0. So while the bundle versions increased with every release we
> still can combine bundles from different releases at runtime without any
> problems.

Great. This is exactly how it works for package versions: Package versions are for the OSGi
framework to wire bundles. Semantic versioning applied. Bundle versions are for humans. It
would be great to apply semantic versioning here as well to some extent. Though not in a technically
strict sense. Still no change, no version IMHO is a good thing.


> Christian
> 2017-01-03 14:04 GMT+01:00 Felix Meschberger <>:
>> 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 <
>>> 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
>>> Open Source Architect
> -- 
> -- 
> Christian Schneider
> <>
> Open Source Architect
> <>

View raw message