| Re: [tycho-user] Testing plug-in's without using single test-bundles |
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
Disadvantages:
- 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?
Regards,
Paolo
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.
--
Regards,
Igor
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
tests.
Nevertheless, this approach would not work to test a fragment itself,
since a fragment cannot be a fragment of a fragment.
Paolo
Am 28.11.2013 09:31, schrieb Sievers, Jan:
1) Converting the plain-java test project into a plugin test projectHave you tried using test fragments instead?
Disadvantages:
- 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
Jan
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tycho-user
tycho-user mailing list
tycho-user@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tycho-user
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tycho-user