as part of updating our jetty development setup I found that we declare openmrs-core dependencies without specifying that they are provided which causes jetty to find them multiple times on the classpath.
These are
javax.servlet.jsp-api
taglibs.request
taglibs.response
taglibs.standard
taglibs.page
by adding mavens provided scope this issue is solved. I will add the missing scope as these libs have to be provided by the container the openmrs.war is deployed to.
Taglibs have been added back in TRUNK-4789, it has been mentioned that modules depend on some dependencies transitively, which I think is a bad habit we have, we should be explicit in what we depend on.
What I am wondering is why are they even in openmrs-core and not for example in the legacyui module? They are declared as dependencies in the web module but we do not have jsps/taglibs anymore in core. Is it because we still provide the possibility of deploying an openmrs module with jsps into a deployed openmrs.war without the legacyui?
I vaguely recall that these were kept in openmrs-core because it was somehow tricky to move them to the legacyui module, and we just ran out of time to do more.
This is just a guess, but maybe it’s because this allows modules which use JSPs and whose minimum OpenMRS version is <2.0 to just work without explicitly requiring the legacyui module. (E.g. we would not want the reporting module to have to jump through hoops to work against 1.x and 2.x versions of openmrs-core.
I agree that in theory openmrs-core should not be including/providing web libraries, and you certainly have my encouragement to explore if we can remove them in a way that’s not too painful (e.g. doesn’t require every single 1.x-era module to be actively upgraded to work with openmrs-core 2.x + legacyui).
