[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] Class visibility without declared dependency
|
On 07/27/2013 07:45 PM, Neil Bartlett wrote:
I think that the Export-Package header is unsuitable for this, but
you're not necessarily back at square one. You should probably look at
the generic Provide-Capability header instead.
I admit I hadn't looked into that, but after some playing around
I'm not sure I understand how this would help for my case.
Remember, I need to create a wire between a static declaration
in an aspect bundle and s.t. that will be woven into base bundles
at load time. Given that WovenClass only allows to add dynamic
imports, package based imports seem to be the only capability
that I can use for this wiring. And then expressing a package
wire using Provide-Capability is even more restricted than Import-/
Export-Package as it doesn't allow me to add custom attributes.
The Eclipse extension registry is an instance of the "extender bundle"
pattern, and since around OSGi R4.3 it was decided that we should
generally try to use Provide- and Require-Capability to model the
pattern rather than either arbitrary manifest headers or resources
inside the bundle. Provide-Capability should support all of the
attributes that you want to express, and furthermore you can take
advantage of Require-Capability to create dependencies on those
capabilities/attributes. These dependencies would be visible to both
the OSGi Framework resolver and to other resolvers such as the OBR/R5
resolver Perhaps in the future p2 will support them too.
Are you saying that the content of a plugin.xml could also be
expressed as a set of Capabilities? I see a strong mismatch between
the rich structure of plugin.xml (defined by arbitrary xsd) and the
simplistic syntax of Capabilities. I must be missing s.t.
Do you have an example of how nested structures could be
migrated from plugin.xml to MANIFEST.MF?
FYI, the schema of our current extension point[1]
My current feeling is that MANIFEST.MF is probably the wrong place
to specify the information we need. So, the idea of avoiding
redundancy looks pretty dead to me.
thanks,
Stephan
[1]
http://git.eclipse.org/c/objectteams/org.eclipse.objectteams.git/tree/plugins/org.eclipse.objectteams.otequinox/schema/aspectBindings.exsd
