commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: OSGi Version at Package Level
Date Tue, 20 Jun 2017 14:18:08 GMT
On 2017-06-20, Bertrand Delacretaz wrote:

> On Thu, Jun 15, 2017 at 6:53 PM, Stefan Bodewig <> wrote:
>> ...We use the default configuration of the bundle plugin, only marking some
>> imports as optional. So we are exporting all our packages...

> Ok. In the OSGi world it's only APIs and utility classes that should
> be exported, implementations should be hidden.

> But this requires separating these things (API, public utilities,
> implementation) in their own packages - if you don't do that, using
> OSGi semantic versioning might not help much and the whole thing might
> be moot.

It may be more difficult than that. Some format specific packages are
actually mixtures of API and implementation as we provide extensions
only supported for a specific format. Things like which compression
level to use for gzip or the dialect to use when tar encounters file
names longer thann 100 characters ...

> And reorganizing your packages might cause too much pain compared to
> the benefits, although it's good in the long term. So maybe something
> for a major release.

If we ever get enough momentum for this, yes :-)

> The format specific packages should be only implementation, correct?
> With only their APIs being exported.

Not in our current world, no.

>> ... What bad happens if the published version of a package changes even if
>> there is no change at all - this is what happens for some packages if we
>> keep on doing what we have done all the time....

> As above - this will require some OSGi users to upgrade or recompile
> other bundles that depends on yours, although technically that
> wouldn't be needed.

Understood, thanks.

>> ...What I really wanted to say is if the bugfix means the exported package
>> version now is "1.17.1" and the bundle version is "1.19" won't we
>> confuse the hell out of our users if we tell them they need version
>> 1.17.1 of the package that's contained inside of Compress 1.19 - as
>> opposed to telling them "upgrade to Compress 1.19"?...

> If the exported package versions haven't changed (because the bugfix
> code is implementation only so not exported) , in OSGi you can use
> either the old or the new version of the bundle, without any other
> changes to your system as OSGi won't see the change. Users will have
> to be informed to upgrade to 1.19 to get the bugfix, and based on no
> exported package versions having changed they will know they don't
> need any other changes in their system.

Interesting. This means OSGi only provides a way for consumers to say
which version of an API they want, but not which implementation. This
means as a consumer you can't say "I want version 1.19 of Compress
because I know it contains an important fix". This feels more limited in
expressiveness than I had expected.

>> ...I'm also afraid we'll have to grep through git logs to figure out which
>> version of Compress a bug is reported against if the reporter talks
>> about the version of an exported package rather than the version of the
>> bundle....

> They shouldn't, tracking should always happen against the version of
> the artifact that you release.

Phew, this is good. :-)

> I think the key is cleanly separating the code so that Java packages
> do not mix APIs, public utilities and bundle-private code.

> If that's done, the rest follows naturally.

> If that's not done, having independent version numbers for each
> package might cause more pain that benefits.

Thank you very much.

> HTH, and nice "talking" to you Stefan after all this time!




To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message