ORIGAM Package Manager

ideas
1

We seem to have ben able to start to separate different ORIGAM features into modules or plugins. Example: Audit, Attachments, Chat.

Some of these consist only from model (e.g. Root package itself), some might include a frontend plugin (e.g. Audit) and some might include extra resources or even full stack (e.g. Chat which adds to the server, client and model).

So far we have been bundling everything in our main build. But we expect the community to create more add-ons. We ourselves want to modularise ORIGAM so one would not need to distribute the whole thing if only parts are needed.

If we want to make the distribution truly painless we have to introduce some kind of a packaging system, like NuGet or npm.

Using GitHub Packages for storage would be a good starting point as we wouldn’t have to provide our own infrastructure for the backend.

Because as usual

image
image722×686 48.8 KB

Which is great. We love open source, too.

For the client functionality I think we could use NuGet client.

For model development it could work like this:

  1. Architect opens a model
  2. Detects packages (we would store them in packages.config) and makes NuGet install them
  3. Loads model from the /model folder and dependent models from the /packages folder (we would have to support multiple model paths)

For server deployment we could incorporate it into the custom Docker build. The procedure could be like this:

  1. Use origam/server:master-latest Docker image
  2. git pull from the model repository
  3. nuget install would download all dependencies found in the model and put them into the packages folder
  4. Model parts of each package could be left there or merged into an aggregated model folder.
  5. index.bin could be built using origam-utils so server startup is faster
  6. The docker image would already contain the frontend source files. Package parts related to the frontend (javascript/html/assets) would be copied to the right plugin folders of the frontend source folder.
  7. yarn build would compile the frontend including the packages
  8. Server related parts (dlls) would be added to the bin folder of the server

This DOCKERFILE would be a standard, so a developer could just run docker build and get his image.

This way we would get a custom docker which would contain all the dependent packages on all levels (model/backend/frontend).

Root Model Package Naming Convention