Re: [ide-dev] Policy of the Platform projects with regards to tests acce

[Bruno Medeiros <bruno.do.medeiros@xxxxxxxxx>]

There is still a big limitation with x-friends. x-friends exposes the public types/members of an otherwise internal package to the friend plugin. However, you still cannot access non-public types/members, such as those declared protected or package-private. (Note that "protected" also grants package-level visibility access, not just access to subclasses: https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html). More precisely, you can't get package-level access.

So for example, if you have this code in the main plugin:

    public class Foo {
        protected void blah() {
        }
    }

with a plugin fragment you can write this code (if the code is in the same package as Foo):

    new Foo().blah();

And, that case is very useful for writing tests.
However with x-friends it doesn't work. Note, you won't get an error in the IDE workbench! So it appears to work, but when you actually run the code, you get an IllegalAccessError. This is because OSGi considers a package from one bundle to be different from a package of another bundle, even if the package has the same name.

On 8 March 2016 at 13:24, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:

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,
 org.eclipse.cdt.dsf.gdb.actions,
 org.eclipse.cdt.dsf.gdb.breakpoints,
 org.eclipse.cdt.dsf.gdb.internal;
  x-friends:="org.eclipse.cdt.debug.gdbjtag.ui,
   org.eclipse.cdt.dsf.gdb.ui,
   org.eclipse.cdt.tests.dsf.gdb,
   org.eclipse.cdt.examples.dsf.gdb",
 org.eclipse.cdt.dsf.gdb.internal.commands;x-friends:="org.eclipse.cdt.dsf.gdb.ui",
 org.eclipse.cdt.dsf.gdb.internal.memory;x-internal:=true,
 -- snip --

[1] https://git.eclipse.org/c/cdt/org.eclipse.cdt.git/tree/dsf-gdb/org.eclipse.cdt.dsf.gdb/META-INF/MANIFEST.MF#n21
[2] https://git.eclipse.org/c/cdt/org.eclipse.cdt.git/tree/dsf-gdb/org.eclipse.cdt.tests.dsf.gdb/META-INF/MANIFEST.MF#n17

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

Jonah
~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com

On 8 March 2016 at 13:17, Bruno Medeiros <bruno.do.medeiros@xxxxxxxxx> 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
> https://rcpquickstart.wordpress.com/2007/06/20/unit-testing-plug-ins-with-fragments/
> ).
>
> 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
> https://twitter.com/brunodomedeiros
>

> _______________________________________________
> ide-dev mailing list
> ide-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/ide-dev
_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ide-dev

--

Bruno Medeiros
https://twitter.com/brunodomedeiros