Re: [ide-dev] Policy of the Platform projects with regards to tests accessing non-public members
I don't know the answer for Platform projects, but CDT for example has
tests that are in a separate plug-in. The main plug-in simply declares
the packages as "x-friends" of the test plug-in instead of internal.
This means there is no limitation.
e.g. see how org.eclipse.cdt.dsf.gdb.internal is declared.  The
org.eclipse.cdt.dsf.gdb.internal package is used from the
-- snip --
Therefore there is no need to change it to a fragment.
Kichwa Coders Ltd.
On 8 March 2016 at 13:17, Bruno Medeiros <bruno.do.medeiros@xxxxxxxxx> wrote:
> I've started recently my first attempt at a big functionality patch for an
> Eclipse Platform project. Previously I've only submitted very small, trivial
> Whilst beginning to write tests for this functionality, I've noticed that
> nearly all platform.ui and platform.text *test* plugins are separate
> plugins, and not plugin-fragments of the plugin being tested. This makes it
> impossible for the test code to directly access non-public members of the
> plugin being tested (see
> This severely limits the usefulness/potential of what the tests can do, so
> I'm wondering, is this some official code policy of the Platform projects,
> is there some limitation prevent them from being converted to fragment
> bundles, or did simply no one got around to doing it?
> Would then a patch to change a test bundle to a fragment be accepted? The
> tests I'm writing need access to non-public plugin members. (of
> org.eclipse.core.filebuffers , if you're wondering)
> Bruno Medeiros
> ide-dev mailing list
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit