aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holly Cummins <>
Subject Re: Which implementors of application interfaces are providers?
Date Thu, 19 Apr 2012 16:03:32 GMT
Hi Felix,

Thanks for the comments.

On Thu, Apr 19, 2012 at 3:54 AM, Felix Meschberger <>wrote:


> I think key are the "implements XXX" and "extends XXX" clauses (and
> similar anonymous classes). As soon as you have something like that in your
> code, it is "providing" and the narrow version range applies.

My understanding was that it was a bit more subtle than this, because some
APIs, like javax.http.HttpServlet, for example, are intended to be
subclassed by consumers of the API. So adding an extra method onto this API
would be a breaking change for consumers, even though it would normally
only be a minor-increment change.

However, avoiding such subtlety/tortuousness in our internal versioning
would clearly have some advantages, particularly if that understanding of
'provider' isn't universal.

IIRC bnd (and thus the bundle plugin) in recent versions is able to find
> this out and generate the import version ranges appropriately.

Ah, now that would be handy! I've just checked and it's not doing it in our
current build but I'll have an explore of more recent bnd versions and see
if I can make it work, since it would save me a lot of time. The bnd docs
seem to indicate it's a manual process:

"How does bnd know if a bundle is a provider or a consumer of a specific
package? Well, the default is the consumer policy but this can be
overridden with the provide:=true directive that works on the
Import-Package clauses
as well as on the Export-Package clauses." (

However, I'll look around and see if there's an automated detection which
isn't referenced from that page. Thanks!

> As for package exports, I started using the file with
> basically these BND annotations
>   @Version("1.0")
>   @Export(optional = "provide:=true")
>   package;
> Where the "provide:=true" is added if there is at least one
> interface/class implemented or extended within the same bundle.

I don't think we have any of these annotations, and I can see they'd be
very useful, so I'll put adding them onto my to do list.  I guess doing so
would mean switching from the text package info files to java ones. Are
there any opinions about doing this, one way or another?

> Also, I find it helpful to use the @ProviderType (provided by the
> exporting bundle) and @ConsumerType (consumed by the exporting bundle) BND
> annotations.

I'll have a look at these as well. Thanks.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message