Latest artifacts are not in maven central

[nvokrri]

Currently, the latest version of this project that is available in maven central repository is 5.4.0, which is 3 major versions behind the latest one.

This was reported in #375 (CC @jkiddo / @markiantorno, we share the same sentiment with the original request), but seems that it got abandoned even after some work had started. Are you still in agreement that the artifacts of this repo should be published to maven central?

[jkiddo]

I've might changed my mind a bit on this matter. How would this project makes sense as a maven artifact?

[nvokrri]

@jkiddo
I've might changed my mind a bit on this matter. How would this project makes sense as a maven artifact?

I had landed on this repo from the webpage link at: https://hapifhir.io/hapi-fhir/docs/server_jpa/get_started.html

My impression is that the purpose of this project is to offer an easy way to boot the server that is wired with a configured database, rather than having users provide their custom data layer. The main intention behind using it as a dependency would be to plug in authentication/authorization checks to all endpoints. Does this usage make sense to you, or perhaps you see other alternatives?

[XcrigX]

@jkiddo
I've might changed my mind a bit on this matter. How would this project makes sense as a maven artifact?

I had landed on this repo from the webpage link at: https://hapifhir.io/hapi-fhir/docs/server_jpa/get_started.html

My impression is that the purpose of this project is to offer an easy way to boot the server that is wired with a configured database, rather than having users provide their custom data layer. The main intention behind using it as a dependency would be to plug in authentication/authorization checks to all endpoints. Does this usage make sense to you, or perhaps you see other alternatives?

I think the way most people would accomplish that is by forking this project and then adding the security layer you desire onto your fork. As stated in the original issue, that can be labor intensive to keep it up to date as you need to pull/merge changes. However - there were some features added to this project since the original issue which make this a bit easier as you can now register custom beans/interceptors via configuration without needing to alter the core code in this project (i.e. fewer merge conflicts) - see: https://github.com/hapifhir/hapi-fhir-jpaserver-starter?tab=readme-ov-file#adding-custom-interceptors

You'd still need to manage merge conflicts with the POM file if you are adding Spring Security or other dependencies, but..
This also gives the advantage that you can run the original unit tests in the project with your custom changes.

NOTE: I don't have a strong opinion on making this a maven artifact you can just import - it seems weird to me, but I guess it could work?

[nvokrri]

@jkiddo
I've might changed my mind a bit on this matter. How would this project makes sense as a maven artifact?

I had landed on this repo from the webpage link at: https://hapifhir.io/hapi-fhir/docs/server_jpa/get_started.html
My impression is that the purpose of this project is to offer an easy way to boot the server that is wired with a configured database, rather than having users provide their custom data layer. The main intention behind using it as a dependency would be to plug in authentication/authorization checks to all endpoints. Does this usage make sense to you, or perhaps you see other alternatives?

@XcrigX
I think the way most people would accomplish that is by forking this project and then adding the security layer you desire onto your fork. As stated in the original issue, that can be labor intensive to keep it up to date as you need to pull/merge changes. However - there were some features added to this project since the original issue which make this a bit easier as you can now register custom beans/interceptors via configuration without needing to alter the core code in this project (i.e. fewer merge conflicts) - see: https://github.com/hapifhir/hapi-fhir-jpaserver-starter?tab=readme-ov-file#adding-custom-interceptors

You'd still need to manage merge conflicts with the POM file if you are adding Spring Security or other dependencies, but.. This also gives the advantage that you can run the original unit tests in the project with your custom changes.

NOTE: I don't have a strong opinion on making this a maven artifact you can just import - it seems weird to me, but I guess it could work?

Thank you and yes, we share the same sentiment with the original poster about maintaining a fork.

This issue was raised because by offering this project as a dependency/blackbox, users (we) will still be able to plug-in custom interceptors without having to create custom CI workflows, and upgrading the version will [in most cases] be as simple as changing a version in pom.xml/build.gradle, wouldn't you agree?

[XcrigX]

One caution - updates to the upstream HAPI project frequently come with DB schema updates that must also made.
These updates (officially) need to be "manually" applied to your database using a CLI tool . I state this because it isn't necessarily as simple as just setting up a CI job to update your server to the latest version, even if you did get the HAPI JPA project as a Maven artifact. For me it tends to be an intentional process and merging some updates is the usually least of the effort.

You can see this thread for some more context on running CLI db migration tool as a deployable service rather than strictly a CLI :
https://chat.fhir.org/#narrow/channel/179167-hapi/topic/HAPI.20database.20migration.20options/with/492190374