Aerie Ecosystem

[camargo]

This document lists all the software components in the Aerie ecosystem.

Java Libraries

1. constraints - Java library for constraint checking
2. contrib - Java library of common convenience classes for mission models
3. merlin-driver - Java library for discrete-event simulation execution
4. merlin-framework-junit - Java library extension of JUnit to unit test mission models
5. merlin-framework-processor - Java library for annotation processing in mission models
6. merlin-framework - Java library for writing mission models
7. merlin-sdk - Java library interface between mission models and the merlin-driver
8. parsing-utilities - Java library for JSON serialization and deserialization
9. scheduler-driver - Java library for goal-oriented scheduling execution

JavaScript/TypeScript Libraries

1. aerie-ampcs - Utility functions to convert a standard XML AMPCS command dictionary to JavaScript
2. aerie-ts-user-code-runner - Library to safely run user code written in TypeScript

Services

1. aerie-gateway - Service for managing files and authentication
2. merlin-server - Service for planning and simulation
3. merlin-worker - Service that executes concurrent simulation requests
4. scheduler-server - Service for scheduling
5. scheduler-worker - Service that executes concurrent scheduling requests
6. sequencing-server - Service for sequence generation and management

Applications and Tools

1. aerie-cli - CLI tool for Aerie API convenience use
2. aerie-docs - Web-based documentation website for Aerie
3. aerie-ui - Web-based client application for Aerie

Example Mission Models

1. aerie-mission-model-template - Template project for starting an Aerie mission model
2. aerie-lander - Example mission model for a lander mission
3. examples - Different examples of simple Aerie mission models

End-to-End Tests

1. db-tests - Aerie repo database tests
2. e2e-tests - Aerie repo end-to-end tests
3. e2e-tests - Aerie UI repo end-to-end tests

[ewferg]

I think this is a useful way to break things up and something we should maybe include in the README? I would say this would replace the directory structure section, which could potentially go in a contributing area, but I don't have any strong opinions there. Another way we could break this down that may be a little simpler for an outside audience would be by high level capability where we would combine some of the libraries/services together. What do you think of this:

Simulation Engine

1. merlin-driver - Java library for discrete-event simulation execution
2. merlin-server - Service for planning and simulation
3. merlin-worker - Service that executes concurrent simulation requests

Mission Model Framework

4. merlin-framework-junit - Java library extension of JUnit to unit test mission models
5. merlin-framework-processor - Java library for annotation processing in mission models
6. merlin-framework - Java library for writing mission models
7. merlin-sdk - Java library interface between mission models and the merlin-driver
8. contrib - Java library of common convenience classes for mission models

Scheduling

1. scheduler-driver - Java library for goal-oriented scheduling execution
2. scheduler-server - Service for scheduling
3. scheduler-worker - Service that executes concurrent scheduling requests

Constraint Checking

1. constraints - Java library for constraint checking

Sequencing

1. sequencing-server - Service for sequence generation and management

Core Infrastructure

1. parsing-utilities - Java library for JSON serialization and deserialization
2. aerie-ampcs - Utility functions to convert a standard XML AMPCS command dictionary to JavaScript
3. aerie-ts-user-code-runner - Library to safely run user code written in TypeScript
4. aerie-gateway - Service for managing files and authentication

[camargo]

Yeah I think it's a good idea to add this list to our doc site. I don't think we should replace the directory structure in the Aerie repo README just because this list includes things outside the directory structure of that repo (and the directory structure also includes things not in this list).
I like the breakdown by higher-level capability. Is there a reason you excluded the application & tools, examples models, and test components?

[Twisol]

These two ways of organization remind me of organizing by feature vs. layer. I tend to like organization by feature better as a default -- although knowing how everything gets composited in layers is useful too :)