APAC is the Aussom Package Manager and you can read more about it in the APAC Usage Guide. It installs, removes, lists, searches, packages, and publishes Aussom packages. APAC itself works the same way on Aussom-Server as it does for the Aussom CLI - the commands, manifest format, lockfile format, and on-disk package layout are identical. This guide covers only the differences that matter when the consumer of the installed packages is a server hosting many apps, rather than a one-user CLI.
For the full set of apac commands (-s, -l, -i, -u, -p,
-pub, etc.), the manifest reference, and package authoring, read
the main guide first:
aussom/design/usage-docs/apac-usage.mdTwo things differ from the CLI:
/var/lib/aussom/modules/).
The server reads its global modules directory from config.yaml,
so each environment block (local, uat, prod) can pick its
own path.sudo. The server's
"global" directory is owned by whatever user runs the server,
so apac -i against it runs as that user.The on-disk layout inside each tier matches the CLI: every package
lives at <modules>/<name>/ with its package.yaml, optional JAR,
its .aus source files, and (for native packages) any platform
binaries.
The server registers two include paths on every app's engine before
the existing app-directory path. Resolution is "more specific wins":
a per-app copy of foo overrides a server-global foo of the same
name.
| Tier | Location | Scope |
|---|---|---|
| Per-app | <appDirectory>/.aussom/modules/ |
One app on this server |
| Server-global | Path set in config.yaml (see below) |
Every app on this server |
A request to include foo.foo; from inside an app walks these
paths in order and returns the first hit. The same include
statement is what an Aussom CLI user would write against an apac
install - the layout matches, so the resolution rule matches.
The server reads one optional key per environment:
<env>.server.apac.modulesDir
When the key is set and the path exists on disk, the server adds it
as an include path on every app engine. When the key is missing or
blank, the server simply does not register a global path and apps
see only their per-app .aussom/modules/.
The key lives inside the same server: block that already carries
name, host, port, appDir, and similar fields. Example:
env: local
local:
server:
name: "Integration Platform Server"
host: "0.0.0.0"
port: 8081
appDir: "test-apps"
apac:
modulesDir: "test-apps/apac-globals/modules"
uat:
server:
name: "Integration Platform Server"
host: "0.0.0.0"
port: 8081
appDir: "apps"
apac:
modulesDir: "/var/lib/aussom-server/modules"
prod:
server:
name: "Integration Platform Server"
host: "0.0.0.0"
port: 8081
appDir: "apps"
apac:
modulesDir: "/var/lib/aussom-server/modules"
The path is resolved as the server reads it: an absolute path points at one fixed location regardless of where the server was started, and a relative path is relative to the server's working directory. Pick the absolute form for production; the relative form is convenient for development checkouts.
The directory itself is just a destination for apac -i to write
into. apac does not read the server config and does not know the
path is special. The server's only job is to register it as an
include path.
The server's global directory is the directory you point
apac.modulesDir at. To install a package there, change into that
directory and run apac -i without -g:
cd /var/lib/aussom-server/modules
apac -i socket@1.0.5
-g is not used on the server. The CLI's -g flag targets the
fixed OS-conventional location, which is not what the server reads.
Running apac -i from inside the configured modules directory makes
that directory the install target, which is what you want.
Result on disk:
/var/lib/aussom-server/modules/
aussom.lock
socket/
package.yaml
aussom-socket.jar
socket.aus
...
Every app on the server can now include socket.socket; and pick up
the package. The server picks up new files on the next request that
triggers an app reload, the same way it handles edits to other
.aus files under a watched directory.
Per-app installs use the same workflow, just rooted at the app's
own directory. Change into the app directory and run apac -i:
cd /var/aussom-server/apps/myapp
apac -i socket@1.0.5
apac creates <myapp>/.aussom/modules/socket/ and a sibling
<myapp>/aussom.lock. Check the lockfile into source control with
the rest of the app so other developers and CI get the same tree
after apac -i (with no version argument, the lockfile pins are
honored).
Result on disk:
apps/myapp/
myapp.aus
aussom.lock
.aussom/
modules/
socket/
package.yaml
aussom-socket.jar
socket.aus
...
app_data/
public/
A per-app install overrides any server-global of the same name for that one app. Other apps on the server still see the global.
Once a package is installed in either tier, an app references it
the same way the Aussom CLI does. The include statement uses the
dotted form because the on-disk layout is <modules>/<name>/<name>.aus:
include socket.socket;
s = new socket();
For multi-file packages, additional source files are reached the
same way - include socket.util.parse; resolves to
socket/util/parse.aus inside the package directory.
Apps with reloadOnFileChange: true in applications.yaml already
watch their own directory tree for .aus, .html, .css, and .js
changes. Files dropped under <appDirectory>/.aussom/modules/
trigger a reload on the next request, which is the intended behavior
when an operator installs or uninstalls a per-app package.
The server-global directory is not under any app directory, so it is not watched. Changes there take effect on the next time each app reloads for another reason (a code edit, a manual restart, or an admin API reload call).
apac does not gate any capability. A package that calls
app.loadJar(...) only works on the server when the
AussomServerSecurityManager allows it. The default is
aussom.app.loadjar: false. Set the flag to true under the
server.securityManager: block in config.yaml for installs that
ship a JAR.
Pure-Aussom packages (type: pure in the manifest) do not need
any capability flag; they are just .aus files on the include
path.
