Skip to content

nasa/mmt

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Metadata Management Tool Application

Build Status codecov

The Metadata Management Tool (MMT) and Draft Metadata Management Tool (dMMT) are web applications designed to assist users in managing metadata and interfacing with the CMR.

Links

Getting Started

Requirements

  • Node (check .nvmrc for correct version)
    • nvm is highly recommended
  • Docker
  • Java 17
    • brew install openjdk@17

Setup

To install the necessary components, run:

    npm install

Usage

In order to run MMT locally, you first need to setup a local CMR, cmr-graphql, and GraphDB.

Running a local CMR

In order to use a local copy of the CMR you will need to download the latest file, set an environment variable, and run a rake task to set required permissions and ingest some data.

Downloading the CMR file

Download the CMR JAR file here. Ensure you save the file as cmr-dev-system-0.1.0-SNAPSHOT-standalone.jar

In your root directory for MMT, create a folder named cmr. Place the cmr-dev-system-0.1.0-SNAPSHOT-standalone.jar file in the cmr folder.

2. Setting the environment variable needed by the local CMR

Before running a local copy of the CMR, you will need to set a required environment variable. Add this line into your .bash_profile (or .zsh_profile):

    export CMR_URS_PASSWORD=mock-urs-password

After adding the line and saving the file, don't forget to source the file by running:

    source ~/.bash_profile
3. Setting up local redis for CMR

CMR comes with redis in the jar, but it is not compiled to run on Macs. If you need to run the CMR on a Mac, install redis with homebrew by running:

    brew update
    brew install redis
    brew services start redis

For more information, see:

4. Running the CMR npm scripts

To start the local CMR and load the test data, run:

Note: This command can be ran as two separate commands if needed:

    npm run cmr:start_and_setup

< or >

    npm run cmr:start
    npm run cmr:setup

After you see "Done!", you can load the app in your browser and use the local CMR. After you have started CMR, to just reload the data, run:

    npm run cmr:reset
    npm run cmr:setup

To stop the locally running CMR, run:

    npm run cmr:stop

You will need to stop the CMR before upgrading to a new CMR version. Note: stopping the running CMR for any reason will delete all data from the CMR. You will have to load the data again when you start it.

Running a local CMR GraphQL

To setup cmr-graphql, follow the https://github.com/nasa/cmr-graphql.

After you have set up cmr-graphql, to start it and point it to your local CMR, run:

    CMR_ROOT_URL=http://localhost:4000 EDL_CLIENT_ID=<client id> EDL_PASSWORD=<password> npm start

Note: This should be run from within the mmt directory.

Running a local CMR proxy

The local CMR uses ports instead of the routes you see in production. So you also need to start the graphql proxy found within this repo to connect to local cmr-graphql to local CMR.

To start the proxy, run:

    npm run start:proxy

Running a local GraphDB

To run GraphDB in docker, run:

    npm run start:graphdb

Running Serverless Offline (API Gateway/Lambdas)

In order to run serverless-offline, which is used for mimicking API Gateway to call lambda functions, run:

    EDL_PASSWORD=<password> npm run offline

Note: The EDL_PASSWORD environment variable is required for group member queries to function.

Running MMT

After starting the local CMR, cmr-graphql and GraphDB, run:

    npm start

UMM JSON-Schema

You can view/download the latest UMM JSON-Schema here.

Local Testing

To run the test suite, run:

    npm run test

UI

Styling

CSS should follow the following guidelines:

  • Prefer Bootstrap styles when writing custom components
  • If the desired look can not be achieved with Bootstrap, additional styling should be accomplished by:
    • Creating a scss file for the custom component
      • Classes should be defined on the elements following the BEM methodology
      • Sass should be written take advantage of nesting to prevent repetition of the blocks and elements

Things to keep in mind

These will help create more maintainable css:

  • Use Bootstrap variables where possible
    • Bootstrap provides css variables for things like colors, sizes, etc which should be used when possible.
      • Bootstrap variables are used with the var() syntax in css
  • Aim to keep specificity low
    • Most elements should only require a single class name
    • Avoid chaining selectors, descendant selectors, or other ways of increasing specificity
  • Use consistent modifier class names, starting with --is. Add more to the list below as new states are required.
    • --is-active,
    • --is-complete
    • --is-errored

Helpful links