[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Class visibility without declared dependency
- From: Stephan Herrmann <stephan.herrmann@xxxxxxxxx>
- Date: Fri, 26 Jul 2013 21:49:08 +0200
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
thanks for chiming in,
On 07/26/2013 11:42 AM, Martin Lippert wrote:
while re-working the aspectj weaving mechanics in Equinox Weaving a while ago we discussed this (with the AspectJ team) and came to
the conclusion that aspects should be exported to be woven into other bundles. Otherwise those aspects are internal to the bundle
only and not woven into other bundles.
I like this design decision because it makes the aspect part of the public API in case that this aspect affects other bundles. To me
it is a public API of that bundle (not being called directly, but being woven and therefore being called by those woven classes later).
I totally agree, I agree to that extent that when we first developed OT/Equinox
we decided to require a bundle-level declaration saying which team class may weave
into classes from which base bundle.
I'm not worried about specifying these things, we always required that, but now
we have to require this information in a redundant way (because our own declaration
are more fine-grained (class-level) than what OSGi uses).
If OSGi would support Export-Class we could simply augment that declaration
for our purposes :)
But I'll sure come up with a set of quick fixes to keep both declarations
in sync ...
Ah, and for internal adaptation: a team may declare as its base bundle: SELF.
Those obviously are not API the same way as you mention.