bnd already does some of that work, just inspecting public API. It uses it to
generate warnings if your public API refers to a private class
Kind regards,
Peter Kriens
On 31 jan. 2013, at 10:22, Gerd Wütherich wrote:
> Hi,
>
> although inheritance is the most common case for these kinds of (compiletime)
> problems, it is not an "inheritance-specific" issue. The point is that your
> bundle uses an API but does not import all types that are used in this API.
>
> Example:
> If you use a class B that provides two methods 'public void doSomething(X x)'
> and 'public void doSomething(Y y)' and you use only one of them, than B has
> to known X *and* Y at compiletime (at least in the PDE/with the ecj),
> regardless if you call the other method in your code or not. So at
> compiletime you have to specify a dependency to B, X and Y, while at runtime
> you only have to specify a dependency to B and X if you don't call 'public
> void doSomething(Y y)' in your code.
>
> The question is if
> a) it makes sense to spread an API over multiple bundles (which is a common
> case!),
> b) to import this API 'partially'.
>
> Maybe one can use the uses contraint of the exporter to calculate if a bundle
> also imports all the types that are visible at an imported API?
>
> Regards,
> Gerd
> _______________________________________________
> 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
