Well this is pretty explanatory…
Regarding the actual implementation, I think that it can be achieved by placing a descriptor at the root of a component’s github repository, for example a file named cuba-addon.json or something similar.
The contents could be borrowed by some other package managers, like npm or composer and so on.
For example this could be a descriptor for my latest dynamic-columns addon:
{
"name": "Dynamic Columns for Table",
"description": "A CUBA Framework component that adds dynamic columns support (user created) for Table components.",
"category": "Add-On",
"tags": ["UI"],
"price": "free",
"license": "Apache-2.0",
"keywords": ["table", "dynamic", "columns"],
"homepage": "https://github.com/pfurini/cuba-component-dynamic-columns#readme",
"bugs": "https://github.com/pfurini/cuba-component-dynamic-columns/issues",
"repository": "https://github.com/pfurini/cuba-component-dynamic-columns.git",
"author": {
"name": "Paolo Furini",
"email": "",
"url": ""
},
"versions": {
"1.0.0": {
"engine": "~6.8.8",
"repository": "https://dl.bintray.com/pfurini/cuba-components",
"coordinates": "it.nexbit.cuba.dynamiccolumns:nxdcol:1.0.0"
},
"1.1.0": {
"engine": "~6.9.0",
"repository": "https://dl.bintray.com/pfurini/cuba-components",
"coordinates": "it.nexbit.cuba.dynamiccolumns:nxdcol:1.1.0"
}
}
}
The engine field is the target CUBA version for a specific version of the addon. The tilde has the same meaning as in node, that is ~6.8.8 will match all 6.8 point releases. One can use more complex specifications, like >=6.8.6 <6.9
There should be a command in the upcoming CLI to publish/update a component registration in the marketplace, that in the end will cache the updated component.json. A proper markeplace REST API will provide the integration with Studio and the CLI itself when publishing, searching and installing an addon.
Studio could enhance the Add component dialog by fetching the current addons published in the marketplace, and filter the available components based on the component.json metadata.
Paolo