| Re: [platform-ui-dev] Policy of the Platform projects with regards to tests accessing non-public members |
> The Require-Bundle stuff introduces more
> problems than it tries to solve.
You know, that's a funny thing. At EclipseCon I attended a couple talks where people said you should never use Require-Bundle and a couple talks where people said you should always use it.
The argument against Require-Bundle was that you can get class name conflicts if you put identical jar files in two plugins with different names.
The argument against Require-Package was that it was much slower than Require-Bundle and slowed down startup time for large numbers of plugins.
If the performance claims are true (I haven't confirmed them), I have to say the argument in favor of Require-Bundle sounds much stronger. The name conflicts only occur if you don't use a consistent naming scheme so are largely only a theoretical problem (and even if it shows up, it can be fixed by applying a consistent naming scheme). But the performance problems were seen by end users in the real world and have no workaround.
- Stefan
Sorry to chime in late.
Existing plug-ins should not be converted to fragments as mentioned before. The ugly thing using a fragment is that it would have packages in it with no *.test.*in the name (in order to access the hidden members). If the amount of hidden members that you use is not high, you should consider to simply put the tests into the existing test bundle and use org.eclipse.text.tests.Accessorto access the hidden members.
Dani
From: Bruno Medeiros <bruno.do.medeiros@xxxxxxxxx>
To: platform-ui-dev@xxxxxxxxxxx
Date: 08.03.2016 15:21
Subject: [platform-ui-dev] Policy of the Platform projects with regards to tests accessing non-public members
Sent by: platform-ui-dev-bounces@xxxxxxxxxxx
[Reposting from the IDE-Dev mailing list]
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_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev