[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] Class visibility without declared dependency
|
On 7/20/13 10:46 , Stephan Herrmann wrote:
Hi,
In the old framework I could use the ClassLoaderDelegateHook
to make aspect classes visible to those base classes into which
I'm weaving calls to the aspect. This is necessary, because
only the aspect knows about its base, not vice versa.
For Luna with the new WeavingHook all I can see is
wovenClass.getDynamicImports().add(somePackage)
This does, however, not work for packages that are not exported
from the aspect bundle. In fact most of the aspects are never
exported, because they're not meant to be called from source code.
If you manipulate some bundle's code and that code ends up with a
dependency on some other external code, you might as well accept the
fact that it does become a true run-time dependency (i.e., a dynamic
import) of the manipulated bundle. It doesn't make sense to pretend that
it isn't a dependency just because the dependency was introduced at run
time. The framework has to handle it like any other dependency.
If you want to avoid that other bundles import the package in question
without knowing that they shouldn't, then just introduce a mandatory
attribute on the exported package.
Additionally, in the old hook I had the option to expose individual
classes, not packages. I didn't yet use this power, but to enforce
that the synthetic dependency is indeed only ever used for the
synthetic aspect calls this would be valuable in the future.
So if a class-based mechanism is available I'd always prefer that
over a package based mechanism.
Any ideas how I could make this work in the new framework?
In OSGi, the atomic unit of dependencies is the package, there is no
other way. The only wiggle room is with the include/exclude directives
on an export, but that isn't exactly the same.
-> richard
Thinking more about it, in the future I _could_ request that
aspects actually declare the corresponding base as x-friends, but
(a) this is redundant information, easy to run out-of-sync, and
(b) it would be an incompatible change, and
(c) I don't know how the runtime could detect when a package added
to dynamic imports is *not* exported.
Thus, if there's any way around this, I certainly prefer *not*
to require such x-friends export at source level. If that could
be added on-the-fly this might be another viable solution.
thanks,
Stephan
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
