Hi Jiri, comments inline.
On 2.9.2015 10:40, Jiri Holusa wrote:
Hi all,
we've been thinking for a while, how to test ISPN uber jars. The current status is
that we actually don't have many tests in the testsuite, there are few tests in
integrationtests/all-embedded-* modules that are basically copies of the actual tests in
corresponding modules. We think that this test coverage is not enough and more
importantly, they are duplicates.
The questions are now following:
* which tests should be invoked with uber-jars? Whole ISPN testsuite? Only
integrationtests module?
The goal is to run the whole test suite because, as you said, we don't
have enough tests in integrationtests/* And we can't duplicate all
test classes from individual modules here.
* how would it run? Create Maven different profiles for
"classic" jars and uber jars? Or try to use some Maven exclusion magic if even
possible?
Some time ago, we had discussion about this with Sebastian, who suggested that running
only integrationtests module would be sufficient, because uber-jars are really about
packaging, not the functionality itself. But I don't know if the tests coverage is
sufficient in that level, I would be much more confident if we could run the whole ISPN
testsuite against uber-jars.
Right. Uber-jars are about packaging but you don't
know that the
packiging is right until you try all the features and see that
everything works. There might be some classes missing (just for some
particular features), same classes in different packages, the
Manifest.mf might be corrupted and then something won't work in OSGi.
I'd prefer a separate Maven profile. IMO, exclusions are too error-prone.
Martin
I'm opening this for wider discussion as we should agree on the way how to do it, so
we could do it right :)
Cheers,
Jiri