Join GitHub today
Extension components generated with webgme-cli contains metadata inside
webgme-setup.json. This allows one repository to import components from another. The webgme-cli tool allows components to be imported from git repositories (e.g. github) and in an initial development phase that may very well do as long as the importer is aware of the location of the repository.
Once a set of components or a domain has matured, it is recommended (if it's public and meant to be shared) to publish the repository as a node-module on npmjs.com. That way the module can be versioned using semantic versioning and be visible for other webgme users/developers.
Follow the instruction below to make your repository visible from webgme.org.
Making a WebGME Module Visible to the Community
Component, Domain or App?
Before publishing a repository the content of it should be categorized as a
A webgme app typically defines a meta-model (distributed as a seed) and is associated with a range of custom visualization and/or plugins. A
webgme-app does not have to guarantee re-usability of components and can have a complex range of dependencies. A
webgme-app can be seen as a complete "end-product" where if someone would like to use it - they would typically clone the repository.
An example of an app is DeepForge. It pulls in components for other repositories, has a range of dependencies on the back-end and defines lots of custom domain-specific visualization components.
A domain always defines (or is associated with) a meta-model (distributed as a seed), and is typically associated with some domain specific visualization and/or interpretation via some plugin(s). To be classified as a
webgme-domain, it should be possible for others to import (at least a subset of) components and be able to use it with minor (documented) configuration settings. This is where a
webgme-domain differs from a
A simple example of this is webgme-finite-state-machine, that contains a seed with the meta-model, a domain specific decorator for the diagram-designer and plugin that generates executable code.
A component is more or less domain-independent. It could require that a certain attribute is defined meta-model, but does not enforce any domain specific semantics on the models.
webgme-component could contain a single component, a range of independent components, e.g. webgme-ui-components, or a set of dependent component that together forms an entire feature, e.g. webgme-constraint-checker.
Note: It may very well be that a repository that started out as a domain or app that ended up containing components that are more or less domain independent. In that case it might be worth migrating those pieces over to a separate repository and include them from the main repository. That way those components can be maintain independently and reused outside of the initial domain.
Conventions before Publishing
Before publishing a package, the
README should clearly state how to bring the components together* (typically the commands used from webgme-cli) and which configurations can or need to be set in order for the extension to work. It's also a good idea to state which external dependencies (beyond the ones needed for a webgme app in general) are needed, e.g. some analysis tool, some database etc.
*If it's a
With a decent looking
README and a decision of which category the repository belongs.
- Add the keywords
webgmeand one of
webgme-component(depending on the category) in your
- Make sure your
package.jsonadditionally contains the following fields: name, description, version, repository