Metadata Mapping: Potential Blocker?

We discovered yesterday that the metadata mapping module is bundling it’s test classes within it’s omod, which is causing it not to start on one of our servers because it can’t find a “hamcrest” dependency. Not sure why this is only showing up on this one server (just I guess, but perhaps because it’s a older version of Tomcat?), but it seems clearly incorrect that the test classes are bundled in the omod.

I found the dependency that is causing the issue (and confirmed if I remove it, the module successfully starts on this server–though the tests don’t pass), but I’m not quite sure why the dependency is causing that behavior since it is scoped as “test”.

I’ve documented here… someone with a little more maven expertise than me should look at this before we sign off on including the latest version of metadata mapping in the next Ref App release.

@raff

Take care, Mark

Hmm… also just discovered that we were running Java 6 as well as Tomcat 6, where generally we are running version 7 of both. However, again, seems wrong that the the tests are bundled in the omod in any case.

Take care, Mark

I’ve run into a similar issue in the past and I recall posting on talk about it, seems like a general flaw in the generated pom file for the omod sub project by the module wizard, this execution in the pom file for omod sub project shouldn’t be there in the first place, it’s a duplicate step since the same resources files already get included as part of the build process of the api sub project. This issue can pretty much creep up in any module if you include the same module’s api test jar as a dependency of the omod sub project, this is necessary if you want to reuse the same test datasets for both sub projects and not duplicate them, and this is evident in the metadata mapping’s omod pom file here. I had to remove that entire execution from the casereport module and everything works just fine and I guess we should update the module wizard and remove it.

FYI, this is the same reason why there is always duplicate files at the root of the generated omods.