How to publish your web component on the Open Data Hub Store ‐ OUTDATED

TO REVISE - OUTDATED

First check that your web-component meets all the requirements necessary to be published on this how to guide, here.

The purpose of this howto guide is to help you in the process of making available a Web Component that you created with the Open Data Hub Community, by publishing it on Open Data Hub Store. The Web Component must be released as an Open Source Licence.

One of three alternatives can be chosen to publish a Web Component on the Store: as a full open source project, as a forked project, or using what we call the external workflow; the preferred being the first one.

1. When using the full open source path, you simply hand in the source code of your Web Component to the Open Data Hub team, no additional effort is required from your side. The code will be placed in a GIT repository, and immediately made available through the Store. Future versions of the Web component are developed under the control of the Open Data Hub team directly within this repository.

2. The forked project way will still see the Web Component’s source code saved in a GIT repository, but you own full control of it, and decide about its future versions. The difference with the previous method is that the updates are done by you in your repository and the Open Data Hub team will need to keep its copy synchronised with yours.

3. Finally, the the external workflow is the one is which nothing is saved in a GIT repository. You will maintain full control of the source code and of the Web Component’s development, including the right to pull it out of the store. Should you decide to follow this path, you will have to satisfy a few more requirements, to ensure proper integration with the Store:

   1. You need to install in the root directory of your Web Component’s source code a suitable ,wcs-manifest.json file, that you will receive via pull request.

   2. Your Web component must be saved (better if in minified form) under a dist directory, e.g., as $ROOT/dist/widget.min.js, where $ROOT is the root directory of your repository.

   3. You need to tag a commit on your master branch with a semantic versioning tag, to communicate to the Store that the corresponding version should be published (example, git tag -a "v1.2.3" -m "v1.2.3").
      A detailed guide about it can be found here: Deploying with Git Tags

An example of these files and setup can be found in the published example of a generic map, that you can find at https://github.com/noi-techpark/webcomp-generic-map.

Finally, to ensure that your Web Component is kept updated in the Store, suitable pull requests will be sent to your repository.

In all three cases, a repository called origins (hosted on github will hold a reference to each Web Component’s repository, from where all files that are necessary for its deployment including the manifest file, the javascript, and logo if present-to each Web Component’s version. It is therefore important, in case the external workflow has been chosen, that the URL to the Web Component be stable, otherwise the Web Component will not be available.