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?

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

"'Cross project issues'" <cross-project-issues-dev@xxxxxxxxxxx>
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
Wednesday, February 02, 2011 1:17 PM
Cross project issues
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
Sent by:
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

cross-project-issues-dev mailing list

Back to the top