| Re: [platform-ui-dev] Policy of the Platform projects with regards to tests accessing non-public members |
First, Require-Bundle is bad and we should always prefer Import-Package. The Require-Bundle stuff introduces more problems than it tries to solve.
Second, test fragments are fine for white box testing in an OSGi context. Test plugins are used for black box and integration testing. So IMHO it would be also ok to add a new test fragment for the white box tests you want to introduce and keep the current test plugin to keep the integration test capability.
@Mickael
Whenever you introduce a dependency to a fragment and need to use Eclipse-ExtensibleAPI you are using fragments in the wrong way and should reconsider your bundle structure. In the case of adding a test fragment there should definitely no dependency to the test fragment.
On 03/08/2016 09:21 PM, David M Williams wrote:
I'd like to suggest a slightly different approach. Instead of "adjusting the test project" that it might be easier to "add a new test bundle as a fragment".+1 with what David days. It also seems easier to me to *add* a fragment and maybe move some individual tests in it than to refactor everything.
Perhaps this will not work for what you had in mind? But if so, I am suggesting it since most of our tests fit into the "Test Runner" framework (and ran on different platforms, after the build).
While I am sure the fragment approach could be made to work in that case too, in sounds like a larger change, and a larger amount of work to "confirm all the old stuff is working" instead of
simply making sure the new stuff is working.
Just a suggestion -- if it makes things easier.
Also, a drawback of fragments, to consider when moving a class to a fragment, is that it becomes impossible for other bundles to reference a fragment via Require-Bundle, but can still use Import-Package (although this require to add an Eclipse-ExtensibleAPI tag in host MANIFEST.MF http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fbundle_manifest.html )
_______________________________________________
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