Yep. Even in the Eclipse top-level project
which wrote that doc, it has been debated often. Introducing x-friends
was an attempt at a best of both worlds approach, but in the end we've
probably all been bitten by cases of consumers using internals and then
demanding/requesting some level of support. On the other hand, it's hard
to measure the community impact of closing the internals entirely. I updated
that wiki page to make it clear that is only one project's position.
<konstantin.komissarchik@xxxxxxxxxx> Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
02/02/2011 04:26 PM
Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
It would be worth pointing
out that there is debate on whether “export everything” is a good practice
or not. There are good arguments either way and I don’t think there will
ever be general consensus on this. I am not going to bother listing the
arguments as it is not my intention to re-start that debate. The referenced
wiki is the approach adopted by the Eclipse project and its subprojects,
but is by no means a final word on the subject.
Every project should discuss
this issue to make sure that all of the project’s committers are on board
with whatever approach is selected.
On Behalf Of Thomas Watson
Sent: Wednesday, February 02, 2011 1:17 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Is exporting all packages a
This is an equinox only feature. The
unfortunate consequence is that on another framework implementation the
x-internal (or x-friends) directives will be ignored and the package will
be exported with not option to run in "strict mode".
Am 02.02.2011 10:17, schrieb Daniel Megert:
>>> See http://wiki.eclipse.org/Export-Package
>> Thank you, Dani. That may be what I was looking for.
>> But it does not explain the difference between or consequences
>> a) exporting a non-API package as x-internal
>> b) not exporting it at all
> Adding x-internal helps your clients during development time as it
> them (discouraged access) when they use a type from such a package.
> runtime, it allows that in non-strict (i.e. default) mode (see
> osgi.resolverMode runtime option) the types from an x-internal package
> be loaded and hence clients can use types from non-API packages. If
> don't add the non-API packages with x-internal to the manifest then
> app using code from such a package won't even work in non-strict mode
> the types would not be loaded by the class loader. Once you start
> strict mode all types from x-internal packages won't load either.
Thanks again. I've also just verified that (you may laugh) and I fully
Is "x-internal" spec'ed in OSGi or is it an Equinox thing?