Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump org.hl7.fhir.core to 6.4.4 #6620

Open
wants to merge 40 commits into
base: master
Choose a base branch
from
Open

Conversation

dotasek
Copy link
Contributor

@dotasek dotasek commented Jan 14, 2025

No description provided.

Copy link

github-actions bot commented Jan 14, 2025

Formatting check succeeded!

@madduci
Copy link
Contributor

madduci commented Feb 26, 2025

Hi and thanks for your effort.

Wouldn't be better to target directly the 6.5.x Version of Core Libraries (currently at 6.5.11)?

It seems that there are some breaking changes and the Validator isn't working anymore:

Caused by: java.lang.NoSuchMethodError: 'void org.hl7.fhir.validation.instance.InstanceValidator.<init>(org.hl7.fhir.r5.context.IWorkerContext, org.hl7.fhir.r5.fhirpath.FHIRPathEngine$IEvaluationContext, org.hl7.fhir.r5.utils.XVerExtensionManager)'
	at org.hl7.fhir.common.hapi.validation.validator.ValidatorWrapper.validate(ValidatorWrapper.java:123)
	at org.hl7.fhir.common.hapi.validation.validator.FhirInstanceValidator.validate(FhirInstanceValidator.java:241)
	at org.hl7.fhir.common.hapi.validation.validator.BaseValidatorBridge.doValidate(BaseValidatorBridge.java:23)
	at org.hl7.fhir.common.hapi.validation.validator.BaseValidatorBridge.validateResource(BaseValidatorBridge.java:59)
	at org.hl7.fhir.common.hapi.validation.validator.FhirInstanceValidator.validateResource(FhirInstanceValidator.java:28)

@dotasek
Copy link
Contributor Author

dotasek commented Feb 26, 2025

@madduci Ideally, yes, we should be targeting 6.5.11, and that is the eventual goal.

When doing bumps of this library in the past, I have encountered cases where there are many breaking changes in the underlying logic. These can cause many test failures. In the worst cases, the breaking changes may even interact.

Incrementing in smaller jumps is an attempt to manage a minimal amount of changes in one PR. I have found this safer and easier to review.

@tadgh, I've been using this approach for some time now, and you've reviewed a few of these. Do smaller increments still seem reasonable?

@madduci
Copy link
Contributor

madduci commented Mar 4, 2025

@dotasek I am trying to upgrade to 6.5.13 to use the latest bugfixes from the core library, here: #6769

I've found that some of your changes made in the Parser are useful also for the newer version.

@dotasek
Copy link
Contributor Author

dotasek commented Mar 4, 2025

@madduci I'm happy that you are maintaining your own PR, and will be happy to review it once it passes tests.

Please be aware that this PR is not complete. It still fails many tests, and I am still trying to fix them. Keep this in mind when you develop your own.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants