We discovered today that many of our modules have some build configuration in their pom that causes classes and resources from the api (and sometimes from api tests) to be included in the omod directly in addition to be included in the lib jar.
This has the potential to cause problems and could certainly lead to odd and unexpected behavior, and I expect it is something we review and correct in as many modules as possible.
To see this problem, build any module you like from source and then open up the omod to view the files inside of it. You will find many artifacts from the api project inside.
This is by design for some resources - namely message properties, application context xml (and possibly liquibase.xml and hibernate mapping files) are expected to be present here by the OpenMRS module factory when loading in modules. However, the implementation of this in the best of cases is done by including all *.properties and .xml files, and in the worst of cases by including all */ files, which means that far more files are included than intended. In the case of **/, it means that all of the compiled class files in the api jar are also included directly in the classes of the omod - two instances of each within the omod in total.
In most cases, this is not leading to any issues (we’d have noticed this far earlier if so), but there are likely cases where this is leading to strange behavior that we haven’t been able to track down. It certainly leads to omod artifacts that are bigger than necessary.
Just taking the coreapps module as an example, the problematic line is here:
This “includes” configuration needs to be narrowed to specify just the resources that should be copied into the omod from the api jar.
@dkayiwa / @mogoodrich / @mksd - thoughts about fixing more widely?