[
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".
Tom
-----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 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 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?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
