A healthcare customer wants to use hospital system data, which includes code that was developed...

Reusable Java libraries should be managed as Maven dependencies, not manually embedded or referenced through arbitrary filesystem locations. Installing the legacy library artifacts into an accessible Maven repository and declaring their Maven coordinates in the application's pom.xml gives the Mule project a deterministic and maintainable dependency model.

Mule applications use Maven as their build/dependency-management mechanism. MuleSoft's external-library guidance supports adding dependencies through Maven coordinates or local library artifacts, with those dependencies represented in the project's POM. This enables consistent resolution during development and CI/CD builds and avoids environment-specific hard-coded JAR paths.

Directly referring to JAR files from application code creates brittle coupling to local filesystem structure. Supplying libraries manually only at deployment time also weakens reproducibility because the application build no longer fully declares its dependencies. Re-creating existing Java integration logic within every Mule application defeats reuse and adds unnecessary maintenance.

Once the Java library is available as a Maven dependency, the Mule Java Module or an appropriate custom module can invoke its functionality while Maven manages versioning and packaging.

Reference topics: Maven dependency management; reusable Java libraries; external libraries; pom.xml; Java Module integration.

Official documentation: https://docs.mulesoft.com/anypoint-code-builder/acb-external-libraries

===============================================================