Stream: hapi
Topic: hapi 3.0.0 / R4 support
James Agnew (Aug 16 2017 at 14:42):
Hi All,
A few quick updates on what's going on at the HAPI FHIR project these days:
We have merged the HAPI 3 branch into master. This means a few things:
- Support for FHIR R4 (current draft) has now been integrated into the codebase
- We had previously been targeting calling the next version of HAPI FHIR version 2.6, but it will now be called 3.0.0
- If you have any code targetting version "2.6-SNAPSHOT", you should consider upgrading it to support "3.0.0-SNAPSHOT" instead.
It is important to note that 3.0.0 will be an API breaking change release. We have dropped support for FHIR DSTU1 and removed a bunch of legacy code, most notably the old Atom-based Bundle class and related methods on the parser and client.
There has been some reorganization of the library as well:
- The FHIR client code has moved out of hapi-fhir-base and into a new library called hapi-fhir-client (which you will need to manually add to your project if you are building clients)
- The FHIR server code has moved out of hapi-fhir-base and into a new library called hapi-fhir-server (which you will need to manually add to your project if you are building servers)
We have also moved a few classes into new packages. If you have code which suddenly starts complaining of missing classes when you upgrade to HAPI 3.0.0-SNAPSHOT, you should make sure that you have included the appropriate client or server JAR, and you should use your IDE's "organize imports" function to re-import various HAPI classes that may have moved.
You may be wondering why we are making these big annoying changes, moving things around: The deal is that HAPI has grown significantly in the last few years. When we started the project it was a simple parser and server project, but we are now contending with trying to support client apps, SMART apps, OSGi containers, Android development platforms, and various server platforms, all from a single code base.
The previous arrangement meant that (for example) Android users had to include a server framework in their apps even thought they would never use it, OSGi users had to use a special massive build with every single dependency included, etc. Our new arrangement modularizes the code base in order to make this easier.
Please feel free to reply to this email if you encounter issues when upgrading. I expect there will be pains we hadn't considered yet..
On another note, our public test server has been upgraded to include initial R4 support. The test endpoint is here:
On one final note, I should probably mention that I'm not as up to date on Zulip as I wish I was. Unfortunately the volume of requests coming in seems to be constantly keeping me underwater these days. If you have questions here that you can't find a resolution on, consider posting on the HAPI FHIR Google Group. There is a very active community there as well.
Cheers,
James
Uma Prasath (Nov 06 2017 at 03:54):
I upgraded my hapi fhir to dstu3 3.0.0 but LocationPhysicalType which was part of "org.hl7.fhir.dstu3.model.codesystems". But got an error could not find LocationPhysicalType enum. I couldnot find it in hapi-fhir-structures-dstu3-3.0.0. Could you please advise ? Also, upgrading to r4, i got a error saying that "could not find any HAPI-FHIR structure JARs on the classpath" error.
Last updated: Apr 12 2022 at 19:14 UTC