♻️ refactor: rename toFHIR → Ignifyr and split the reactor into Community/Enterprise editions

[sinaci]

Consolidated rename + edition-split branch — both touch the same files, so they land together.

Rename (clean break): packages io.ignifyr.*, coordinates io.ignifyr:ignifyr-*, HOCON ignifyr.*, Docker srdc/ignifyr-*, docs; version → 2.0-SNAPSHOT. Legacy tofhir intentionally survives only in the srdc/tofhir-web image, the tofhir-redcap sibling service, the SwaggerHub link, and git history.

Edition split: the reactor is now module-separable into a public Community Edition (ignifyr-cli + engine/common/sql/file connectors, Apache-2.0) and a private Enterprise Edition (ignifyr-server + fhir-server/kafka/json/delta/streaming/scheduling/redcap/observability/terminology). Everything plugs in through the IgnifyrExtension ServiceLoader SPI — the engine never names a connector or format directly. A maven-enforcer bannedDependencies gate keeps enterprise-only libs out of community modules. Moving a feature between editions is a one-folder move with zero engine changes.

This is the module-level split only. Physical extraction to ignifyr-enterprise is Phase 2, not this PR.

Testing: mvn -B verify green. ⚠️ Requires JDK 11 — under JDK 21 the Spark reflective path surfaces as a spurious IllegalAccessError in ExtensionRegistrySpec; unsupported-JDK symptom, not a defect.

33 commits · 496 files · +18,952 / −11,381

[Okanmercan99]

Should we change tofhir-web:latest to ignifyr-web:latest?

[sinaci]

Once this image is pushed with its new name, yes we should change then.

[Okanmercan99]

spark.sql.extensions is a comma-separated list in Spark, and ExtensionRegistry has explicit
code to respect that — line 98 joins contributions from multiple modules instead of overwriting
them. But that merged value is thrown away here: ++ replaces on key collision, and the user's
spark { } block is merged last.

So if a user sets spark.sql.extensions for any unrelated reason (Iceberg, Sedona, a custom
optimizer rule), the value goes from

io.delta.sql.DeltaSparkSessionExtension          (contributed by ignifyr-format-delta)

to

com.example.MyExtension                          (user's value, Delta silently dropped)

The Delta session extension is then never registered, Delta sink writes fail, and nothing in the
error points back at the spark { } block that caused it.

Suggestion: keep the additive rule at this seam too — merge as today, then re-join that one key
from both layers:

val k = "spark.sql.extensions"
val merged = sparkConfDefaults ++ contributed ++ userConf
val joined = Seq(contributed.get(k), userConf.get(k)).flatten
               .flatMap(_.split(",")).map(_.trim).filter(_.nonEmpty).distinct
if (joined.isEmpty) merged else merged + (k -> joined.mkString(","))

Note this only applies to the list-valued key. Delta's other contribution,
spark.sql.catalog.spark_catalog, is genuinely single-valued, so a user override there is
legitimate and should keep winning as it does today.

[sinaci]

Yes, this is a valid problem, we can fix as suggested. If there are other list-valued config parameters other than "spark.sql.extensions", we should add them to "val k" as well.

[Okanmercan99]

The scaladoc promises "Force every registry to materialize — so a duplicate-registration error
surfaces at engine startup rather than in the middle of a job", but scheduler is not in the
list, and since these are lazy vals whose bodies contain the conflict check, not reading one
means not checking it.

So with two scheduling modules installed by mistake, the engine starts cleanly and looks
healthy. The IllegalStateException from singleCapability only fires later — at
MappingJobLauncher:91 when a scheduled job is first launched, or on the server at
ExecutionService:133 on the first query about scheduled executions.

Worth noting separately that streaming is covered only incidentally. The line that reads it,
IgnifyrEngine:65, exists to decide whether to start the archive timer:

if (ExtensionRegistry.streaming.isDefined) fileStreamInputArchiver.startStreamingArchiveTask()

Its fail-fast side effect is a coincidence. If that line is ever refactored, moved behind
another condition, or removed, streaming loses its duplicate protection silently — and no test
covers the path, so nothing would catch it.

Making the intent explicit here is a one-liner and removes both problems:

def init(): Unit = {
  sourceConnectors
  sinkProviders
  terminologyServiceProviders
  identityServiceProviders
  cliCommands
  schemaInferrers
  streaming
  scheduler
  ()
}

The other two registries are fine as-is and do not need adding: sourceFailureDescriptors is a
plain flatMap with no uniqueness check so it cannot throw, and sparkConfContributions is
already forced while the SparkSession is built at IgnifyrEngine:37, before this call.

[sinaci]

OK, I agree.

[Okanmercan99]

e.getMessage is a String, so this resolves to scala-logging's
error(message: String, args: Any*) overload rather than error(message: String, cause: Throwable).
The varargs form exists to fill {} placeholders, and this message has none (it is fully
s-interpolated), so SLF4J/Logback discards the argument instead of appending it. Logback's usual
rescue — treating a trailing extra argument as the exception — does not apply either, because the
argument is a String, not a Throwable.

Net effect: the log line records that a chunk failed, but nothing about why. No exception type, no
message, no stack trace:

ERROR StreamingSinkHandler - Streaming chunk resulted in error for project: proj-1,
job: job-7, execution: exec-3, mappingTask: patient-mapping

That is worse here than almost anywhere else, because this is the deliberate swallow path. The
module guide states the intent plainly — "catches per-micro-batch exceptions and only logs (the
stream survives bad chunks)" — so the exception goes nowhere else: it is not rethrown, the job is
not marked FAILURE, and the user is not notified. This log line is the only record of the failure
and the only diagnostic available afterwards. A streaming job can run for days quietly dropping
chunks and leave behind nothing but "something went wrong".

One-word fix:

logger.error(s"Streaming chunk resulted in error for project: ...", e)

Pre-existing — main has the identical line in SinkHandler.writeStream, so this is not a
regression from the extraction. Raising it because the code moves in this PR and the fix is
trivial. Note the sibling path at StreamingJobExecutor.scala:62 gets this right: it logs FAILURE
and rethrows, so there the exception does survive.