Define structured way to host plug-in meta-data about camunda-modeler-plugins HOT 7 CLOSED

The easiest thing would be to have a plugins.json at the root of this project that provides this metadata. Other projects provide this via yml, which could be interesting as well.

I will research this thing a bit.

from camunda-modeler-plugins.

I think adding a plug-in to a JSON file is absolutely manageable.

Combine that with a simple GitHub Action that verifies the JSON file against a defined JSONSchema and we're good.

from camunda-modeler-plugins.

How others do

VS Code Marketplace

• any plugin defines itself
• no central, easy accessible registry
• only example repo: https://github.com/microsoft/vscode-extension-samples

Electron Apps
https://github.com/electron/apps/blob/master/apps/camunda-modeler/camunda-modeler.yml

• define via yml
• one file per app

name: 'Camunda Modeler'
description:
  'Developer-friendly app for editing and executing BPMN process diagrams and
  DMN decisions.'
website: 'https://camunda.com/products/modeler/'
category: 'Developer Tools'
repository: 'https://github.com/camunda/camunda-modeler/'
keywords:
  - bpmn
  - dmn
  - modeling
  - modeler
  - diagram
  - 'business process'
license: MIT
screenshots:
  - imageUrl: 'https://raw.githubusercontent.com/camunda/camunda-modeler/master/docs/screenshot.png'
    caption: 'BPMN Editor with properties panel'
    imageLink: 'https://github.com/camunda/camunda-modeler'

JSON Schema Catalog
https://github.com/SchemaStore/schemastore/blob/master/src/api/json/catalog.json

• define via json
• simple overview, easily accessible
• maintains versions, but no compatibility

{
  "$schema": "https://json.schemastore.org/schema-catalog.json",
  "version": 1.0,
  "schemas": [
    {
      "name": "AnyWork Automation Configuration",
      "description": "AnyWork Automation Configuration used to configure automation scripts on AnyWork",
      "fileMatch": [
        ".awc.yaml",
        ".awc.yml",
        ".awc.json",
        ".awc.jsonc",
        ".awc"
      ],
      "url": "https://json.schemastore.org/anywork-ac-1.1.json",
      "versions": {
         "1.0": "https://json.schemastore.org/anywork-ac-1.0.json"
      }
    },
    ...
  ]
}

Fig Plugins
https://github.com/withfig/plugins/blob/main/CONTRIBUTING.md#add-metadata-to-your-plugin

• define via index.ts
• quite complex
• interesting: stores the complete plugin installation guide

const plugin: Fig.Plugin = {
  icon: "🔗",
  name: "dropbox_zpm-zsh",
  displayName: "Dropbox (ZPM)",
  type: "shell",
  description: "Zsh dropbox plugin",
  authors: [
    {
      name: "zpm-zsh",
      github: "zpm-zsh",
    },
  ],
  github: "zpm-zsh/dropbox",
  license: ["GPL-3.0"],
  site: "https://github.com/horosgrisa/zsh-dropbox",
  shells: ["zsh"],
  categories: ["Completion"],
  keywords: ["zsh", "dropbox-plugin", "dropbox"],
  installation: {
    origin: "github",
    sourceFiles: ["dropbox.plugin.zsh"],
  },
};

export default plugin;

Obsidians Community Plugins
https://github.com/obsidianmd/obsidian-releases/blob/master/community-plugins.json

• define via json
• simple overview

[
    {
        "id": "nldates-obsidian",
        "name": "Natural Language Dates",
        "author": "Argentina Ortega Sainz",
        "description": "Create date-links based on natural language",
        "repo": "argenos/nldates-obsidian"
    },
    {
        "id": "hotkeysplus-obsidian",
        "name": "Hotkeys++",
        "author": "Argentina Ortega Sainz",
        "description": "Additional hotkeys to do common things in Obsidian",
        "repo": "argenos/hotkeysplus-obsidian"
    },
    ...
]

from camunda-modeler-plugins.

What I could vision as a first step:

{
  "version": "1.0.0",
  "plugins": [
    {
      "id": "camunda-modeler-plugin-resize-tasks",
      "displayName": "Camunda Modeler Plugin: Resize Tasks",
      "version": "0.1.0",
      "description": "Camunda Modeler Plugin That Makes Tasks Resizable",
      "url": "https://github.com/philippfromme/camunda-modeler-plugin-resize-tasks",
      "category": "BPMN"
    }
  ]
}

Having this as a start, we can easily build things like compatibility or installation on top

{
  "id": "camunda-modeler-token-simulation-plugin",
  "displayName": "Token Simulation for the Camunda Modeler",
  "version": "0.16.0",
  "description": "Token simulation as a plugin for the Camunda Modeler",
  "url": "https://github.com/camunda/camunda-modeler-token-simulation-plugin",
  "category": "BPMN",
  "compatibility": [
    {
      "plugin": {
        "start": "8.0.0",
        "end": "0.15.0"
      },
      "desktop-modeler": {
        "start": "2.2.0",
        "end": "4.12.0"
      }
    },
    {
      "plugin": {
        "start": "0.16.0"
      },
      "desktop-modeler": {
        "start": "5.0.0"
      }
    }
  ]
}

Obviously, a JSON Schema would be imaginable, also to verify the plugins.json via CI. But that's optional (can be added later).

{
  "$schema": "https://foo.bar.com/plugins-schema.json",
  "version": "1.0.0",
  "plugins": []
}  

This would already enable us to make plugins discoverable

from camunda-modeler-plugins.

Looks promising. One possible improvement I could see is to have separate files for each of the plugins (cf. Electron apps or Homebrew formulae). This way, when I as a plugin maintainer add my plugin, it does not conflict with other pending contributions. I believe this could happen when everybody starts to modify the same array in a single JSON.

from camunda-modeler-plugins.

Looks promising. One possible improvement I could see is to have separate files for each of the plugins (cf. Electron apps or Homebrew formulae). This way, when I as a plugin maintainer add my plugin, it does not conflict with other pending contributions. I believe this could happen when everybody starts to modify the same array in a single JSON.

Good thought, but this would need an extra bundling step to put all the JSON files together into one, right? With a simple file, one can easily access it, e.g. via https://raw.githubusercontent.com/camunda/camunda-modeler-plugins/master/plugins.json.

from camunda-modeler-plugins.

Indeed, that would make the pipeline more complicated.

from camunda-modeler-plugins.