1) There are n+m consumers and providers for 1 API. Where is then the best
place to define what role an interface plays?
2) Forcing a bundle to be a consumer XOR provider without a fundamental reason
is bad practice imho. Though it might not be the best thing to do, I can think
of several scenarios where it could make sense. You usually need very good
reasons to make something impossible by its architecture.
3) Switching a provider type to a consumer type (or vice versa) without a major
bump seems completely unreasonable
Your arguments about the annotated annotation sound a bit confused. If we do
not get it right, it is just as wrong indirectly? OSGi is a standard so I'd
rather have these annotations in my code then proprietary? And it violates the
basic separation of concerns pattern.
Kind regards,
Peter Kriens
On 15 apr. 2013, at 21:46, Henning Andersen wrote:
> Regarding 2 and 3 below, my point is that a client bundle should declare
> whether it is consumer or provider of an imported package (default consumer).
> With that knowledge, building a bundle that consumes a package from another
> bundle should fail if the client contains any implementations of
> provider-type interfaces.
> If the client cannot declare consumer or provider role/policy, a build cannot
> fail when a (consumer) client (by mistake) implements both consumer and
> provider types.
> Switching between consumer and provider policy automatically based on whether
> the client implements provider type interfaces is too much automation in my
> view. Getting a provider policy instead of a consumer policy unnoticed will
> introduce major problems later due to not being able to upgrade bundles
> individually.
>
> Given the above, provider type becomes the obvious default, since it really
> is the more restrictive one, clients can only implement a provider type
> interface if they are declared as providers of the containing package.
>
> Notice that changing an interface from provider to consumer type is safe in a
> minor version (regardless of the above), since clients build against the type
> when it was a provider type will be incompatible (if they implement the
> type). The reverse is not true, going from consumer to provider type will
> require a major version update of the package. This again favors that
> provider type is the default.
>
> Regarding the annotation indirection, defining the ability to use a different
> annotation scheme in the spec could free us from problems getting the
> consumer/provider type annotation right (plus this would be the only
> osgi-dependency for most of our code). In our case, we do have a hard rule
> that certain annotations dictate consumer type. The easiest way to enforce
> this would be to declare it on our annotation(s) so that developers only need
> to apply the one annotation, not both. The other way we have is to add a
> compilation check ourselves that validates that the rule is not broken.
>
> Thanks,
>
> Henning
>
>
>
> On Mon, Apr 15, 2013 at 9:46 AM, Peter Kriens <[email protected]> wrote:
> There are a number of issues with this opinion:
>
> 1) The whiteboard pattern in general requires a consumer type. So it is
> absolutely NOT the normal case to be a Provider Type, look at the OSGi
> compendium. I do not think there is any package without a Consumer Type.
>
> 2) The frequency of Consumer type/Provider type is irrelevant since they're
> aggregated in the package. Assuming everything is a Provider Type will break
> any client when one of the Consumer type changes, regardless of their ratio.
>
> 3) The package level provide: directive was a hack to make some of this stuff
> work when there are no Consumer/Provider Type annotations. In the future bnd
> should detect this information from the annotations because that is less
> error prone. And though it might be useful on imports, its primary intention
> is on the export.
>
> 4) It is another example, pervasive in enterprise software, of being 'nice'
> by trying to hide reality (Damping anyone?) because it is 'easier'. You first
> make it right, then make it easier. The other way around usually ends up in
> trading development time for lots of debug time. In general it is good to be
> lazy as a developer but it should never cause solutions that are not correct
> all the time. In the embedded world, these kind of suggestions would be
> considered, well, eh, flabbergasting :-)
>
> About the indirection of annotated annotations, this seems like things become
> a lot harder to read. I also expect that it will result in the proposed
> effect of 'well most of the time this existing annotation is ...', having the
> same problems as sketched before. I would suggest to keep it highly cohesive
> and simple.
>
> Kind regards,
>
> Peter Kriens
>
>
>
> On 14 apr. 2013, at 21:26, Henning Andersen wrote:
>
>> I certainly agree with Emily that having a default of @ProviderType is
>> sensible, since the normal case for most APIs is to call methods on it, not
>> to implement interfaces of it.
>>
>> bnd already has a similar default regarding its imports, where clients
>> should specify provide:=true when the client is a provider of the API.
>>
>> I think this makes perfect sense also from a tooling standpoint, in that a
>> tool could break the build if a client tries to implement a @ProviderType
>> interface without having declared provide:=true on the corresponding import
>> statement. That way, there is no unsafety (except naturally purely semantic
>> changes to implementation).
>>
>> A sidenote on the RFC 197: I think naming these annotations more explicitly
>> like "ProviderImplemented" and "ConsumerImplemented" would reduce confusion
>> on which to use when. Also, it would be really nice if the RFC would allow
>> specifying other annotations as having the same semantics, for instance by
>> again annotating those annotations. Allowing us to write:
>>
>> @MyCustomAnnotation
>> public interface Xyz {}
>>
>> and giving provider or consumer role to the interface with the annotation.
>> We certainly have cases where this would allow us to not add yet another
>> annotation to all our consumer implemented interface.
>>
>> Best Regards,
>>
>> Henning
>>
>>
>>
>> On Sun, Apr 14, 2013 at 4:17 PM, Neil Bartlett <[email protected]> wrote:
>>
>> On Sun, Apr 14, 2013 at 2:38 PM, BJ Hargrave <[email protected]> wrote:
>> > And even that guess is not really safe. I always use the following
>> > example to explain. If you have an interface A:
>> >
>> > /* version 1.0 */
>> > interface A {
>> > /* returns true in a certain condition */
>> > boolean check();
>> > }
>> >
>> > And in a new version, this interface has been changed like this:
>> >
>> > /* version ??? */
>> > interface A {
>> > /* returns false in a certain condition */
>> > boolean check();
>> > }
>> >
>> > Then, even though the method signature has not changed in any way,
>> > the semantics of this interface have changed in an incompatible way
>> > and a major bump in versioning is required. There is just no way
>> > tools are going to pick up on this as long as they're just based on
>> > Java (byte)code, you actually need to understand the documentation
>> > to understand this. So this is another instance where you might be
>> > in for some unpleasant surprises if you blindly use the output of
>> > such versioning tools.
>>
>> Yes. Tools can only analyze syntactic changes to find semantic differences.
>> Other (non-syntactic) semantic changes need humans to participate in the
>> version change decision.
>>
>> The conclusion seems to be that tools will differ in their approach to
>> interpreting defaults. Tools in the future could even attempt to go further
>> and analyze actual method behaviour in addition to signatures. This is fine
>> because RFC 197 does not place any constraints on tool developers, it merely
>> defines the existence and meaning of the @Consumer/ProviderType annotations.
>>
>>
>> --
>>
>> BJ Hargrave
>>
>> Senior Technical Staff Member, IBM
>> OSGi Fellow and CTO of the OSGi Alliance
>> [email protected]
>>
>> office: +1 386 848 1781
>> mobile: +1 386 848 3788
>>
>>
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> [email protected]
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> [email protected]
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> [email protected]
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
