I’ve looked into this further and it seems like a limitation of the java compiler in PDE, not of OSGi itself. At runtime, your fragments should be able to load classes from each other.

This obviously doesn’t help much, though, unless you decide to write your unit tests using reflection :-)

As for the “friends” mechanism, you should know that this restriction is applied only in PDE. At runtime, your packages are exported in an unqualified way because OSGi does not honor the “x-friends” directive.

— Patrick

Thanks a lot for your answer. I’m still looking for a solution though… I’m not good with exposing all the classes I want to test due to some strict safety requirements I have to fulfil…
One solution would be to drop the fragment I have to test and make a plug in out of it. And have to original host plug in expose its components to the fragment as a friend plug in… But I’m still hopping…

Mircea

I just worked up some sample projects, and it appears that even after setting Eclipse-ExtensibleAPI: true in the bundle manifest, there is no visibility between fragments of the same bundle. There may be a way to do this, though, and you might want to ask in the Eclipse newsgroups.

A workaround would be to put just the fragment test cases in a regular bundle. Then the Eclipse-ExtensibleAPI setting will allow the fragment classes to be tested. Of course you’ll need to export the package in the fragment and you’ll only be able to test public classes/methods. Kind of backwards, I know, but it should work.

If you figure out a way to do this, let me know.

— Patrick

Unfortunately I’ve never been able to get test fragments working with PDE Build. There is an open Bugzilla entry on this, and maybe you could add a post saying that you’d be interested in a solution.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=181508

The more people that ask, the better.

Regards,

— Patrick

Your approach makes sense. The only alternative I see is to create some common test plug-in that could contain reusable test classes. This would eliminate the visibility leakage issue you have, but as you say it’s not really a big deal.

Thanks for posting this tip. I think it will help others trying to do fragment-based testing.

— Patrick

We’ve been using the fragment option for almost a year now. As you may recall you helped us to get our RCP app up and running. Anywho, in using fragments as containers for tests, I’ve found that it’s useful to have “Eclipse-ExtensibleAPI: true” in the manifest for the host plugin. By default this value is false. This allows fragments to contribute API to the host plugin and is useful if you want to provide utility classes and methods for testing that other test fragments can use.

For example:

ModelPlugin:
-SomeModel class

ModelTestPlugin:
-ModelTests class — extends TestCase and provides helper methods to create SomeModel objects
-SomeModelTest — extends ModelTests; just for completeness :]

PresentationPlugin:
-SomePresenter class

PresentationTestPlugin:
-SomePresenterTest class — extends ModelTests*

* Without specifying the “Eclipse-ExtensibleAPI: true” in the manifest for ModelPlugin, I would not be able to extend ModelTests in PresentationTestPlugin (would get compilation errors). Of course the disadvantage to this is that now PresentationPlugin is going to have visiblity to ModelTests, but that’s something I’m willing to live with. Perhaps there’s still a better way yet?

Cheers,
Nihal

Reference:
http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/bundle_manifest.html