Posted on Oct 29

Integrating Modules from Other Projects into a Project

Read the original article：Integrating Modules from Other Projects into a Project

Problem Description

There are two sibling projects A and B. The goal is to package and use a module from Project B inside Project A.

Background Knowledge

The project-level build-profile.json5 lists project modules: each item specifies the module name, its srcPath, and its build targets.
Dependencies are declared in oh-package.json5 under dependencies (runtime) or devDependencies (development). You can reference:
- Remote third‑party packages,
- Local folders,
- Local HAR/HSP artifacts.
HSP (Shared Package) is the recommended library type for sharing ArkTS/ETS code and resources across modules/apps.

Troubleshooting Process

Confirm directory layout

/parent ├─ A/ └─ B/

2.Check library type in Project B

Ensure B contains an HSP module (e.g., library) that builds successfully on its own.

3.Verify module registration in A

In A’s build-profile.json5, confirm B’s module is listed with the correct relative srcPath and a target that applies to A’s product:

{ "modules": [ { "name": "entry", "srcPath": "./entry", "targets": [{ "name": "default", "applyToProducts": ["default"] }] }, { "name": "library", // must match module name in B "srcPath": "../B/library", // relative to A "targets": [{ "name": "default", "applyToProducts": ["default"] }] } ] }

4.Verify dependency wiring in A

In A/entry oh-package.json5, add the local dependency pointing to B’s module folder:

{ "name": "entry", "version": "1.0.0", "dependencies": { "library": "file:../../B/library" // key should align with library package name } }

5.Re-sync & build

Sync in DevEco Studio → Clean/Rebuild A.

6.If issues persist, check common pitfalls

Wrong srcPath or file: path (relative paths from A).
Module/package name mismatch between modules[].name and dependency key.
Missing targets.applyToProducts mapping the active product (e.g., "default").
Incompatible compatibleSdkVersion / runtimeOS between A and B.
Using HAR when HSP is expected (or vice versa).

Analysis Conclusion

Failures typically stem from path or naming mismatches, unregistered module targets, or incompatible SDK/product settings.

Correctly registering B’s HSP module in A’s build-profile.json5 and wiring a matching local file: dependency in oh-package.json5 resolves the packaging/linking errors.

Solution

Keep A and B as siblings.
In B, create/confirm an HSP module (e.g., library).
In A:
- Add B/library to build-profile.json5 → "modules" with a correct relative srcPath and targets.
- Add a local dependency in A/entry oh-package.json5:

"dependencies": { "library": "file:../../B/library" }

Re-sync and build A.

Verification Result

Build of A succeeds in debug and release.
Code from B/library is importable/usable in A/entry.
Final HAP produced by A contains the library content (expected classes/resources available at runtime)