Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Is exporting all packages a best practice?

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.


- Konstantin



From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] 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 best practice?


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".



-----cross-project-issues-dev-bounces@xxxxxxxxxxx wrote: -----

To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
From: Eike Stepper <stepper@xxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
Date: 02/02/2011 03:34AM
Subject: Re: [cross-project-issues-dev] Is exporting all packages a best practice?

Am 02.02.2011 10:17, schrieb Daniel Megert:
>>> See
>> Thank you, Dani. That may be what I was looking for.
>> But it does not explain the difference between or consequences of:
>> 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 warns
> them (discouraged access) when they use a type from such a package. During
> runtime, it allows that in non-strict (i.e. default) mode (see
> osgi.resolverMode runtime option) the types from an x-internal package can
> be loaded and hence clients can use types from non-API packages. If you
> don't add the non-API packages with x-internal to the manifest then any
> app using code from such a package won't even work in non-strict mode as
> the types would not be loaded by the class loader. Once you start in
> 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 agree now.

Is "x-internal" spec'ed in OSGi or is it an Equinox thing?



cross-project-issues-dev mailing list


Back to the top