Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-user] Testing plug-in's without using single test-bundles

I don't like the lib/*.jar approach with OSGI, I think it's misusing OSGI.
I prefer the x-internal/x-friend as it's restricted to tests bundles.


On Mon, Dec 23, 2013 at 3:01 PM, Paolo Bazzi <paolo@xxxxxxxxx> wrote:
Hi Igor (& other interested)

Thanks for your input! We also thought about the breaking OSGi visibility approach, but since very a lot of internal classes are tested, we would need to mark a huge number of packages with x-internal/x-friend.

Finally we used the following approch:

3) Add the necessary eclipse target platform plugins as plain-maven dependency to the plain-java test project
- The target platform information is duplicated, once in the target platform for the tycho build, and once in the maven dependency list of the test project (executed with plain maven-surefire)
- The target platform bundles are deployed twice in the artifactory, once as target platform p2 archive, and once as maven dependencies (plugin+POM)

Unfortunately additionaly to the mentioned disadvantage about the target platform jar's, we also found out, that we need to add each third-party dependency twice. For example the apache-commons-math dependency had to be added once in the productive plugin A (jar in lib folder, and referenced in manifest as bundle-classpath) and once as maven dependency in the test-project POM. We found no other way to get the test project compiling.
Basically the test project is not recognizing the jar file included in the Eclipse plugin A, since it is an Eclipse-dependency and not a Maven one. But on the other hand, if I add the library as Maven dependency in the plugin A and remove the jar from the lib folder, the Eclipse IDE is not able to compile the project, since the library is missing (Maven dependencies are not resolved through M2E, if the  project has package-type eclipse-plugin.)

Our setup now looks like this (simplified):
- Parent POM
- Eclipse plugin A, package type eclipse-plugin, [apache-commons-math in lib folder, added to Manifest Bundle-ClassPath]
- Eclipse plugin B, package type eclipse-plugin
- Test Project, package type jar, Maven Dependency in POM to Plugin A and B and Maven Dependency to apache-commons-math.

Any suggestions?


Am 28.11.2013 15:25, schrieb Igor Fedorenko:

If you require direct access to internal classes from tests, fragments
are the only way to do this. If all your tests require access to
internal classes, then you will have to have one test fragment per host,
which should also have access to all host's other fragments, iirc.

If you are willing to break OSGi class visibility somewhat, bundles can
export internal packages with eclipse-specific x-internal/x-friends
Export-Package attributes. This will still give you warning/errors
inside IDE, which makes unwanted/unexpected classpath reference obvious
during development, but the packages will be accessible at runtime.

There is also middle-ground approach, where most of the tests can be
kept in single plain test bundle and a small number of test fragments
for tests that require access to internal classes.


On 11/28/2013, 8:19, Paolo Bazzi wrote:
That would correspond to my proposed solution 4, which requires to
create about 70 new fragments and splitting up the >4500 existing unit
Nevertheless, this approach would not work to test a fragment itself,
since a fragment cannot be a fragment of a fragment.


Am 28.11.2013 09:31, schrieb Sievers, Jan:
1) Converting the plain-java test project into a plugin test project

- In order to be able to test classes in internal packages, I have to
export every single package with x-friend:<my.test.plugin> notation and
have to repeat this procedure for each new tested package
Have you tried using test fragments instead?

tycho-user mailing list

tycho-user mailing list
tycho-user mailing list

tycho-user mailing list


"Legacy code" often differs from its suggested alternative by actually working and scaling.
 - Bjarne Stroustrup

Back to the top