hi julian no i didn't, because i don't think it makes sense to enforce a running mongoDB for being able to build oak-core. nor does it make sense to me to require a coverage that can only be reached with the derby-rdb profile enabled.
but now that you mention: this is for me another hint that the document store implementations should be moved out of oak-core rather sooner thank later. i recently looked at it and it seems doable with moderate effort. i recently had a discussion with marcel and he proposed that those really familiar with the document store code take care of that. an initial look reveal the following issues: - 2 classes have dependencies to indexing - several classes have dependencies to plugins.observation - usage of oak constants spread over multiple plugins. for these i would suggest to move constants that used outside of the scope of the plugins to a single utility in oak-core-spi kind regards angela On 11/05/17 12:49, "Julian Reschke" <[email protected]> wrote: >On 2017-05-11 12:05, Angela Schreiber wrote: >> hi oak-devs >> >> as a follow up to http://markmail.org/message/rzbqwwx3lilshct6 i would >> like to suggest that we enforce minimal test coverage not only with >> security modules but also for other oak code that is used in production. >> >> i gave it a try and identified those modules that already have a >>somewhat >> sensible coverage as this exercise IMO doesn't make sense for modules >>that >> are poorly tested. >> >> enforcing minimal coverage would mean that the module build will fail if >> the coverage is no longer met. >> >> the figures (computed yesterday) look as follows: >> >> - oak-jcr: 0.71 >> - oak-core: 0.75 > > ... > >To get coverage for oak-core, one should run with > >a) MongoDB running and > >b) Derby RDB profile. > >Did you try that? > >Best regards, Julian
