Agama Import

Re-use and portability is one of the most important business goals of Agama. Initially we thought that a developer would fork a project from the Agama Lab Explore Catalog, make some changes, and Release their own version. But what we've discovered is that we may need to actually Trigger flows from parent projects, without making any modifications (and it may be too late to fork that project and use it as the base). For example, in a flow that calls an OpenID Provider, the developer may want to Trigger io.jans.inbound.oauth2.AuthzCodeWithUserInfo. Right now there is no good way to do this other then copying all the assets into your project.

To solve this, we could make a few changes to the archive and metadata.

.gama structure

├── code/
├── lib/
├── web/
     ├── gluufederation/agama-openid/       <--- github_id and project to avoid collissions
├── project.json   
├── LICENSE        
└── README.md

projects.json metadata

{
  "projectName": "A unique name that will be associated to this project",
  "author": "A user handle that identifies you",
  "description": "Other relevant data can go here",
  "type": "",
  "configs": {
    "com.foods.sweet": {
        "prop1": "secret",
        "prop2": [1, 2, 3]
    }
  },
  "noDirectLaunch": [ "test" ]
  "parent_project": { 
      "GluuFederation/agama-pw": {"version": "1.9.42", "include_in_gama": True},
      "GluuFederation/agama-openid": {"version": "3.3.2", "include_in_gama": False}
  }
}

Impacts / questions

• .gama

  1. Add parent folder to web (github-id/repo)

• Agama Lab

  1. Notifications about dependency version updates
  2. Present an option to bundle certain projects in the .gama
  3. Show links to dependency docs of available published projects--for example, smart drop down selector for Trigger to available flows (including depenencies)
  4. Perhaps we can optionally show the parent project assets--but they are greyed out and read only. There could be a project checkbox to show imported assets...

• Publication Process

  1. Impacts to project publication process? For example, we should perhaps not allow derivative projects in Agama Lab... parent_project must be null.

More questions

Things to consider before undertaking implementation:

1. how will TUI display deployments now? when uploading an archive with several imported projects, several rows will appear, ie. one per project?
2. if so, how will removal work now? eg. if a project is removed, their dependencies too?
3. what if someone deploys a new version of a project but the currently deployed version is a dependency of another existing project? (project versioning is not supported because there cannot be several versions of the same Java class simultaneously)
4. While agama-lab will show a sort of "merged" view for code and lib directories, will the generated archive contain the archives of the corresponding dependencies instead? ie. dependencies not "exploded" ?