Hi, Am 23.04.2018 um 22:21 schrieb Stefan Bodewig: > Hi all > > I'm trying to resolve COMPRESS-443 which talks about having a regression > test that fails if we break the OSGi bundle again (has already happened > three times duing the life of Compress so far). But unfortunately I'm > getting stuck with my limited Maven and even more limited PAX Exam Fu. > > You can see what I've tried in the COMPRESS-443 branch: > https://github.com/apache/commons-compress/tree/COMPRESS-443 > > The OsgiITest I've added loads the SNAPSHOT version I've installed into > my local repo last and doen't care about the current classes and POM, > which is quite understandable as the bundle hasn't even been built when > I try to run the test. > > Do I have to create a separate maven project just for the tests? If so, > I'll probably just drop the very idea as turning compress into a reactor > build just for a single test case feels wrong. > > I really hope I am missing something obvious. This has been true often > enough that I'm optimisitic :-)
at work we used PaxExam to test OSGi-based applications consisting of multiple modules. Here the (integration) tests have always been in a separate module as they require a more complex setup. To have only a single module, maybe it would work to run the test in the verify phase and reference the artifact via PaxExam's streamBundle() option directly from the file system? We could also think about having a separate Commons-internal project that contains OSGi-related tests. Such tests are useful for most of our components, and we could even test whether they collaborate correctly in their current versions. Well, this is certainly not trivial. Oliver > > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
