search

hapifhir / org.hl7.fhir.core

Apache License 2.0
153 stars 155 forks source link

Maven dependency conflicts and classpath issues #1733

Open bpasson opened 1 week ago

bpasson commented 1 week ago

Not sure if these are bugs, but I ran into two issues:

First when analyzing the dependencies for hapi-fhir-base:7.4.0 I notice the following dependency conflict hapi-fhire-base:7.4.0 depends on hapi-fhir-base:6.4.1 as seen below. It all seems to work as maven in the end picks the 7.4.0 version, but does report a conflict. I would not expect such a circular reference, and if it is needed for some reason to at least have it be the same version.

ca.uhn.hapi.fhir:hapi-fhir-base:7.4.0 
       |
ca.uhn.hapi.fhir:org.hl7.fhir.core:6.3.11
       |
ca.uhn.hapi.fhir:hapi-fhir-base:6.4.1

Furthermore ca.uhn.hapi.fhir:hapi-fhir-validation depends on org.ogce:xpp3 which includes the class javax.xml.namespace.QName. This clashes with the same class shipped with the the JVM (21). To make it work I had to replace the org.ogce:xpp3 dependency with xpp3:xpp3_min.

I hope you have the time to take a look at these and see if they are fixable.

dotasek commented 1 week ago

@bpasson The circular dependency is a legacy issue that we are aware of, but have not had dedicated time to address.

I will try to prioritize an update to HAPI 7.4.0 to at least bring us up to the current release version, but this may take some time, as it has historically caused us issues.

In the meantime I can try replacing org.ogce with xpp3, as that is much more limited in impact.

bpasson commented 1 week ago

@dotasek I haven't experienced any issues so far with using xpp3:xpp3. Both artifacts are pretty old though and haven't received any updates in years. To prevent any future API issues it might be a good idea to switch to java.xml.stream.XMLInputFactory. Not sure how big the impact is, but it is part of the core Java API and better maintained. It was added in Java 6, so it should not hurt to many users.