I agree the whiteboard pattern requires a consumer type and I am aware of that the pattern is widely used in OSGi compendium. However, in the products I have been working on, only handful times this pattern or listener pattern were used. There were thousands thousands interfaces declared though.
For your 2nd point, based on my previous observation, the consumer type interfaces are not common. The aggregation scenario is not common either. As a side point, I think when those annotations are available, we should set a best practice (such as splitting provider type interfaces from consumer type interfaces so that they are in two packages. The package version management can be fine grained.) This OSGi annoation rfc sets its default value based on risk factor. If the consumers of the annoations spec accept the risk being low, what is the point to fighting instead of collecting votes. Regards, Emily On Mon, Apr 15, 2013 at 8:54 AM, Peter Kriens <[email protected]>wrote: > Well, obviously a tool can only go so far ... I sure hope nobody has the > hope that tools can solve this problem. Once they can, we're out of work :-) > > This kind of changes are the main reason to place the packageinfo in the > same directory as where the change is made. Desperately hoping to be > updated. > > Interestingly, your change as described could be fully compatible, neither > description excludes the other :-) > > Kind regards, > > Peter Kriens > > On 14 apr. 2013, at 01:09, Marcel Offermans wrote: > > > On Apr 14, 2013, at 0:13 AM, Ferry Huberts <[email protected]> wrote: > >> On 13/04/13 23:56, Emily Jiang wrote: > >>> I still disagree. As I mentioned in the call, most interfaces will be > >>> provider type (implemented by service provider). If we assume them all > >>> to be consumer type (listener pattern), we will bump the major version > >>> unnecessarily when a new method is added. Our guess will be wrong 99% > or > >>> even more. I would like to hear what majority people think. > >> > >> As BJ said, @ConsumerType is the _safe_ guess. > > > > 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. > > > > Greetings, Marcel > > > > > > > > _______________________________________________ > > 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 > -- Thanks Emily ================= Emily Jiang [email protected]
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
