Community
Participate
Working Groups
Build-ID: 0.9.0 / master as per 17-Oct-2011 Most MANIFEST.MF in Linuxtools export their "internal" packages without specifying the OSGi ;x-internal:="true" directive. This is a problem for development, because API tooling can't be applied properly, since it won't know the difference of what is API versus what is internal. This, in turn, is a major problem as Linuxtools strives for an 1.0 release ... adding the "x-internal" directive after an 1.0 release would virtually remove API and thus not be acceptable. In fact I noticed the problem because with a 0.8.1 Linuxtools baseline set in Preferences > PDE > API Tooling, removal of methods from internal MassifToolPage was reported as an error (although it's not an error since that class is internal). Suggestions: 1.) As per 0.9.0, Linuxtools should add the missing ;x-internal:="true" directives for all internal packages exported in MANIFEST.MF 2.) After 0.9.0, all Linuxtools committers should be required to specify an API baseline in their Preferences, such that problems like this are detected early enough.
PS for some of the exported internal packages, an ;x-friends:="bundle..." might be needed in order to give visibility to other valgrind bundles.
(In reply to comment #1) > PS for some of the exported internal packages, an ;x-friends:="bundle..." > might be needed in order to give visibility to other valgrind bundles. This is exactly what I was planning on doing. Using the PDE form editor, the package is either public (no OSGI directive) or it can be hidden except for specified packages. This ends up adding the x-friends directive (but no x-internal). If anyone has a need for some of the classes that were previously exposed, I would consider moving them to the public package if warranted.
Sounds good. FYI an x-friends implies x-internal for everyone who's not a friend.
Checking in patch for Valgrind core into master and stable-0.9 branch.
Setting target milestone.
