Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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. [1] The
org.eclipse.cdt.dsf.gdb.internal package is used from the
org.eclipse.cdt.tests.dsf.gdb plug-in[2].

Export-Package: org.eclipse.cdt.dsf.gdb,
 -- snip --


Therefore there is no need to change it to a fragment.

Jonah Graham
Kichwa Coders Ltd.

On 8 March 2016 at 13:17, Bruno Medeiros <> wrote:
> Hi,
> 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
> patches.
> 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
> ide-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit

Back to the top