Hi, John,
In this particular case, it's debug.ui and dsf.ui. I guess I just
assumed that this was normal ... :-)
If CDT does intend that packages always be exported, then I can submit
a bug (with a patch, of course).
Thanks!
Christian
On 17/03/10 03:36 PM, John Cortell wrote:
I don't think that was intentional. All packages in CDT
plugins should be
exported (though internal/provisional ones should be hidden from
downstream plugins). Which plugin are you seeing non-exported packages
in?
John
At 02:32 PM 3/17/2010, Christian Damus wrote:
Content-Type:
multipart/alternative;
boundary="----_=_NextPart_001_01CAC608.93C08184"
Content-Class: urn:content-classes:message
Hi,
As I understand it, the recommendation from the Equinox experts at
Eclipse is that bundles should export all internal packages, using the
x-internal attribute if desired, even though they aren't constituents
of
the bundle's API and are not intended for use by down-stream
components. The rationale for this recommendation is that those who
want to shoot themselves in the foot, or assume the extra burden of
software maintenance, should at least have the opportunity to do
so.
The Eclipse Platform project actually makes this policy for the
SDK:
http://wiki.eclipse.org/Export-Package
I am looking at some extensions to the CDT Debug UI, assessing the
impact
of migrating to Helios M6. In the replacement of the old
Disassembly View by the DSF implementation, some APIs seem to have
moved
into packages that are not exported, so they are inaccessible. This
makes it difficult to do a quick port to get up and running again
(obviously, I should strive for a longer-term solution).
What does the CDT committer team think of adopting a policy similar to
Eclipse Platform, and exporting all packages in all bundles all the
time?
Thanks,
Christian
--
Christian W. Damus
Software Developer, IDE Team
QNX Software
Systems
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
