There is one trick in bnd that can solve your problems but it requires that
you're very careful not to expose the base classes/adapters outside your
bundle. It is called Conditional-Package, it is similar to static linking in C.
What you do is provide the base classes in a special package subtree (I use
aQute.lib). In the bnd file you do:
Conditional-Package: aQute.lib.*
bnd will now automatically copy the classes in these packages that you actually
use into your bundle and not export them. However, you have to make sure these
classes never are visible in the API. For example ...
I have a aQute.service.reporter.Reporter interface that is used for reporting
progress, errors, warnings, etc to users. I have a
aQute.lib.reporter.ReporterAdaptor that implements this interface. Whenever I
have a class that does reporting I often extend ReporterAdapter since this is
just awfully convenient. However, I do not require a support bundle (which
often become dependency hell) since the aQute.lib.reporter package is
automatically included in my own bundle.
Interestingly, this was how ar(chive) files worked with C. We had a period
where we turned to dynamic linking but it is interesting to see how are moving
back to solutions that carry all their dependencies (WARs, Apple App store,
Microsoft, etc) since the dependency management can get quickly out of hand.
However, you obviously have to use bnd(tools) ...
Kind regards,
Peter Kriens
On 29 jan. 2013, at 12:41, erwin dl wrote:
> I often encounter situations where a certain class ClassA in a bundle A
> depends on a class ClassB in a bundle B, and where ClassB is a subclass of
> ClassC in a bundle C.
>
> So it is logical that bundle B has a dependency on bundle C.
>
> But to get the things compiled and working, I am forced in such a situation
> to also add an explicit dependency of bundle A on bundle C.
> Even when not directly referring to the base-class in my ClassA...
>
> At least this is true in eclipse's PDE.
> But in internal discussions here, it seems to be perceived as an inevitable
> fact, independent of eclipse or equinox implementation choices...
>
> I would prefer that the implementation decision of ClassB, to inherit part of
> its stuff from ClassC, i.o. implementing it directly itself, would be hidden
> for ClassA and bundle A.
>
> I.e. it is not a situation where a kind of API is provided in bundle C, and
> where bundle A would better use the API, and where bundle B provides
> implementations as services etc.
> It's a simple class-hierarchy set-up that exposes implementation decisions
> and forces dependents to add a-priori "unnecessary" extra dependencies...
>
> If someone has advice or ideas on this, I would be very interested to
> hear/learn from them!
>
> Many thanks,
> erwin
>
>
> _______________________________________________
> 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
