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?

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