[
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
|
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 project
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
Have you tried using test fragments instead?
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