ExternalVendorCode/openmct
1
0
Fork 0
mirror of https://github.com/nasa/openmct.git synced 2025-02-20 09:26:45 +00:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Updates to README in topic-core-refactor (#2573)

Browse Source 
* Updates to README in topic-core-refactor 

In preparation for merge into Master

* Added section on v1.0.0 and link to Migration Guide

* Minor wording change

* More minor wording changes
This commit is contained in:
Andrew Henry 2019-12-11 10:28:47 -08:00 committed by Deep Tailor
parent a16a44208a
commit 8ec1b9965a
1 changed files with 26 additions and 70 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

96
README.md
View File

@ -9,26 +9,6 @@ Please visit our [Official Site](https://nasa.github.io/openmct/) and [Getting S
Try Open MCT now with our [live demo](https://openmct-demo.herokuapp.com/).
![Demo](https://nasa.github.io/openmct/static/res/images/Open-MCT.Browse.Layout.Mars-Weather-1.jpg)
## New API
A simpler, [easier-to-use API](https://nasa.github.io/openmct/docs/api/)
has been added to Open MCT. Changes in this
API include a move away from a declarative system of JSON configuration files
towards an imperative system based on function calls. Developers will be able
to extend and build on Open MCT by making direct function calls to a public
API. Open MCT is also being refactored to minimize the dependencies that using
Open MCT imposes on developers, such as the current requirement to use
AngularJS.
This new API has not yet been heavily used and is likely to contain defects.
You can help by trying it out, and reporting any issues you encounter
using our GitHub issue tracker. Such issues may include bugs, suggestions,
missing documentation, or even just requests for help if you're having
trouble.
We want Open MCT to be as easy to use, install, run, and develop for as
possible, and your feedback will help us get there!
## Building and Running Open MCT Locally
Building and running Open MCT in your local dev environment is very easy. Be sure you have [Git](https://git-scm.com/downloads) and [Node.js](https://nodejs.org/) installed, then follow the directions below. Need additional information? Check out the [Getting Started](https://nasa.github.io/openmct/getting-started/) page on our website.
@ -48,9 +28,14 @@ Building and running Open MCT in your local dev environment is very easy. Be sur
Open MCT is now running, and can be accessed by pointing a web browser at [http://localhost:8080/](http://localhost:8080/)
## Open MCT v1.0.0
This represents a major overhaul of Open MCT with significant changes under the hood. We aim to maintain backward compatibility but if you do find compatibility issues, please let us know by filing an issue in this repository. If you are having major issues with v1.0.0 please check-out the v0.15.0 tag until we can resolve them for you.
If you are migrating an application built with Open MCT as a dependency to v1.0.0 from an earlier version, please refer to [our migration guide](https://nasa.github.io/openmct/documentation/migration-guide).
## Documentation
Documentation is available on the [Open MCT website](https://nasa.github.io/openmct/documentation/). The documentation can also be built locally.
Documentation is available on the [Open MCT website](https://nasa.github.io/openmct/documentation/).
### Examples
@ -58,48 +43,29 @@ The clearest examples for developing Open MCT plugins are in the
[tutorials](https://github.com/nasa/openmct-tutorial) provided in
our documentation.
For a practical example of a telemetry adapter, see David Hudson's
[Kerbal Space Program plugin](https://github.com/hudsonfoo/kerbal-openmct),
which allows [Kerbal Space Program](https://kerbalspaceprogram.com) players
to build and use displays for their own missions in Open MCT.
We want Open MCT to be as easy to use, install, run, and develop for as
possible, and your feedback will help us get there! Feedback can be provided via [GitHub issues](https://github.com/nasa/openmct/issues), or by emailing us at [arc-dl-openmct@mail.nasa.gov](mailto:arc-dl-openmct@mail.nasa.gov).
Additional examples are available in the `examples` hierarchy of this
repository; however, be aware that these examples are
[not fully-documented](https://github.com/nasa/openmct/issues/846), so
the tutorials will likely serve as a better starting point.
## Building Applications With Open MCT
### Building the Open MCT Documentation Locally
Open MCT's documentation is generated by an
[npm](https://www.npmjs.com/)-based build. It has additional dependencies that
may not be available on every platform and thus is not covered in the standard
npm install. Ensure your system has [libcairo](http://cairographics.org/)
installed and then run the following commands:
Open MCT is built using [`npm`](http://npmjs.com/) and [`webpack`](https://webpack.js.org/).
* `npm install`
* `npm install canvas nomnoml`
* `npm run docs`
See our documentation for a guide on [building Applications with Open MCT](https://github.com/nasa/openmct/blob/master/API.md#starting-an-open-mct-application).
Documentation will be generated in `target/docs`.
## Plugins
## Deploying Open MCT
Open MCT can be extended via plugins that make calls to the Open MCT API. A plugin is a group
of software components (including source code and resources such as images and HTML templates)
that is intended to be added or removed as a single unit.
Open MCT is built using [`npm`](http://npmjs.com/)
As well as providing an extension mechanism, most of the core Open MCT codebase is also
written as plugins.
To build Open MCT for deployment:
`npm run prepare`
This will compile and minify JavaScript sources, as well as copy over assets.
The contents of the `dist` folder will contain a runnable Open MCT
instance (e.g. by starting an HTTP server in that directory), including:
* `openmct.js` - Open MCT source code.
* `openmct.css` - Basic styles to load to prevent a FOUC.
* `index.html`, an example to run Open MCT in the basic configuration.
For information on writing plugins, please see [our API documentation](https://github.com/nasa/openmct/blob/master/API.md#plugins).
## Tests
Tests are written for [Jasmine 3](http://jasmine.github.io/)
Tests are written for [Jasmine 3](https://jasmine.github.io/api/3.1/global)
and run by [Karma](http://karma-runner.github.io). To run:
`npm test`
@ -115,7 +81,7 @@ naming convention is otherwise the same.)
### Test Reporting
When `npm test` is run, test results will be written as HTML to
`target/tests`. Code coverage information is written to `target/coverage`.
`dist/reports/tests/`. Code coverage information is written to `dist/reports/coverage`.
# Glossary
@ -125,11 +91,8 @@ addressed (either by updating this glossary or changing code to reflect
correct usage.) Other developer documentation, particularly in-line
documentation, may presume an understanding of these terms.
* _bundle_: A bundle is a removable, reusable grouping of software elements.
The application is composed of bundles. Plug-ins are bundles. For more
information, refer to framework documentation (under `platform/framework`.)
* _capability_: An object which exposes dynamic behavior or non-persistent
state associated with a domain object.
* _plugin_: A plugin is a removable, reusable grouping of software elements.
The application is composed of plugins.
* _composition_: In the context of a domain object, this refers to the set of
other domain objects that compose or are contained by that object. A domain
object's composition is the set of domain objects that should appear
@ -144,13 +107,8 @@ documentation, may presume an understanding of these terms.
* _domain object_: A meaningful object to the user; a distinct thing in
the work support by Open MCT. Anything that appears in the left-hand
tree is a domain object.
* _extension_: An extension is a unit of functionality exposed to the
platform in a declarative fashion by a bundle. For more
information, refer to framework documentation (under `platform/framework`.)
* _id_: A string which uniquely identifies a domain object.
* _key_: When used as an object property, this refers to the machine-readable
identifier for a specific thing in a set of things. (Most often used in the
context of extensions or other similar application-specific object sets.)
* _identifier_: A tuple consisting of a namespace and a key, which together uniquely
identifies a domain object.
* _model_: The persistent state associated with a domain object. A domain
object's model is a JavaScript object which can be converted to JSON
without losing information (that is, it contains no methods.)
@ -162,7 +120,5 @@ documentation, may presume an understanding of these terms.
a user clicks on a domain object in the tree, they are _navigating_ to
it, and it is thereafter considered the _navigated_ object (until the
user makes another such choice.)
* _space_: A name used to identify a persistence store. Interactions with
persistence will generally involve a `space` parameter in some form, to
distinguish multiple persistence stores from one another (for cases
where there are multiple valid persistence locations available.)
* _namespace_: A name used to identify a persistence store. A running open MCT
application could potentially use multiple persistence stores, with the