You can also look at the log4j-osgi module. It does. It does some load testing for log4j's own budles. Gary
On Feb 9, 2018 21:21, "Simon Spero" <sesunc...@gmail.com> wrote: > Writing tests for osgi modules is painless... the second time :-P > > The key to making tests easy is to use pax-exam, which handles most of the > tedious container setup and junit / test-NG test execution. > > https://ops4j1.jira.com/wiki/spaces/PAXEXAM4/pages/54263870/Documentation > > I can implement this if OSGI related changes are wanted. > > Simon > > On Feb 7, 2018 5:10 AM, "Stefan Bodewig" <bode...@apache.org> wrote: > > > On 2018-02-07, Jochen Wiedmann wrote: > > > > > On Wed, Feb 7, 2018 at 9:54 AM, Stefan Bodewig <bode...@apache.org> > > wrote: > > > > >> I know I asked before (I really am not an OSGi guy at all) and was > > >> pointed into a direction for writing a test that would start a small > > >> container and load the bundle. This should help, but unfortunately the > > >> very idea slipped further and further down my priority list. > > > > > Well, if *you* are having trouble here, that's bound to happen for > > > others, too. And, I don't know how they would implement that, > > > internally, but as it's their topic, I clearly have the expectation, > > > that *they* provide something useful. > > > > I'd be content with having a regression test, although I'm not sure how > > involved it would get. This time the Import-Package value was > > syntactically incorrect, this might get caught by static analysis. Last > > time I stripped an Import-Package (the one for XZ when I added the > > Brotli dependency IIRC), so the manifest was valid but you have been > > unable to use the algorithms provided by XZ. This is a runtime issue > > that really requires a test, I guess. > > > > > Btw: Would org.apache.felix:maven-bundle-plugin:3.5.0:verify have > > > spotted the problem? > > > > At least not when I use it the naive way (this is based on the rel/1.16 > > tag: > > > > $ mvn org.apache.felix:maven-bundle-plugin:3.5.0:verify > > [INFO] Scanning for projects... > > [INFO] > > [INFO] ------------------------------------------------------------ > > ------------ > > [INFO] Building Apache Commons Compress 1.16 > > [INFO] ------------------------------------------------------------ > > ------------ > > [INFO] > > [INFO] --- maven-bundle-plugin:3.5.0:verify (default-cli) @ > > commons-compress --- > > [INFO] ------------------------------------------------------------ > > ------------ > > [INFO] BUILD FAILURE > > [INFO] ------------------------------------------------------------ > > ------------ > > [INFO] Total time: 0.625 s > > [INFO] Finished at: 2018-02-07T11:04:54+01:00 > > [INFO] Final Memory: 15M/605M > > [INFO] ------------------------------------------------------------ > > ------------ > > [ERROR] Failed to execute goal org.apache.felix:maven-bundle- > plugin:3.5.0:verify > > (default-cli) on project commons-compress: Execution default-cli of goal > > org.apache.felix:maven-bundle-plugin:3.5.0:verify failed.: > > NullPointerException -> [Help 1] > > [ERROR] > > [ERROR] To see the full stack trace of the errors, re-run Maven with the > > -e switch. > > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > > > > with -X I only get a Maven internal stack trace. Same for the 3.4.0 > > version that is requested by commons-parent 43. > > > > TBH I don't want to dig deeper here as I really think we need runtime > > verification over static analysis. > > > > Stefan > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > >
