OSGi Version at Package Level

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

OSGi Version at Package Level

Jörg Schaible
Hi,

maybe you have missed the discussion for
https://issues.apache.org/jira/browse/COMPRESS-399, but in short we face a
PR that introduces individual versions at package level for a component.

Actually I can understand the reasoning from a logical point if view, but it
fails for me completely from the practical side. Do we really want different
versions inside a single component? Can we even guarantee binary
compatibility to such an extent? Do we want such a micro-management for each
release?

IMHO it does not make sense, our release process is enervating enough. Until
now we provide one version for each release that is also valid for OSGi. I
have not too much experience with OSGi myself, but when I look into the
Eclipse ecosystem then I can see that a complete bunch of plugins is
released together as one version - I am not aware that they do such package
based version management. And - AFACIS - it is also possible to declare
valid ranges for OSGi dependencies. And we ensure with our release policy
for major versions (new package name) that no dependency can upgraded by
pure chance to a major incompatible version.

I won't put a veto on the commit of this PR, but actually I am not
interesting in supporting such a scenario for our components.

Your opinions?

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: OSGi Version at Package Level

garydgregory
On Tue, Jun 6, 2017 at 5:10 PM, Jörg Schaible <[hidden email]> wrote:

> Hi,
>
> maybe you have missed the discussion for
> https://issues.apache.org/jira/browse/COMPRESS-399, but in short we face a
> PR that introduces individual versions at package level for a component.
>
> Actually I can understand the reasoning from a logical point if view, but
> it
> fails for me completely from the practical side. Do we really want
> different
> versions inside a single component? Can we even guarantee binary
> compatibility to such an extent? Do we want such a micro-management for
> each
> release?
>
> IMHO it does not make sense, our release process is enervating enough.
> Until
> now we provide one version for each release that is also valid for OSGi. I
> have not too much experience with OSGi myself, but when I look into the
> Eclipse ecosystem then I can see that a complete bunch of plugins is
> released together as one version - I am not aware that they do such package
> based version management. And - AFACIS - it is also possible to declare
> valid ranges for OSGi dependencies. And we ensure with our release policy
> for major versions (new package name) that no dependency can upgraded by
> pure chance to a major incompatible version.
>
> I won't put a veto on the commit of this PR, but actually I am not
> interesting in supporting such a scenario for our components.
>
> Your opinions?
>

It sounds like a maintenance nightmare.

Is there at least a Maven plugin to help like Clirr and japicmp, but for
OSGi?

Gary


>
> Cheers,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: OSGi Version at Package Level

Bertrand Delacretaz
In reply to this post by Jörg Schaible
Hi,

On Wed, Jun 7, 2017 at 2:10 AM, Jörg Schaible <[hidden email]> wrote:
> ...maybe you have missed the discussion for
> https://issues.apache.org/jira/browse/COMPRESS-399, but in short we face a
> PR that introduces individual versions at package level for a component....

That's standard practice for OSGi bundles.

The https://github.com/apache/commons-compress/pull/26 changes look
suboptimal because they set the same initial version for each exported
package, but that's correct as a way to start doing that.

The "baseline" goal of the Apache Felix maven-bundle-plugin can then
be used to automatically recommend changes to those version numbers to
implement semantic versioning *at the java package level* which is the
way OSGi handles this.

We're using this extensively in Apache Sling, where we release a large
number of bundles each with their own package-level version numbers
which evolve independently from the bundle version. It works well once
it's setup, which is what that pull/26 does AFAICS.

Here's example output from that plugin building [1] after adding a
method to a class in the o.a.s.distribution package:

[INFO] Baseline Report - Generated by Apache Felix Maven Bundle Plugin
on 2017-06-07T08:54Z based on Bnd - see http://www.aqute.biz/Bnd/Bnd
[INFO] Comparing bundle org.apache.sling.distribution.api version
0.3.1-SNAPSHOT to version 0.3.0
[INFO]
[INFO]   PACKAGE_NAME                                       DELTA
CUR_VER    BASE_VER   REC_VER    WARNINGS
[INFO] = ================================================== ==========
========== ========== ========== ==========
[INFO] * org.apache.sling.distribution                      minor
0.3.0      0.3.0      0.4.0      Version increase required
[INFO]      < interface org.apache.sling.distribution.Distributor
[INFO]          + method doNothing()
[INFO]              + access abstract
[INFO] -----------------------------------------------------------------------------------------------------------
[INFO]   org.apache.sling.distribution.event                unchanged
0.1.1      0.1.1      0.1.1      -
[INFO] -----------------------------------------------------------------------------------------------------------
[INFO]   org.apache.sling.distribution.transport            unchanged
0.1.0      0.1.0      0.1.0      -
[INFO] -----------------------------------------------------------------------------------------------------------
[ERROR] org.apache.sling.distribution: Version increase required;
detected 0.3.0, suggested 0.4.0
[INFO] Baseline analysis complete, 1 error(s), 0 warning(s)

HTH,
-Bertrand

[1] https://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/distribution/api

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: OSGi Version at Package Level

Emmanuel Bourg-3
In reply to this post by Jörg Schaible
Le 7/06/2017 à 02:10, Jörg Schaible a écrit :

> Your opinions?

Do I understand well that we would have to micro manage versions at the
package level different from the version at the component level, and
sometimes significantly different versions (like foo 1.2.3 and
org.apache.commons.foo.bar 2.3.4)? That sounds like a nightmare. What is
the real gain? What existing problem would that solve exactly?

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: OSGi Version at Package Level

Bertrand Delacretaz
On Wed, Jun 7, 2017 at 9:10 AM, Emmanuel Bourg <[hidden email]> wrote:
> ...Do I understand well that we would have to micro manage versions at the
> package level different from the version at the component level, and
> sometimes significantly different versions (like foo 1.2.3 and
> org.apache.commons.foo.bar 2.3.4)?...

That's how it's done in OSGi-based systems.

>... That sounds like a nightmare...

With the right tools as mentioned in my previous message it's quite easy.

> ...What existing problem would that solve exactly?...

Implementing semantic versioning at the java package level as opposed
to bundle level.

In heavily componentized systems that's a big help, assuming the Java
packages make sense - to paraphrase Grady Booch, one package should do
one thing and one thing well.

On the other hand, if you don't care about package-level versioning
and consider your bundle as one big thing on which other things
depend, that doesn't help much.

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: OSGi Version at Package Level

Emmanuel Bourg-3
Le 7/06/2017 à 09:23, Bertrand Delacretaz a écrit :

> With the right tools as mentioned in my previous message it's quite easy.

Easier but not easy.


> Implementing semantic versioning at the java package level as opposed
> to bundle level.

That's the theory, I'm actually curious to see what real issue it solves
with commons-compress. What incompatibility in commons-compress caused
an issue with an OSGi application? And was there no other alternative to
solve this issue?

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: OSGi Version at Package Level

Bertrand Delacretaz
On Wed, Jun 7, 2017 at 9:57 AM, Emmanuel Bourg <[hidden email]> wrote:
> Le 7/06/2017 à 09:23, Bertrand Delacretaz a écrit :
>>... Implementing semantic versioning at the java package level as opposed
>> to bundle level.
>
> That's the theory, I'm actually curious to see what real issue it solves
> with commons-compress....

I agree that what I explained is "the theory" which is very valid in
complex systems fully based on OSGi, avoiding problems if for example
an API package is provided by multiple bundles.

But maybe it doesn't make sense for commons-compress, I don't know
that code well enough to comment.

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: OSGi Version at Package Level

sebb-2-2
On 7 June 2017 at 09:02, Bertrand Delacretaz <[hidden email]> wrote:

> On Wed, Jun 7, 2017 at 9:57 AM, Emmanuel Bourg <[hidden email]> wrote:
>> Le 7/06/2017 à 09:23, Bertrand Delacretaz a écrit :
>>>... Implementing semantic versioning at the java package level as opposed
>>> to bundle level.
>>
>> That's the theory, I'm actually curious to see what real issue it solves
>> with commons-compress....
>
> I agree that what I explained is "the theory" which is very valid in
> complex systems fully based on OSGi, avoiding problems if for example
> an API package is provided by multiple bundles.
>
> But maybe it doesn't make sense for commons-compress, I don't know
> that code well enough to comment.

I doubt package-level versions make sense for (m)any Commons components.
AFAIK most components are only usable and released as a whole.

It might make sense for VFS I suppose, if that wants to release
implementations separately.

> -Bertrand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: OSGi Version at Package Level

Gilles Sadowski
On Wed, 7 Jun 2017 10:54:54 +0100, sebb wrote:

> On 7 June 2017 at 09:02, Bertrand Delacretaz <[hidden email]>
> wrote:
>> On Wed, Jun 7, 2017 at 9:57 AM, Emmanuel Bourg <[hidden email]>
>> wrote:
>>> Le 7/06/2017 à 09:23, Bertrand Delacretaz a écrit :
>>>>... Implementing semantic versioning at the java package level as
>>>> opposed
>>>> to bundle level.
>>>
>>> That's the theory, I'm actually curious to see what real issue it
>>> solves
>>> with commons-compress....
>>
>> I agree that what I explained is "the theory" which is very valid in
>> complex systems fully based on OSGi, avoiding problems if for
>> example
>> an API package is provided by multiple bundles.
>>
>> But maybe it doesn't make sense for commons-compress, I don't know
>> that code well enough to comment.
>
> I doubt package-level versions make sense for (m)any Commons
> components.
> AFAIK most components are only usable and released as a whole.

It would have made sense in a certain component that is so big that
many parts of it did not fundamentally change between two releases,
yet where bumped into a different top-level package because other
parts required an incompatible release.

For a single "real" component (small scope), it is not necessary,
almost by definition.

For a bunch of utilities, e.g. (maven) modules, that can evolve
independently or at different paces, it seems like a neat idea.
[As was explained by Stian some time ago (when I had proposed to
allow module versions, it is a political decision, not a technical
one.]


Regards,
Gilles


> It might make sense for VFS I suppose, if that wants to release
> implementations separately.
>
>> -Bertrand
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: OSGi Version at Package Level

Stefan Bodewig
In reply to this post by Bertrand Delacretaz
On 2017-06-07, Bertrand Delacretaz wrote:

> On Wed, Jun 7, 2017 at 9:10 AM, Emmanuel Bourg <[hidden email]> wrote:
>> ...Do I understand well that we would have to micro manage versions at the
>> package level different from the version at the component level, and
>> sometimes significantly different versions (like foo 1.2.3 and
>> org.apache.commons.foo.bar 2.3.4)?...

> That's how it's done in OSGi-based systems.

>> ... That sounds like a nightmare...

> With the right tools as mentioned in my previous message it's quite easy.

>> ...What existing problem would that solve exactly?...

> Implementing semantic versioning at the java package level as opposed
> to bundle level.

> In heavily componentized systems that's a big help, assuming the Java
> packages make sense - to paraphrase Grady Booch, one package should do
> one thing and one thing well.

> On the other hand, if you don't care about package-level versioning
> and consider your bundle as one big thing on which other things
> depend, that doesn't help much.

Compress, which is targeted by Simon's pull request, is probably one of
the few components where package level versioning might make sense. For
most of our releases the packages are independent of each other and many
of our implementation packages don't change at all with new releases.

I'm not a citizen of OSGi land and find it hard to fully understand
whether the suggested changes make things better in any way.

Right now we bump all package level versions together with the
artifact. We intend to use semantic versioning, if we've failed to do so
in the past, then this is the problem more than whether the version
applies to the package or the library as a whole.

So I've got a bunch of practical questions:

Say we started versioning packages with 1.15 and all untouched APIs stay
at 1.14. We update package versions whenever there is an API change. We
go ahead and fix a problem with an implementation detail in - say - "ar"
in 1.19 but there is no API change. Would we modify the package version?

What if we change the implementation in "util", not in "ar", what is
going to happen to the version in "ar"? What will the bundle plugin tell
us?

Would this mean we'd need to start using bugfix version numbers for
packages where the implementaion changes but the API doesn't? I.e. "ar"
in Compress 1.19 would have version 1.14 (no API changes) or 1.14.5
(five implementation changes since 1.14)?

How would we tell our users to upgrade to version 1.19 in order to use a
bug fix that has been applied if this is the version of the library as a
whole and not the version of a package?

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: OSGi Version at Package Level

Bertrand Delacretaz
Hi Stefan,

I'll do my best to answer from my heavy OSGi user's point of view -
but as mentioned I know little about the specifics of Compress.

On Mon, Jun 12, 2017 at 4:39 PM, Stefan Bodewig <[hidden email]> wrote:
> ...Say we started versioning packages with 1.15 and all untouched APIs stay
> at 1.14. We update package versions whenever there is an API change. We
> go ahead and fix a problem with an implementation detail in - say - "ar"
> in 1.19 but there is no API change. Would we modify the package version?...

No, in the OSGi world the Java package versions are completely
independent of the version of the bundle that provides them.

You can actually have several bundles providing the same package, and
the OSGi framework will do the right thing and wire the most recent
version only, unless dependencies specify something different. I
digress and that's kind of an edge case but that helps explain the
concept I think: each exported package (others ones are invisible in
an OSGi system outside of their own bundle) has its own version cycle,
independent from anything else.

So in practical terms you define the version number of the bundle as
usual, driven by your perception of how much it changes, and it's the
package version numbers that are actually important in an OSGi system.

>
> ...What if we change the implementation in "util", not in "ar", what is
> going to happen to the version in "ar"? What will the bundle plugin tell
> us?..

if util is exported and changes require a version number increase then
you do that.

And if ar has not changed its version number stays the same.

And if a package is not exported it doesn't have an OSGi version
number, its changes only affect the implementation but not the wiring
with its clients.

>
> ...Would this mean we'd need to start using bugfix version numbers for
> packages where the implementaion changes but the API doesn't? I.e. "ar"
> in Compress 1.19 would have version 1.14 (no API changes) or 1.14.5
> (five implementation changes since 1.14)?...

Yes that's totally possible as the package has its own version numbering cycle.

>
> ...How would we tell our users to upgrade to version 1.19 in order to use a
> bug fix that has been applied if this is the version of the library as a
> whole and not the version of a package?...

If an non-exported implementation package includes changes then you
can tell your users to upgrade that bundle to include those fixes but
at the OSGi level those changes are invisible as the OSGi framework
only sees exported packages.

That's an implementation upgrade then, but if exported packages have
not changed you can guarantee that the system will startup without
requiring any other upgrades, that's the beauty of OSGi.

And if the version of an exported package changes, it will cascade
into the whole system and force you to upgrade bundles that depend on
it (based on their importing version range), which guarantees that if
your system starts it has all the right versions.

HTH,
-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: OSGi Version at Package Level

Stefan Bodewig
On 2017-06-12, Bertrand Delacretaz wrote:

> I'll do my best to answer from my heavy OSGi user's point of view -
> but as mentioned I know little about the specifics of Compress.

Thanks, Bertrand. You don't really need to know specifics about
Compress. It contains some packages that provide the generic API for
compression and archiving and they don't change that often. Then there
is a utils package that changes more frequently. And we've got a bunch
of format specific packages, many of which don't change at all between
versions, some of them only change the implementation (fixing bugs) and
some may add new methods or classes to add format specific features.

We use the default configuration of the bundle plugin, only marking some
imports as optional. So we are exporting all our packages.

To be honest I still feel I must be missing something.

So far all packages have the same version as the library itself,
i.e. they change the minor version with each release, even if there is
no change at all.

I do understand why signaling a minor change when there really is a
major change is a problem. But this is unrelated to the OSGi issue, so
I'd like to leave this out.

If the API of a package changes with a new release we are on the safe
side with the current approach.

What is the expectation if only the implementation of a package changes?
If we need to update the version of the package as well, them I'm afraid
no tools is going to catch this.

What is the expectation for the format specific packages if the version
of the utils package they internally depend on changes? Do the format
specific packages need a version update as well? Does the bundle plugin
detect this?

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.

> On Mon, Jun 12, 2017 at 4:39 PM, Stefan Bodewig <[hidden email]> wrote:

>> ...What if we change the implementation in "util", not in "ar", what
>> is going to happen to the version in "ar"? What will the bundle
>> plugin tell us?..

> if util is exported and changes require a version number increase then
> you do that.

> And if ar has not changed its version number stays the same.

This is what I've rephrased above. "ar" depends on "util" internally,
but that's (currently?) not visible looking at the list of exported
packages.

>> ...How would we tell our users to upgrade to version 1.19 in order to use a
>> bug fix that has been applied if this is the version of the library as a
>> whole and not the version of a package?...

> If an non-exported implementation package includes changes then you
> can tell your users to upgrade that bundle to include those fixes but
> at the OSGi level those changes are invisible as the OSGi framework
> only sees exported packages.

> That's an implementation upgrade then, but if exported packages have
> not changed you can guarantee that the system will startup without
> requiring any other upgrades, that's the beauty of OSGi.

> And if the version of an exported package changes, it will cascade
> into the whole system and force you to upgrade bundles that depend on
> it (based on their importing version range), which guarantees that if
> your system starts it has all the right versions.

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"?

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.

Maybe I'm making a bigger problem of this than it really is.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: OSGi Version at Package Level

Bertrand Delacretaz
Hi Stefan,

On Thu, Jun 15, 2017 at 6:53 PM, Stefan Bodewig <[hidden email]> 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.

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 the API of a package changes with a new release we are on the safe
> side with the current approach...

Yes. You might cause unnecessary incompatibilities with client OSGi
bundles that specify a restricted import versions range, that's
inconvenient but not dramatic.

>
> ...What is the expectation if only the implementation of a package changes?...

That should be invisible from the OSGi side of things. You will
mention in your release notes that users need to upgrade to the new
*bundle version* to get the new implementation, but the versions of
the OSGi exported packages wouldn't change.

Again this is moot if everything's exported or if packages mix things up.

> ...What is the expectation for the format specific packages if the version
> of the utils package they internally depend on changes? Do the format
> specific packages need a version update as well? Does the bundle plugin
> detect this?...

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

>
>... 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.

> ...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.

> ...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. Exported package versions then
naturally derive from whatever changes are made, and provide API-level
compatibility guarantees that are very useful in large systems.

>... Maybe I'm making a bigger problem of this than it really is...

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.

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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: OSGi Version at Package Level

Stefan Bodewig
On 2017-06-20, Bertrand Delacretaz wrote:

> On Thu, Jun 15, 2017 at 6:53 PM, Stefan Bodewig <[hidden email]> 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!

Indeed!

Cheers

        Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: OSGi Version at Package Level

Simon Spero
On Tue, Jun 20, 2017 at 10:18 AM, Stefan Bodewig <[hidden email]> wrote:

>
> 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.
>

Bundles can specify all sorts of Requirements, including implementations,
and bugfix version ranges  (by default, the bugfix component is not
specified in the lower bound, but that is just a default).   It can be a
little too expressive :-)

If a new version becomes available, it can often be swapped in dynamically
(e.g. when using Declarative Services (née Felix SCR)  with Greedy dynamic
reference, an inject  service will be replaced whenever a newer version is
available).

For more on updating and refreshing bundles see:
https://stackoverflow.com/questions/4330927/how-does-osgi-bundle-update-work


I do feel that it ought to be possible to have  more aggressive updates for
critical (security) release, though  that's a little orthogonal to the
version range issue.
Reply | Threaded
Open this post in threaded view
|

Re: OSGi Version at Package Level

garydgregory
On Jun 20, 2017 3:08 PM, "Simon Spero" <[hidden email]> wrote:

On Tue, Jun 20, 2017 at 10:18 AM, Stefan Bodewig <[hidden email]> wrote:

>
> 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.
>

Bundles can specify all sorts of Requirements, including implementations,
and bugfix version ranges  (by default, the bugfix component is not
specified in the lower bound, but that is just a default).   It can be a
little too expressive :-)

If a new version becomes available, it can often be swapped in dynamically
(e.g. when using Declarative Services (née Felix SCR)  with Greedy dynamic
reference, an inject  service will be replaced whenever a newer version is
available).

For more on updating and refreshing bundles see:
https://stackoverflow.com/questions/4330927/how-does-osgi-bundle-update-work


I do feel that it ought to be possible to have  more aggressive updates for
critical (security) release, though  that's a little orthogonal to the
version range issue.


One day, in a galaxy far far away, we will just be able to push a button to
release...

Gary
Reply | Threaded
Open this post in threaded view
|

Re: OSGi Version at Package Level

Bertrand Delacretaz
In reply to this post by Simon Spero
On Wed, Jun 21, 2017 at 12:08 AM, Simon Spero <[hidden email]> wrote:
> ....Bundles can specify all sorts of Requirements, including implementations,
> and bugfix version ranges...It can be a
> little too expressive :-)...

Yes, in the OSGi projects where I'm involved we avoid these things as
they create more coupling than we like.

When working in that way, getting the right implementations is a
deployment concern, and the OSGi framework "just" makes sure
everything that's deployed is compatible at the API level.

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: OSGi Version at Package Level

Bernd Eckenfels
Hello,

Just a pointer, those constraints come in handy when you plan to have OSGi do. the final resolving of actual deployed systems as well. It might not be your cup of coffee but I recommend the modularity talk of Peter Kriens 2016 at the modconf in Darmstadt: https://youtu.be/VwD0pYNOvFQ to get a radically different view.

(But Imagree with others that for most commons projects (especially tools libraries) there is not much benefit for having package versions different from bundle versions. Especially not since there is no overall OSGi theme going on.)

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: Bertrand Delacretaz <[hidden email]>
Sent: Wednesday, June 21, 2017 9:03:28 AM
To: Commons Developers List
Subject: Re: OSGi Version at Package Level

On Wed, Jun 21, 2017 at 12:08 AM, Simon Spero <[hidden email]> wrote:
> ....Bundles can specify all sorts of Requirements, including implementations,
> and bugfix version ranges...It can be a
> little too expressive :-)...

Yes, in the OSGi projects where I'm involved we avoid these things as
they create more coupling than we like.

When working in that way, getting the right implementations is a
deployment concern, and the OSGi framework "just" makes sure
everything that's deployed is compatible at the API level.

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]